Closed Bug 431085 Opened 12 years ago Closed 10 years ago
Review Staat der Nederlanden CA email trust eligibility
Bug 369357 comment 37 suggests that Staat der Nederlanden does not verify that the subscriber (Subject) has access/control to the email address(es) that it puts into certs, yet it's CA certs are trusted for email. At least one other person concurs with that assessment. So Mozilla needs to review that CA's practices to see if they comply with Mozilla's policy for email trust, and consider what action to take if they do not.
I guess that this bug can be closed once the discussion about the Staat der Nederlanden CA has been concluded.
Staat der Nederlanden has updated their practices and CP to address the concerns stated in this bug about not verifying that the email address included in a certificate is owned/controlled by the subscriber. This has been discussed in bug #436056 and in the public discussion for the corresponding root inclusion request. Their current practice is as follows: PKIoverheid does not allow the email address to be included in the Subject.emailAddress field. The email address is deprecated but permitted in the SubjectAltName.rfc822Name field. It only may be used to support certain applications (legacy implementations) who need the email address (according to RFC 5280 page 25). This is sometimes necessary for (legacy) applications within companies and governmental organizations. Therefore it is applicable with regard to our CP part 3a. But it will not be necessary for the use of certs issued to civilians (CP Part 3c). Staat der Nederlanden updated CP Part 3a (for employees of governmental organizations or commercial companies) to include the following: If the e-mail address is included in the certificate then the CSP MUST: - let the subscriber agree on this by signing an agreement and; - verify that the e-mail address belongs to the domain of the subscriber. After significant discussion, it was determined that Staat der Nederlanden’s new practice of only allowing the email address in the SubjectAltName.rfc822Name field, means that the certs cannot be used for S/MIME within the context of Mozilla products like Thunderbird. We determined that the new root will not have the email trust bit enabled, because in the context of Mozilla the certs issued under the new root cannot be used for S/MIME. Staat der Nederlanden will create a new bug if they decide to pursue enabling the email trust bit in the new root. Now the question: Is it worthwhile/necessary to disable the email trust bit in the old root that is currently in NSS?
If I may make a suggestion: PKIoverheid will decide in coordination with the CSPs within the PKIoverheid hierarchy (particularly the CSPs UZI-register/CIBG and Defensie) if we will file a new/separate bug requesting that the email trust bit be enabled for our new (G2) root. If PKIoverheid decide to file a new/separate bug we will do so for coming February 1st. We need this time to analyze what the consequences are for our end entity users now the email trust bit with regard to our G2 root (and perhaps also with regard to our G1 root) will not be included. Furthermore we will have to decide what strategy we will have to undertake to convince Mozilla from our point of view. I suggest that this Bug will be put on hold pending this decision from PKIoverheid. If PKIoverheid should decide not to file a new/separate bug than it is up to Mozilla to make a decision with regard to our G1 root. If PKIoverheid should decide to file a new/separate bug than it depends on the outcome of the new discussion what will happen with the email trust bit regarding our G1 root. Does Mozilla agree with this suggestion? Regards Mark
Given that you did update your practices to include verification of ownership of the email address, I don't see a problem in waiting.
Assignee: hecker → kathleen95014
Status: NEW → ASSIGNED
Whiteboard: Pending PKIoverheid Decision due Feb 2010
>After significant discussion, it was determined that Staat der Nederlanden’s >new practice of only allowing the email address in the >SubjectAltName.rfc822Name field, means that the certs cannot be used for >S/MIME within the context of Mozilla products like Thunderbird. The latest RFC regarding S/MIME is 5750 (http://tools.ietf.org/html/rfc5750). Section 4.4.3 states that “Any email addresses present MUST be encoded using the rfc822Name…”. To include the e-mail address in this field seems appropriate. >We determined that the new root will not have the email trust bit enabled, >because in the context of Mozilla the certs issued under the new root cannot >be used for S/MIME. In addition as stated in the mozilla.dev.security.policy newsgroup: “While, according to spec, certificates usable for S/MIME email may not be required to include email addresses, our specific interest is how such certificates are used in the context of Mozilla products like Thunderbird. If email certificates cannot be used in the context of the Thunderbird model then, from Mozilla's perspective, there is no point in accepting them for purposes of email, even if they might be usable in other applications that support S/MIME. One of our goals is to operate the root program in terms of minimizing risk. One way that we can minimize risk is by not giving roots more trust than they absolutely require. To summarize, to enable the email trust bit, the requirements in the Mozilla CA Certificate policy must be met for the root and all of the sub-CAs, and the email certificates should be usable within the Mozilla context/products (eg Thunderbird).” With regard to the first requirement: “…, the requirements in the Mozilla CA Certificate policy must be met for the root and all of the sub-CAs”: The policy of PKIoverheid regarding the verification of Email Address Ownership/Control is that PKIoverheid does not allow the email address to be included in the Subject.emailAddress field. The email address is deprecated but permitted in the SubjectAltName.rfc822Name field. In our CP Part 3a it is stated that: “If the e-mail address is included in the certificate the CSP must: let the subscriber agree on this by signing an agreement and; verify that the e-mail address belongs to the domain of the subscriber.” The reason why PKIoverheid deprecated the use of an email address is because of security concerns. Firstly, including an email address in a certificate severely weakens the PKI model with regard to privacy. Secondly, including email addresses in certificates can lead to spam attacks. With regard to the second requirement: “…and the email certificates should be usable within the Mozilla context/products (e.g. Thunderbird).”: Section 3 from RFC 5750 (http://tools.ietf.org/html/rfc5750#section-3) states that ...”End-entity certificates MAY contain an Internet mail address…” …..”Receiving agents MUST recognize and accept certificates that contain no email address.” ……”Receiving agents MUST check that the address in the From or Sender header of a mail message matches an Internet mail address, if present, in the signer's certificate, if mail addresses are present in the certificate. A receiving agent SHOULD provide some explicit alternate processing of the message if this comparison fails, which may be to display a message that shows the recipient the addresses in the certificate or other certificate details. A receiving agent SHOULD display a subject name or other certificate details when displaying an indication of successful or unsuccessful signature verification.” The question is does Tbird comply with the requirements and recommendations as stated in section 3 from RFC 5750. Especially the recommendation “A receiving agent SHOULD provide some explicit alternate processing of the message if this comparison fails, which may be to display a message that shows the recipient the addresses in the certificate or other certificate details.” Does Tbird comply with this recommendation? The answer is: yes it does. See attachment 1 [details] [diff] [review]. In this situation a message is digitally signed. The sender has installed the cert without an email address as described at http://kb.mozillazine.org/Installing_an_SMIME_certificate. The only difference is that the cert automatically is installed at “Web Sites” instead of “Other People’s” within Tbird (because the email address is not included?). When the recipient receives the digitally signed message Tbird displays the following message: “Although the digital signature is valid, it is unknown whether sender and signer are the same person. The certificate used to sign the message does not contain an email address. Please look at the details of the signature certificate to learn who signed the message.” (Approximately the same message will be displayed when the sender signs using a cert including another email address than the email address the message was send from) This makes perfect sense. The recipient has to check the details in the certificate itself to check the identity of the sender. For example: the recipient can rely on a name or social security number all verified by the CA. In general PKI, there is no need for an application to check the consistency of, for example, an email address because the cert info itself is dominating. Given the message “Although the digital signature………. signed the message.” Tbird complies with the general PKI principal (the cert info is dominating) and with the S/MIME standard. See attachment 2 [details] [diff] [review]. Unfortunately it is not possible to encrypt a message with Tbird using a cert without an email address. However it is possible to decrypt a digitally signed and encrypted message with Tbird send from another email client (e.g. Outlook). When the recipient receives the digitally signed and encrypted message than Tbird displays the same message “Although the digital….. signed the message.” Furthermore it states that the message is encrypted (with the public key of the receiver). The message can be decrypted with the private key of the receiver placed on the smart card (by placing the smart card in the reader and entering the PIN). Summary: - It is possible to send and receive digitally signed messages in Tbird using certs without an email address; - No risks are involved and no harm is done to end users. Tbird displays a clear message when a certificate, that does not contain an email address, is used to sign the message. Tbird complies with the general PKI principal (the cert info is dominating) and with the S/MIME standard; - Encrypting a message with Tbird is not possible. Nevertheless it is possible to decrypt a digitally signed and encrypted message send from another email client. Again no risks are involved and no harm is done to end users. Tbird again displays a clear message. So certs without an email address can be used in the context of Mozilla products like Thunderbird. No risks are involved and no harm is done to end users. IMO the issue that remains is “does PKIoverheid/Staat der Nederlanden adequately verify the email addresses (in compliance with the Mozilla CA Policy) that we do put into certs, when we do?” Finally one could argue “why does PKIoverheid/Staat der Nederlanden want to have the email trust bit set if to their opinion Tbird can function, for the most part, with certs without an email address”. There are 3 main reasons/arguments: At this moment two CSPs within the PKIoverheid (UZI-register and Defensie) don’t include an email address in the certificate because of security concerns. PKIoverheid shares these security concerns but at the same time recognizes the fact that it is common practice to include email addresses in S/MIME certificates because this is the default situation for most applications like Tbird and Outlook. That is why the PKIoverheid policy states that the email address is deprecated BUT permitted in the SubjectAltName.rfc822Name field. Because other CSPs (ESG, DigiNotar and Getronics) within the PKIoverheid hierarchy do include an email address, it is highly desirable that the email trust bit is set for the Staat der Nederlanden Root CA - G2. The second reason is that it is not possible with Tbird to send an encrypted message using a cert without an email address. In addition to the former reason, if Tbird could be altered in a way as is possible with MS Outlook (http://support.microsoft.com/default.aspx?scid=kb;en-us;276597) than this would enhance interoperability between different email clients. IMO this could also be beneficial for the use and broader acceptance of Tbird. For example: it is to be expected that the coming years more and more eID citizen cards will be implemented in Europe. It is unlikely that certs distributed on those cards will contain a personal email address of the citizen because of privacy reasons. Furthermore if email addresses would be included than this would lead to a lot of reissuing of certs because citizens tend to change their personal email address. For that reason it would be desirable that Tbird could handle certs without an email address the way MS Outlook does. Regards Mark
To summarize… The concern raised in this bug was that Staat der Nederlanden was not verifying that the subscriber owns/controls the email address to be included in the certificate. As per Comment #2, Staat der Nederlanden updated their practices and CP to address this concern. Then a question was asked if the email trust bit should remain enabled. Comment #5 explains why Staat der Nederlanden wants to keep the email trust bit enabled. Note that bug #436056 has been approved for adding the new Staat der Nederlanden root certificate to NSS, and enabling the websites and code signing trust bit. If desired, Staat der Nederlanden may file a new bug to request that the email trust bit be enabled for the new root certificate. I have filed bug #551248 for the Thunderbird feature request to allow users to encrypt messages with a cert that does not include an email address. I believe that this bug has resolved.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
(In reply to comment #2) Kathleen wrote: > After significant discussion, it was determined that Staat der Nederlanden’s > new practice of only allowing the email address in the > SubjectAltName.rfc822Name field, means that the certs cannot be used for > S/MIME within the context of Mozilla products like Thunderbird. Kathleen, I suppose that discussion took place in one of our newsgroups. Please cite the particular thread (say, in google groups) or message where that determination was made. Thanks.
> Please cite the particular thread http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/2fa60c3f2bdc18ee# The discussion thread is called “Staat der Nederlanden Root Inclusion Request”
You need to log in before you can comment on or make changes to this bug.