On Thu, Mar 21, 2019 at 9:42 AM tadahiko.ito.public--- via dev-security-policy <[email protected]> wrote:
> Hi I have few questions about Mozilla Root Store Policy 5.1 > > Mozilla Root Store Policy 5.1 only permits following algorithms for ECC. > > > 5.1 Algorithms > > > > Root certificates in our root program, and __any certificate__ which > > chains up to them, __MUST__ use __only__ algorithms and key sizes from > the following set: > > > > RSA keys whose modulus size in bits is divisible by 8, and is at > least 2048. > > Digest algorithms: SHA-1 (see below), SHA-256, SHA-384, or SHA-512. > > ECDSA keys using one of the following curve-hash pairs: > > P-256 with SHA-256 > > P-384 with SHA-384 > > > I am wondering the above is for validation path only, or also for usage of > EE certificate. > #I thought it might be also for EE cert, since RFC5480 does not require > anything on key usage(I descrive detail at the bottom of this text). > During the discussion in which it was introduced, the goal was two-fold: 1) Restrict the set of SubjectPublicKeyInfos to ones supported by Mozilla policy and appropriate for Mozilla users 2) Restrict the set of SignatureAlgorithms to ones supported by Mozilla policy and appropriate for Mozilla Users This would apply to all certificates in the certification path. This is also why DSA keys (and signatures) are excluded, even though they are permissible under the Baseline Requirements. A clearer rewording of this section may be to specifically enumerate the allowed SubjectPublicKeyInfo AlgorithmIdentifiers (for all certificates in the chain) and the signatureAlgorithm AlgorithmIdentifiers (for all certificates in the chain). The current language was modeled after the Baseline Requirements structure, which similarly conflates these two fields. > As far as I understand, ECDSA public key just show a point on elliptic > curve. that point can also be used (plain)ECDH or ECIES. > So, if 5.1's description is also for end entity cert, EE cert's key-usage > must contain digitalSignature, can contain nonRepudiation, and must not > contain key agreement, key encipherment, etc. to comply 5.1. > > (question.1) > So far I guess, that statement of 5.1 include requirement for key-usage of > any EE certs, not limit to server certificates. is it correct? > To make sure I understand the scenarios: A) The EE certificate does not contain an EKU extension B) The EE certificate contains an EKU extension, and DOES NOT contain id-kp-serverAuth C) The EE certificate contains an EKU extension, and DOES contain id-kp-serverAuth I) The Intermediate certificate does not contain an EKU extension II) The Intermediate certificate contains an EKU extension, and DOES NOT contain id-kp-serverAuth III) The Intermediate certificate contains an EKU extension, and DOES contain id-kp-serverAuth I break this down, because the following combinations have historically been considered "not server certificates": I+B, II+(A, B, C), III+B While the following have been considered in scope for policy: I+(A,C), III+(A, C). Similarly, the issuance practices of I+(A, B, C) and III+(A, B, C) have all been considered subject to the BRs; the most notable example of this is using SHA-1 to sign EE certificates that aren't server certificates (but the intermediate CA's key is capable of issuing them). This is where the language "any certificate which chains up to them" comes from. Your question - what are the permissible key usages extensions - is similar to the I+(A, B, C) / III+(A, B, C) scenario. Considering the keyUsage extension specifically (i.e. not considering the signatureAlgorithm nor the SubjectPublicKeyInfo algorithm) strikes me as fitting in the I+B, II+(A, B, C), III+B scenario. There's a legitimate question about whether it should apply in the I+B/III+B scenario (i.e. the intermediate is technically capable of issuing TLS certificates, but this certificate happens to be not-TLS), but I would think for the II+(A, C) scenario it should be OK to declare it out of scope. I'm nervous about the II+B scenario, since you could always issue a version of II` that set a different EKU... (question.2) > In addition, if CA issue ECC certificate without appropriate key-usage, > reason to revoke can be non-compliance with Mozilla's root program? > > > RFC 5480 does not seems to require anything for key-usage #since, RFC 2119 > state MAY is "truely optional" > > RFC 5480 ECC SubjectPublicKeyInfo Format March 2009 > > > > If the keyUsage extension is present in an End Entity (EE) > > certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo, > > then any combination of the following values MAY be present: > > > > digitalSignature; > > nonRepudiation; and > > keyAgreement. > This is a great question! If the certificate is in scope of the BRs (i.e. the intermediate is either I or III), then we know Subscriber certificates MUST have a Key Usage (7.1.2.3(e) of the BRs). >From RFC 5280, Section 4.1.2.3, we know "When the keyUsage extension appears in a certificate, at least one of the bits MUST be set to 1." >From RFC 5280, Section 4.2.1.12, we know that if an EKU asserts id-kp-serverAuth (so (I, II, III)+C), then you're restricted to "digitalSignature, keyEncipherment, or keyAgreement" (those are the only consistent values enumerated) >From RFC 5246, 7.4.2 (and RFC 8446, Section 4.4.2.2), we can also see further restrictions on the allowed key usage bits of server certificates; this is not strictly an issuing prohibition, but worth considering. We can see through RFC 3279, 4055, 5756, 4491, 5480, and 5758 the relevant keyUsages for a variety of algorithms, such as RSA, DSA, and of course, EC. If I understand this question correctly, it's asking about whether the MAY of values (X, Y, Z) means SHALL NOT/MUST NOT for values (A, B, C). One interpretation says "You may set these values... or any other value". The MAY tells clients what they should be prepared for, potentially allowing them to reject any value outside of that if they're unprepared for it. Another interpretation says "These are the ONLY values that MAY be present. You MAY assert one or more of them, but you MUST NOT assert something else" While I have thoughts on "what is sensible", I'm not sure if that's aligned with "what is required", so I'm hoping to make sure I've understood both the questions correctly and provided the citations, to get feedback from other members of this community. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
