Re: When to accept/require revised audits for missing cert fingerprints
I have updated the "Acceptable remediation" section of https://wiki.mozilla.org/CA/Audit_Letter_Validation#Intermediate_Certificates as follows. I will greatly appreciate your review and input on this. ~~ Acceptable remediation: Remediation may include one of the following when a non-technically-constrained intermediate certificate is missing from an audit statement. Note that Mozilla's Root Store Policy says: "If the CA has a currently valid audit report at the time of creation of the certificate, then the new certificate MUST appear on the CA's next periodic audit reports." - Have your auditor issue a revised report that includes the intermediate certificate. -- This will not be an acceptable remediation if the certificate has been in existence for past audit periods. -- This is an acceptable remediation when the certificate is self-signed and has the same Subject and SPKI as other certificates listed in the audit statement. For example, this can happen when Mozilla includes one version of a root certificate, but another version of the root certificate can be part of a valid chain constructed as: leaf --> untrusted root --> trusted root. - Revoke the intermediate certificate in accordance with Mozilla's Root Store Policy. -- If your CA decides not to revoke the certificate within the timeline specified by section 4.9 of 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. ~~ Thanks, Kathleen ___ 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 Fri, Feb 7, 2020 at 12:27 PM Dimitris Zacharopoulos via dev-security-policy wrote: > Finally, I don't think auditor professional ethics have anything to do > with this discussion. Both audit schemes allow for reports to be updated > otherwise we wouldn't even have this option on the table. Challenging > audit schemes is good and healthy but should probably be on a separate > thread with specific concerns raised. The professional ethics and standards are extremely relevant to this thread, because it's essential to understand what assurance a revised report provides. That is, it's incorrect to assume a revised report provides the same level of assurance as an original report, without understanding the professional standards and ethics involved. The absence of such standards and guidance, from ETSI, is further extremely relevant to understanding what levels of assurance the initial report provides, why an initial report may make mistakes, and what the implications are about an updated report. More importantly, much like delaying revocation, it *shouldn't* be an option. The notion of revising a report is apparently without consequence to ETSI, but is of significant impact to WebTrust, and that's an extremely relevant factor to this discussion. ___ 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
For what it's worth, I think that there should be two distinct cases: a) Self-signed Certificates that have the same SPKI and name, but only one was ever requested to be included as a Trust Anchor in the Mozilla Root Program, b) Variations of Issuing CA Certificates that have the same SPKI and name. For b), the rules of disclosure in the Mozilla Policy were very clear and unambiguous. I would expect all versions of b) to be included in audit reports. For a), in my understanding, if the CA only requested one version of the Root CA Certificate to be included, the possible other versions could "theoretically" be considered "Intermediate" CA Certificates but they are self-signed and effectively do not transfer any trust over, unless I am missing something. So, when the disclosure requirement was drafted in the policy, I don't think it was ever intended for CAs to disclose all variations of their Root CA Certificates that share the same SPKI and name. Wayne and Kathleen, as module owners, could confirm if this is true or not. If CAs were intended to add all variations of their self-signed Root CAs, it would have been highlighted and discussed on this list as a corner case (I can't remember if this corner case was discussed when writing the disclosure policy). And even if CAs wanted to disclose these in CCADB, it was counter-intuitive to add a self-signed Root as an Intermediate. It is possible that a CA issued two or more variations of their Root CA Certificate, changing extensions and other information if they detected that something was incorrect. IMHO that should not effect anything because at the end of the day, the Trust Anchor is the one that matters. I also can't think of a "bad actor" case for a) that could take advantage of this theoretical "gap" to cause any security risks, but perhaps others could. With that said, I believe there should be some guidance on the wiki of CCADB or Mozilla Policy that describe this corner case and have a process for adding "variations" of such self-signed certificates as "Intermediate CA" Certificates (when most people are used to see them as self-signed "Root CA" Certificates). As long as the SPKI and name is included in consecutive audit reports from the creation of one of those variations, there should be a grace period allowing the other variations to be disclosed and be included in future audit reports. It would be causing "pain" to CAs and auditors to update existing audit reports to retroactively disclose such cases, for no good reason. I am not sure if adding one of the self-signed Root CA variations in the OneCRL (not the one included as a Trust Anchor) would cause any harm to the properly disclosed and audited hierarchy. Could someone please clarify that? Finally, I don't think auditor professional ethics have anything to do with this discussion. Both audit schemes allow for reports to be updated otherwise we wouldn't even have this option on the table. Challenging audit schemes is good and healthy but should probably be on a separate thread with specific concerns raised. Thank you, Dimitris. On 2020-02-07 6:00 μ.μ., Wayne Thayer via dev-security-policy wrote: On Thu, Feb 6, 2020 at 5:44 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: 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. I'd like to see Mozilla require an incident report from CAs that can't or won't follow the existing guidance (by either supplying a revised audit statement, revoking the certificate, or adding it to OneCRL). A number of CAs have resolved these issues by following this guidance and I recommend against adding a grace period at this time for those who have not. This places the onus on the CA to ensure their audit reports will meet Mozilla’s requirements. In the future, I expect ALV to catch these issues as soon as the audit report is published. Mistakes do happen, and I don't think our policy should go straight to revocation upon an ALV failure due to an audit statement error. 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? I realize Mozilla uses OneCRL to address the gap there, but ostensibly this is a straight BR violation regarding providing continuous audits. The proposed revisions will make this unambiguously clearer, but either way, the best path to protect the most users is to require the CA to revoke such certificates. This also hopefully has the desired effect of forcing
Re: When to accept/require revised audits for missing cert fingerprints
On Fri, Feb 7, 2020 at 11:00 AM Wayne Thayer wrote: > I'd like to see Mozilla require an incident report from CAs that can't or > won't follow the existing guidance (by either supplying a revised audit > statement, revoking the certificate, or adding it to OneCRL). A number of > CAs have resolved these issues by following this guidance and I recommend > against adding a grace period at this time for those who have not. > Right, apologies if it wasn't clearer: I was suggesting that the existing guidance be the one granted the grace period (with the expectation that folks follow) Following that grace period, the option becomes revoking the certificate. > > I realize Mozilla uses OneCRL to address the gap there, but ostensibly this >> is a straight BR violation regarding providing continuous audits. The >> proposed revisions will make this unambiguously clearer, but either way, >> the best path to protect the most users is to require the CA to revoke >> such >> certificates. >> >> This also hopefully has the desired effect of forcing CAs to pay closer >> attention to the requirements placed on them, and ensure that the >> negotiate >> and scope their audits to ensure they’re actually meeting those >> requirements. >> >> > I agree, but I also think that ALV will cause these issues to be caught > and quickly corrected in the future (assuming the CA has properly disclosed > all CA certificates). > I agree, ALV will catch these sooner. I took Kathleen's question to be primarily about "How do we handle CAs that have had undetected problems", and my point is that this should only be temporary. ___ 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 Thu, Feb 6, 2020 at 5:44 PM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: 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. > > I'd like to see Mozilla require an incident report from CAs that can't or won't follow the existing guidance (by either supplying a revised audit statement, revoking the certificate, or adding it to OneCRL). A number of CAs have resolved these issues by following this guidance and I recommend against adding a grace period at this time for those who have not. This places the onus on the CA to ensure their audit reports will meet > Mozilla’s requirements. > > In the future, I expect ALV to catch these issues as soon as the audit report is published. Mistakes do happen, and I don't think our policy should go straight to revocation upon an ALV failure due to an audit statement error. 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? > > I realize Mozilla uses OneCRL to address the gap there, but ostensibly this > is a straight BR violation regarding providing continuous audits. The > proposed revisions will make this unambiguously clearer, but either way, > the best path to protect the most users is to require the CA to revoke such > certificates. > > This also hopefully has the desired effect of forcing CAs to pay closer > attention to the requirements placed on them, and ensure that the negotiate > and scope their audits to ensure they’re actually meeting those > requirements. > > I agree, but I also think that ALV will cause these issues to be caught and quickly corrected in the future (assuming the CA has properly disclosed all CA certificates). ___ 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 Fri, Feb 7, 2020 at 7:55 AM douglas.beattie--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, February 6, 2020 at 6:05:20 PM UTC-5, Ryan Sleevi wrote: > > (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? > > I agree with your description of where S/MIME email addresses must go, but > I don't agree with your last statement that an email address "MUST NOT > appear in any other field". More below. > > > 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? > > While it's not necessary for S/MIME, it's common to use an S/MIME > certificate for both secure mail and client authentication (and even other > things like ipSEC, file encryption etc). > > 1) Many/most CAs include both secure mail and client auth EKUs to permit > such use. Is including the client auth EKU not permitted because it's not > needed for S/MIME? Ideally, no, for the same reason we don’t have S/MIME certificates that are TLS certificates. Doesn’t Microsoft policy explicitly forbid this? Certainly, a future Mozilla policy would ideally forbid this. 2) When using this S/MIME certificate for client authentication to a > corporate system, the subjectAltName:UPN may be needed. The UPN typically > contains an email address which may be the same, or may be different from > the one in subjectAltName:rfc822Name. Since the UPN is not used for > S/MIME, then its value should be opaque to S/MIME clients and the > validation of this field should not need to follow the Mozilla policy for > email validation. I don’t agree with this. While not processed by clients, the inclusion of this information still represents a risk of different certificate profiles being used causing incompatibilities (e.g. revoking for S/MIME non-compliance will almost certainly be delayed due to it impacting the smart-card sign-on scenario), and will almost certainly mislead users who look to examine other identity information that may be present (e.g. in the Subject) To solve that, either we: 1) Guarantee the certificate is never displayed to the user so they are never mislead, thus defeating the goal of CAs in including such information in the Subject Or 2) Forbid the inclusion of these fields 3) Is including an email within a private extension not permitted, perhaps > for a special usecase outside of S/MIME? Today, the CA is required to validate that, which caused ambiguities as you note. As proposed, it would be forbidden, which handily resolves this and other issues. 4) Is including an email address in any other subject field (there is a > long list of subject fields in https://tools.ietf.org/html/rfc4519) not > validated in accordance with the policy prohibited in S/MIME certificates? As worded, yes. Can you clarify what interpretation would state this is acceptable? Since S/MIME applications use the email address only in the 3 fields you > listed, is including it elsewhere an issue? Given there are no standards > for the validation or use of an email address in any field (including the 3 > used for S/MIME) when the secure mail EKU is NOT included, is there an > issue when including email addresses in fields outside of those 3 when the > certificate contains the secure mail EKU? If it contains the EKU, I think such fields other than those three should be prohibited. And I’m not even convinced it should be allowed in the subject, given the issues it poses to nameConstraints and ambiguities for clients. If it does not contain the EKU, or contains an unrelated EKU in addition, then it should not be coming from a trusted hierarchy. That is the only sensible end-state that looks to learn from the past twenty years of the Web PKI. I posted my proposed change to the Mozilla policy here: >
Re: Which fields containing email addresses need to be validated?
On Thursday, February 6, 2020 at 6:05:20 PM UTC-5, Ryan Sleevi wrote: > (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? I agree with your description of where S/MIME email addresses must go, but I don't agree with your last statement that an email address "MUST NOT appear in any other field". More below. > 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? While it's not necessary for S/MIME, it's common to use an S/MIME certificate for both secure mail and client authentication (and even other things like ipSEC, file encryption etc). 1) Many/most CAs include both secure mail and client auth EKUs to permit such use. Is including the client auth EKU not permitted because it's not needed for S/MIME? 2) When using this S/MIME certificate for client authentication to a corporate system, the subjectAltName:UPN may be needed. The UPN typically contains an email address which may be the same, or may be different from the one in subjectAltName:rfc822Name. Since the UPN is not used for S/MIME, then its value should be opaque to S/MIME clients and the validation of this field should not need to follow the Mozilla policy for email validation. 3) Is including an email within a private extension not permitted, perhaps for a special usecase outside of S/MIME? 4) Is including an email address in any other subject field (there is a long list of subject fields in https://tools.ietf.org/html/rfc4519) not validated in accordance with the policy prohibited in S/MIME certificates? Since S/MIME applications use the email address only in the 3 fields you listed, is including it elsewhere an issue? Given there are no standards for the validation or use of an email address in any field (including the 3 used for S/MIME) when the secure mail EKU is NOT included, is there an issue when including email addresses in fields outside of those 3 when the certificate contains the secure mail EKU? I posted my proposed change to the Mozilla policy here: https://github.com/mozilla/pkipolicy/issues/200 Maybe this will be addressed as part of the S/MIME Certificate working group and we can wait until then. > 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. No, not for S/MIME. Yes for when an S/MIME certificate is used for S/MIME and other purposes. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
