Extension KeyUsage in Subscriber's Certificate

[Lijun Liao]

The extension KeyUsage in subscriber's certificate SHOULD be marked as
critical as in RFC 5280. What if it is not set? Does this violate the
Baseline Requirements or any rules used by Mozilla Security Policy?

Best regards
Lijun

[Ryan Sleevi]

1. Open
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.4.pdf
2. Search for "KeyUsage"
- 11 occurrences

#1
7.1.2.1 Root CA Certificate
b. keyUsage
This extension MUST be present and MUST be marked critical ...

#3
7.1.2.2 Subordinate CA Certificate
e. keyUsage
This extension MUST be present and MUST be marked critical ...

#5
7.1.2.3. Subscriber Certificate
e. keyUsage (optional)
If present, bit positions for keyCertSign and cRLSign MUST NOT be set.

3. Answer question :)

[Lijun Liao]

Just makes it clear: The extension KeyUsage is optional in subscriber's
certificate. But what happens if it is present and is NOT critical?

[Ryan Sleevi]

On Tue, Apr 9, 2019 at 10:39 AM Lijun Liao <lijun...@gmail.com> wrote:

> Just makes it clear: The extension KeyUsage is optional in subscriber's
> certificate. But what happens if it is present and is NOT critical?
>

RFC 5280 says SHOULD, not MUST. RFC 2119 defines SHOULD as:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course

I think, in such an event, a CA may be reasonably asked to provide details
about what the valid reasons of the particular circumstances were to
deviate from that SHOULD, and how the full implications were understood and
weighed.

[Lijun Liao]

Let us consider the case that the CA unsets the critical flag unintendedly,
e.g. using the default configuration. Which means there are no explizit
reasons. Is it required that the CA to create an incident report to mozilla?

[Matt Palmer]

On Wed, Apr 10, 2019 at 08:55:27AM +0200, Lijun Liao via dev-security-policy wrote:
> Let us consider the case that the CA unsets the critical flag unintendedly,
> e.g. using the default configuration. Which means there are no explizit
> reasons. Is it required that the CA to create an incident report to mozilla?

My expectation would be "yes", as the CA has failed to adhere to RFC5280.

- Matt

[Wayne Thayer]

I'm either confused, or I disagree. We're talking about a certificate that
deviates from a "SHOULD" in RFC 5280, correct? Our guidance on incidents
[1] defines misissuance, in part, as "RFC non-compliant". The certificate
as described strictly complies with RFC 5280 (and presumably all other
policies). In this circumstance, I do not expect an incident report.

Having said that, I would be pleased if a CA voluntarily published an
incident report explaining how the mistake happened and steps taken to
learn and improve. That level of transparency would be seen as a positive
rather than a mark against the CA.

- Wayne

[1] https://wiki.mozilla.org/CA/Responding_To_An_Incident

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Ryan Sleevi]

On Wed, Apr 10, 2019 at 12:23 PM Wayne Thayer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I'm either confused, or I disagree. We're talking about a certificate that
> deviates from a "SHOULD" in RFC 5280, correct? Our guidance on incidents
> [1] defines misissuance, in part, as "RFC non-compliant". The certificate
> as described strictly complies with RFC 5280 (and presumably all other
> policies). In this circumstance, I do not expect an incident report.
>
> Having said that, I would be pleased if a CA voluntarily published an
> incident report explaining how the mistake happened and steps taken to
> learn and improve. That level of transparency would be seen as a positive
> rather than a mark against the CA.
>
> - Wayne
>
> [1] https://wiki.mozilla.org/CA/Responding_To_An_Incident

I don't think you're confused Wayne, and I'd agree. Deviation from a SHOULD
is not, in and of itself, an incident. It's not unreasonable that members
of the community might detect that and ask why, but I don't think that
makes it a mistake, so much as a curiousity. That said, I do agree that CAs
that deviate from SHOULDs, intentionally or unintentionally, benefit from
being transparent about this, as it helps build understanding about
potentially unmet use cases, find alternatives (for example, if deviation
would pose an interoperability risk, despite being a SHOULD), or just
generally be a demonstration of the CA's own monitoring and compliance
regime that it notices such deviations.

Having more systematic sharing of knowledge is, I think, a net benefit to
the community - and even unintentional situations, whether detected
internally or externally, provide extremely valuable learning opportunities
that help protect against deviations from MUSTs :)

[Mirro]

在 2019年4月10日星期三 UTC+8下午2:55:50，Lijun Liao写道：

For the $4.2.1.3. Key Usage in RFC 5280 says:
Conforming CAs MUST include this extension in certificates that contain public keys that are used to validate digital signatures on other public key certificates or CRLs. When present, conforming CAs SHOULD mark this extension as critical.

The certificates that contain public keys that are used to validate digital signatures on other public key certificates or CRLs are CA certificates, not subscriber certificates. So in my opinion the requirement in RFC 5280 is for the CA certificates. Since there are both not a RFC non-compliant and BR non-compliant when it is not marked as critical in subscriber certificates, an incident report is not required.


Mirro