On Thu, Mar 21, 2019 at 9:42 AM tadahiko.ito.public--- via
> 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.
> 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
C) The EE certificate contains an EKU extension, and DOES contain
I) The Intermediate certificate does not contain an EKU extension
II) The Intermediate certificate contains an EKU extension, and DOES NOT
III) The Intermediate certificate contains an EKU extension, and DOES
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),
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
> 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
(22.214.171.124(e) of the BRs).
>From RFC 5280, Section 126.96.36.199, 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 188.8.131.52, 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 184.108.40.206), 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
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.