Closed Bug 211498 Opened 21 years ago Closed 21 years ago

Signature with cert from untrusted CA is wrongly marked as invalid

Categories

(MailNews Core :: Security: S/MIME, defect)

Other Branch
x86
All
defect
Not set
major

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: BenB, Assigned: ssaux)

Details

Reproduction:
- Open a signed mail from a sender with a certificate issued by a CA not
explicitly marked as trusted in the internal database, e.g. by web.de (big
German freemail provider with CA).

Actual result:
- Broken pen for "invalid signature"
- If you click on the pen, the dialog says:
"Digital Signature is Not Valid
This message includes a digital signature, but the signature is invalid.
The certificate used to sign the message was issued by a certificate authority
that you do not trust for issuing this kind of certificate."
This statement is wrong, the signature is (probably) correct and it is still useful.

Expected result:
- Pen with question mark
- "Digital signature cannot be verified
This message includes a valid digital signature, but the certificate authority
issuing the used certificate is neither known nor trusted yet. This means that
the identity of the sender (name, email address) cannot be verified, but it can
be verified that it is always the *same* sender who uses this certificate."

Severity Major, because this makes all certificates apart from those of the big
CAs pretty useless and worse yet spreads misinformation to users.
s/big CAs/CAs shuffeling $$$/
OS: Linux → All
s/Digital signature cannot be verified/Digital signature with unverifyable identity/

There should also be some aids to verify that it's always the same certificate
signing emails from a certain email address, e.g. issueing a warning, if I have
a certificate for that address in my local database, but the certificate in the
new email is a different one. I don't know, if that happens already. If not,
that should be a new bug.
Works as designed. The question mark is reserved for signatures that can't be
verified because IMAP allows the attachments to not be downloaded when they're
large. When that happens, we show the question mark and let the user download
the attachment to verify the signature.

Untrusted CAs are bad, and we correctly show a broken pen.

User need to trust the CA (and that only if he truly trust it.)
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
> Works as designed

Then the design is flawed.

> Untrusted CAs are bad
> User need to trust the CA

Bad assumptions. I don't trust *any* CA. If your enemy is the state, you cannot
trust CAs.

Apart from that, there is nothing wrong with a signature that I verified myself,
even if I don't trust the CA. PGP works that way. There is no inherent reason
why S/MIME should not allow the same mode of operation.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Also, the statement "the signature is invalid" is plain wrong.

Note the difference in goals: I don't care that Christian Biesinger really has
that name in real life. I do care, however, that I am speaking always to the
same "Christian Biesinger" that I know. CAs are important for the former, but
don't necessarily verify the latter. For the latter, I don't need CAs. There is
no reason to discount the latter goal, and I'd argue that it's the more
important goal from a security standpoint.
Summary: Signature with cert from untrusted CA marked as invalid → Signature with cert from untrusted CA is wrongly marked as invalid
Ben, when you already have the certificate from the other person, could you use
certificate manager to make the cert as trusted, to make the signature verify?

I think it is clearly a point of view whether the signature is "invalid".
On a technical level, we agree, a signature is cryptographically valid even if
the cert is untrusted.

But on a philosophy level, we want to say "the signature is not worth anything,
because you can't trust the authenticy".

I agree the wording "signature is invalid" is not precise, but on the other
hand, this statement is followed by the more detailed explanation (which you
cited), and that makes it clear?
The signature is invalid as per RFCs. S/MIME is not PGP and it relies on CA and
trusted chains. The client continues an S/MIME tradition that has existed since
1996 and we're not going to change this policy. Go and trust individual certs if
you don't want to trust the CA.

Status: REOPENED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → INVALID
ssaux, could you please point our the RFC and ideally the section where it says
that the sig is invalid? IIRC, e.g. self-signed certs are supported even under
S/MIME.

> "the signature is not worth anything,
> because you can't trust the authenticy"

I don't think it's worthless. Even if I don't explicitly trust the cert and no
nothing about the CA: Let's say I read the mozilla newsgroups and you and biesi
always sign your posts with own self-signed cert or with a cert from an CA that
didn't pay $$$ to Netscape. When I read the first post from you, it gets added
to my database. Chances are, that's also the first time I hear from *you* (as a
person), and I don't care very much what your real-life name is. I continue to
read the newsgroups over the years, and you always sign your posts with that
same cert, Mailnews always compares it with the internal database, finds (based
on the email address in the cert) the stored cert and sees that the cert in the
email matches the stored one and that the signature matches the sig. What does
that tell me? That the post I read is from the same person as all the other
posts I read from the guys kaie and biesi. That's all I wanted to know. (If the
cert in the email would not match that in the db, *that*'s a case to boldly warn
users, even if it were signed by a "trusted" CA.) And I know all that even
though I never explcitly marked the cert as trusted nor even trust the signing CA.

> S/MIME is not PGP and it relies on CA and trusted chains.

Why? There is no cryptographical reason for that, only business/policy reasons,
and I don't think that Mozilla should enforce such (IMHO needless and dangerous)
policies.

> could you use certificate manager to make the cert as trusted,
> to make the signature verify?

Yes, *I* can do that, *I* know that I can ignore Mozilla's wrong statement that
the sig is invalid and the cert is bad and still mark it trusted, because *I*
know about this bug and the crypto background (somewhat). My recipients,
however, usually do not, and I'd either have to explain them for hours why I am
right or tell them to just believe me more than the software they use, in which
case I could probably tell them *anything*, and there's the risk that they
believe the next bad guy who tells them "Mozilla is wrong to warn you about
installing that XPI, it's harmless, trust me". In other words, you make it
*practically impossible* that others accept my perfectly fine self-signed cert
or cert signed by web.de (which is probably no worse than those from TC
Trustcenter), and this bug is the reason for it.
> over the years

just as a note - certificates expire; I think one year is not uncommon (mine
expires after a year)
I know. Nice plot, ain't it? So, in traditional S/MIME scheme, all my personal
trust metrics are invalid after a year and I have to trust the CA again, which
might not be so trustworthy after all (*any* CA). Yet another reason to fix this
bug.

(I idly wonder, who this the current S/MIME is supposed to serve - normal users
probably won't care enough about security to go through lengths to get a cert,
and really paranoid users probably won't trust CAs. This leaves only huge
mega-corps as users who want to potentially sue people in court based on their
real-life identity testified by the cert and CA.)
Let's start with X509 certs, the underpinning of S/MIME. Validation assumes
trusted CAs.

ftp://ftp.isi.edu/in-notes/rfc3280.txt

2.3  User Expectations

   Users of the Internet PKI are people and processes who use client
   software and are the subjects named in certificates.  These uses
   include readers and writers of electronic mail, the clients for WWW
   browsers, WWW servers, and the key manager for IPsec within a router.
   This profile recognizes the limitations of the platforms these users
   employ and the limitations in sophistication and attentiveness of the
   users themselves.  This manifests itself in minimal user
   configuration responsibility (e.g., trusted CA keys, rules), explicit
   platform usage constraints within the certificate, certification path
   constraints which shield the user from many malicious actions, and
   applications which sensibly automate validation functions.

2.4  Administrator Expectations

   As with user expectations, the Internet PKI profile is structured to
   support the individuals who generally operate CAs.  Providing
   administrators with unbounded choices increases the chances that a
   subtle CA administrator mistake will result in broad compromise.
   Also, unbounded choices greatly complicate the software that process
   and validate the certificates created by the CA.

3  Overview of Approach

   Following is a simplified view of the architectural model assumed by
   the PKIX specifications.

   The components in this model are:

   end entity: user of PKI certificates and/or end user system that is
               the subject of a certificate;
   CA:         certification authority;
   RA:         registration authority, i.e., an optional system to which
               a CA delegates certain management functions;
   CRL issuer: an optional system to which a CA delegates the
               publication of certificate revocation lists;
   repository: a system or collection of distributed systems that stores
               certificates and CRLs and serves as a means of
               distributing these certificates and CRLs to end entities.

   Note that an Attribute Authority (AA) might also choose to delegate
   the publication of CRLs to a CRL issuer.





[Note phrase "trusted CA"]

3.1  X.509 Version 3 Certificate

   Users of a public key require confidence that the associated private
   key is owned by the correct remote subject (person or system) with
   which an encryption or digital signature mechanism will be used.
   This confidence is obtained through the use of public key
   certificates, which are data structures that bind public key values
   to subjects.  The binding is asserted by having a trusted CA
   digitally sign each certificate.  The CA may base this assertion upon
   technical means (a.k.a., proof of possession through a challenge-
   response protocol), presentation of the private key, or on an
   assertion by the subject.  A certificate has a limited valid lifetime
   which is indicated in its signed contents.  Because a certificate's
   signature and timeliness can be independently checked by a
   certificate-using client, certificates can be distributed via....



Section 6.

[Note the term "validation" and the phrase "trust anchor". Everything in the
spec starts with the notion of trusted CAs.]

   To meet this goal, the path validation process verifies, among other
   things, that a prospective certification path (a sequence of n
   certificates) satisfies the following conditions:

      (a)  for all x in {1, ..., n-1}, the subject of certificate x is
      the issuer of certificate x+1;

      (b)  certificate 1 is issued by the trust anchor;

      (c)  certificate n is the certificate to be validated; and

      (d)  for all x in {1, ..., n}, the certificate was valid at the
      time in question.

   When the trust anchor is provided in the form of a self-signed
   certificate, this self-signed certificate is not included as part of
   the prospective certification path.  Information about trust anchors
   are provided as inputs to the certification path validation algorithm
   (section 6.1.1).



[rfc 2632 http://www.ietf.org/rfc/rfc2632.txt]
[relevant sentences:
  S/MIME agent MUST certify that the public key is valid.
  S/MIME agents
   MUST use PKIX certificates to validate public keys as described in
   the Internet X.509 Public Key Infrastructure (PKIX) Certificate and
   CRL Profile [KEYM].]
  

1. Overview

   S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
   [SMIME-MSG], provides a method to send and receive secure MIME
   messages. Before using a public key to provide security services, the
   S/MIME agent MUST certify that the public key is valid. S/MIME agents
   MUST use PKIX certificates to validate public keys as described in
   the Internet X.509 Public Key Infrastructure (PKIX) Certificate and
   CRL Profile [KEYM]. S/MIME agents MUST meet the certificate
   processing requirements documented in this document in addition to
   those stated in [KEYM].


[enjoy].

I think Mozilla does an excellent job at implementing S/MIME.
Product: PSM → Core
Product: Core → MailNews Core
QA Contact: bmartin → s.mime
You need to log in before you can comment on or make changes to this bug.