Questions about Mozilla Root Store Policy 5.1

[tadahiko....@gmail.com]

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).

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?

(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.

Regards Tadahiko Ito

[Ryan Sleevi]

On Thu, Mar 21, 2019 at 9:42 AM tadahiko.ito.public--- via
dev-security-policy <dev-secur...@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...

(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.

[Tadahiko Ito]

Thanks to provide me the scope and your concern.
It seems clear for me.

Thanks for your answer.
so far for me, interpretation of that explanation seems very ambiguous.

When I read RFC, I thought "MAY" mean 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 responding.

[Tadahiko Ito]

> > 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"
> >

it seems we do have ambiguity. I talk with author, and I believe RFC will be fixed relatively soon.
<https://mailarchive.ietf.org/arch/msg/spasm/32KJmCburr6tWciJHTjfv5piRxI>

Tadahiko Ito