2019年3月21日木曜日 16時27分46秒 UTC+1 Ryan Sleevi: > On Thu, Mar 21, 2019 at 9:42 AM tadahiko.ito.public--- via > dev-security-policy <dev-security-policy@lists.mozilla.org> 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... >
Thanks to provide me the scope and your concern. It seems clear for me. > (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" > Thanks for your answer. so far for me, interpretation of that explanations seems very ambiguous. When I read RFC, I thought "MAY" meant the former. (to support ECIES and further forward compatibilities ) As same time, I do agree the latter interpretation of "MAY" should be sensible with the webPKI framework. Fortunately, I am attending IETF right now. so I will ask people who is confident with wording on RFCs. Their opinion should help the future of corresponding. > 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
