Which fields containing email addresses need to be validated?
The Mozilla policy section 2.2 says: * . the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate. Since the Mozilla policy only applies to certificates with the EKU of Secure Mail (ignoring TLS in this discussion), it would seem to imply that only email addresses that could be used for sending or receiving signed or encrypted emails would be in scope. It's not against Mozilla policy to issue certificates with unvalidated email addresses in any field as long as the Secure Mail EKU is not included, so the intent should be to validate only those that are used for Secure Mail. As far as I know, the only fields that could be used by S/MIME applications are the CN, Email, and RFC822 SAN fields. We should clarify the Mozilla policy to more clearly define list of fields containing email address (those 3 listed above) must be validated in section 2.2 so that this is clear and concise. Wayne opened this issue in December and I just replied with a comment related to the validation requirements of SAN/Other Name/UPN: https://github.com/mozilla/pkipolicy/issues/200 smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Which fields containing email addresses need to be validated?
On Thu, Feb 06, 2020 at 08:54:04PM +, Doug Beattie via dev-security-policy wrote: > It's not against Mozilla policy to > issue certificates with unvalidated email addresses in any field as long as > the Secure Mail EKU is not included, so the intent should be to validate > only those that are used for Secure Mail. Any field in the certificate should be validated. If it contains an email address, it should be validated. If it's not validated, it should get removed. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Which fields containing email addresses need to be validated?
I don't agree that the CA MUST validate EVERY field. CAs leverage enterprise RAs to validate some information in SMIME certificates, e.g., the subscribers name in the CN field because the CA can't readily validate that. I believe the same is true for some other fields like the UPN which is the active directly account, but I thought I'd start a discussion to see what people thought. Doug -Original Message- From: Kurt Roeckx Sent: Thursday, February 6, 2020 4:06 PM To: Doug Beattie Cc: mozilla-dev-security-policy Subject: Re: Which fields containing email addresses need to be validated? On Thu, Feb 06, 2020 at 08:54:04PM +, Doug Beattie via dev-security-policy wrote: > It's not against Mozilla policy to > issue certificates with unvalidated email addresses in any field as > long as the Secure Mail EKU is not included, so the intent should be > to validate only those that are used for Secure Mail. Any field in the certificate should be validated. If it contains an email address, it should be validated. If it's not validated, it should get removed. Kurt smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Which fields containing email addresses need to be validated?
On Thu, Feb 06, 2020 at 09:31:40PM +, Doug Beattie via dev-security-policy wrote: > I don't agree that the CA MUST validate EVERY field. CAs leverage > enterprise RAs to validate some information in SMIME certificates, e.g., the > subscribers name in the CN field because the CA can't readily validate that. I don't care who does the validation, just that it's validated. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Which fields containing email addresses need to be validated?
(Replying from the correct e-mail) On Thu, Feb 6, 2020 at 3:55 PM Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > We should clarify the Mozilla policy to more clearly define list of fields > containing email address (those 3 listed above) must be validated in > section > 2.2 so that this is clear and concise. > Doug, Is the proposal that, similar to how TLS defines that domain names MUST appear within the SAN:dNSName, that emailAddresses MUST appear within one of those three fields (that is: subject:commonName, subject:emailAddress, subjectAltName:rfc822Name), that any value in the subject MUST also appear in the subjectAltName, and an emailAddress MUST NOT appear in any other field? That would address the concern, correct? Wayne opened this issue in December and I just replied with a comment > related to the validation requirements of SAN/Other Name/UPN: > > https://github.com/mozilla/pkipolicy/issues/200 I'm not sure I understand your question on this issue, and was hoping you could expand. As you note, it's not used within S/MIME, so presumably, it's not necessary for an S/MIME certificate, and thus MUST NOT be included. That would resolve the ambiguity, correct? Are you aware of any system that requires a single certificate contain both in order to be used for S/MIME? If I understood your question right, it's not required. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: When to accept/require revised audits for missing cert fingerprints
On Tue, Feb 4, 2020 at 6:59 PM Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > All, > > https://wiki.mozilla.org/CA/Audit_Letter_Validation > currently says: > "" > Acceptable remediation for an intermediate certificate missing BR audits > may include one or more of the following: > > - Have your auditor issue a revised report that includes the > intermediate certificate. Note that if the certificate has been in > existence for multiple past audit periods, this will not be considered a > full remediation unless new reports are supplied for all of those > periods in which the certificate did not appear on the original reports. > > - Revoke the intermediate certificate in accordance with BR section > 4.9. If your CA decides not to revoke the certificate within the > timeline specified by the BRs, then that is another incident, which must > be addressed in a separate Incident Report. > > - If the intermediate certificate is technically capable but not > intended for TLS issuance, and revocation is not imminent, you may > request that Mozilla add it to OneCRL by adding a comment to the > Bugzilla bug with the request and sending email to Mozilla. Note: While > adding the certificate to OneCRL satisfies Mozilla's expectations for > remediation, it may not satisfy other root store programs. You are > advised to seek their guidance on this issue. > "" > > Questions: > > 1) Should we require a revised audit statement when it is missing the > SHA256 fingerprint of a cert that has the same Subject + SPKI as other > cert(s) listed in the audit statement? > For this situation, we have been requiring CAs to have their auditor > revise their current audit statements. But the question has come up > about when that is necessary, e.g. what if the CA is about to get their > next audit statement? Do they still need to get their previous audit > statement updated? If not, what would be the cut-off for not requiring > that the current audit statement get updated? Or is it only necessary > that future audit statements list the forgotten certs that have the same > Subject + SPKI as other audited certs? This is a tricky one. In theory, all of the key controls regarding issuance should be applied to all variants (“doppelgangers”). That is, a certificate issued by one version, even if not included in scope, would still exercise the same private key as the in-scope CA. There are some tortured readings, however, that an auditor may be convinced to sign-off on: For example, if the auditor did not examine or reconcile the HSM logs with the logs of the in-scope issued certificates, then it’s possible that one or more invalid certificates will not be detected, even though they’re valid and chain to the in-scope CA. In this model, we’re assuming the CA software and logs treat the two certificates, despite sharing the same subject and SPKI, as distinct, and the auditor only examines the logs of the in-scope version. Another example would be if the CA disclosed to the auditor that the certificate is expired, and thus the CA doesn’t examine issuance practices or acknowledges no certs issued for “that” CA, while the doppelganger is unexpired and the auditor doesn’t examine this. The detailed control reports from WebTrust would help with this, but only if they’d been used for the problematic audit, which no CA has done. A restated report would in theory help, but it still leaves it ambiguous where the auditor actually considered all of these edge cases, and it was just a clerical mistake, or if they failed to consider. The only sure way is to require revocation, not just of the doppelgänger, but of all variations of it, given the risk of historical certs still being valid. However, that’s also a huge disruption, and may require invalidating every single certificate from that CA! While I think we should be more regularly requiring CAs to create new clean hierarchies every few years, ALV is probably not the best trigger for that. My recommendation is that, for audit periods ending within the next 30 or so days (meaning, effectively, for reports provided over the next 4 months, given the three month window before reporting), such situations are accepted despite the limited assurance they provide. Following that - that is, for any audit afterwards, there is zero exception, and revocation is required. This places the onus on the CA to ensure their audit reports will meet Mozilla’s requirements. 2) Should we accept a revised audit statement to include the SHA256 > fingerprint of a certificate that was not previously listed and does not > have the same Subject + SPKI as other cert(s) listed in the audit > statement? Believe it or not, this is actually remarkably similar to “should we grant exceptions for revocation”. If the answer is “Yes”, CAs will pressure their auditors to do so. Auditors have significant professional guidelines making that difficult, at least within WebTrust
