Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates
Section 6 ("Revocation") of Mozilla's Root Store Policy states:
CAs MUST revoke Certificates that they have issued upon the occurrence of
> any event listed in the appropriate subsection of section 4.9.1 of the
> Baseline Requirements, according to the timeline defined therein.
>
Because the BRs don't apply to intermediate and end-entity certificates
that are constrained to S/MIME, it's not clear if our policy requires that
those certificates follow the BR revocation requirements or not.
The discussion [1] that led to the current language makes it clear that the
intent is for the revocation requirement to apply to S/MIME certificates.
I propose adding the following statement to clarify the scope of this
section:
This requirement applies to certificates that are not otherwise required to
> comply with the BRs.
This is https://github.com/mozilla/pkipolicy/issues/166 and
https://github.com/mozilla/pkipolicy/issues/167
I will appreciate everyone's input on this proposal.
- Wayne
[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/eAy0lxgFHR8/g6Jddy40EAAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement
In version 2.6 of our Root Store Policy, we added the requirement to section 5.3 that intermediate certificates contain an EKU and separate serverAuth and emailProtection uses. Version 2.6.1 updated the requirement to exclude cross certificates [1]. Last month, an issue [2] was filed requesting that we add "Policy Certification Authorities" (PCAs) as another exception. PCAs are described in RFC 5280 as a CA certificate that is only used to issue other CA certificates, so excluding PCAs from this requirement would not in theory weaken it. However, I'm not aware of any way to technically enforce that PCAs not issue end-entity certificates, and allowing more exceptions would seem to make this policy more difficult to enforce. In addition, RFC 5280 section 3.2 appears to reference PCAs as an example of an architecture that should be abandoned in favor of x509v3 certificate extensions: With X.509 v3, most of the requirements addressed by RFC 1422 can be addressed using certificate extensions, without a need to restrict the CA structures used. In particular, the certificate extensions relating to certificate policies obviate the need for PCAs... This is https://github.com/mozilla/pkipolicy/issues/172 I will appreciate everyone's input on this proposal. - Wayne [1] https://github.com/mozilla/pkipolicy/commit/a8353e12db6128d9a01de7ab94949180115a2d92 [2] https://github.com/mozilla/pkipolicy/issues/172 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Policy 2.7 Proposal: CA Certificate Binding to Policy Documents
The required practice "Publicly Available CP and CPS" [1] states: The CP/CPS must clearly indicate which root and subordinate certificates > the practices and processes described in those documents apply to. This can be done in (at least) two ways: * the policy document can unambiguously list the specific CA certificates within its scope * the CA certificate can contain one or more policy OIDs that are referenced in the applicable policy documents I have found that many CP/CPSes don't clearly list the certificates that are in-scope, and the binding between policy OIDs in subordinate CA certificates and CP/CPSes is often unclear when the CA has multiple policy documents. My concern is that this could lead to situations where a CA can pick and choose policies to argue that a given certificate is compliant. However, BR section 7.1.2.3 already requires each end-entity certificate to include "A Policy Identifier, defined by the issuing CA, that indicates a Certificate Policy asserting the issuing CA's adherence to and compliance with these Requirements." I'm much more interested in compliance with the BRs and Mozilla policy than the CA's own CPS, so this mitigates my concern. Even though I don't think this is as important now that I've given it some thought, I propose moving the following required practice into section 3.3 "CPs and CPSes" of our policy: CPs and CPSes must clearly indicate which root and intermediate > certificates the practices and processes described in those documents apply > to. > This is https://github.com/mozilla/pkipolicy/issues/171 I will appreciate everyone's input on this proposal. - Wayne [1] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Clarify Section 5.1 ECDSA Curve-Hash Requirements
On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi wrote: > > On Mon, Apr 22, 2019 at 6:20 PM Brian Smith wrote: > >> There are three (that I can think of) sources of confusion: >> >> 1. Is there any requirement that the signature algorithm that is used to >> sign a certificate be correlated in any way to the algorithm of the public >> key of the signed certificate? AFAICT, the answer is "no." >> >> 2. What combinations of public key algorithm (RSA vs. ECDSA vs EdDSA), >> Curve (N/A vs. P-256 vs P-384 vs Ed25519), and digest algorithm (SHA-256, >> SHA-384, SHA-512) are allowed? This is quite difficult to get *precisely* >> right in natural language, but easy to get right with a list of encodings. >> >> 3. Given a particular combination of algorithm, curve, and digest >> algorithm, which encodings of that information are acceptable? For example, >> when a a NULL parameter required and when is it optional. Again, this is >> hard to get right in natural language, and again, listing the encodings >> makes this trivial to get exactly right. >> >> Agreed - is someone willing to take on this task? >>> >> >> I could transform what I did with webpki into some text. >> >> However, first I think it would be useful if somebody could check that >> the encodings that webpki expects actually match what certificates in >> Certificate Transparency are doing. For example, does every CA already >> encode a NULL parameter when one is required by RFC 4055 (which is included >> by reference from RFC 5280)? Are there any algorithm combinations in use >> that aren't in webpki's list? This is something I don't have time to >> thoroughly check. >> > > I agree with Brian here, unsurprisingly. Luckily, my colleague, David > Benjamin, had some time to do just what Brian proposes. > > The following pull request - https://github.com/mozilla/pkipolicy/pull/183 - > demonstrates an attempt to resolve those three questions highlighted by > Brian. > > Thank you David and Ryan! This appears to me to be a reasonable improvement to our policy. Brian: could I ask you to review the proposed change? > This does not, however, address the last part of what Brian proposes - > which is examining if, how many, and which CAs would fail to meet these > encoding requirements today, either in their roots, subordinates, or leaf > certificates. > > While I agree that this would be useful information, for the purpose of moving ahead with this policy change would it instead be reasonable to set an effective date and require certificates issued (notBefore) after that date to comply, putting the burden on CAs to verify their implementations rather than relying on someone else to do that work? While this includes RSA-PSS, it's worth noting that mozilla::pkix does not > support these certificates, and also worth noting that the current encoding > scheme is substantially more verbose than desirable. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
