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)
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.
Reporter | ||
Comment 2•21 years ago
|
||
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.
Assignee | ||
Comment 3•21 years ago
|
||
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
Reporter | ||
Comment 4•21 years ago
|
||
> 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 → ---
Reporter | ||
Comment 5•21 years ago
|
||
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
Comment 6•21 years ago
|
||
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?
Assignee | ||
Comment 7•21 years ago
|
||
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 ago → 21 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 8•21 years ago
|
||
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.
Comment 9•21 years ago
|
||
> over the years
just as a note - certificates expire; I think one year is not uncommon (mine
expires after a year)
Reporter | ||
Comment 10•21 years ago
|
||
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.)
Assignee | ||
Comment 11•21 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•