Bonsoir,

Le lundi 7 octobre 2019 20:53:11 UTC+2, Ryan Sleevi a écrit :
[...]
> # Intermediates that do not comply with the EKU requirements
> 
> In September 2018 [1], Mozilla sent a CA Communications reminding CAs about
> the changes in Policy 2.6.1. One specific change, called to attention in
> ACTION 3, required the presence of EKUs for intermediates, and the
> separation of e-mail and SSL/TLS from the intermediates. This requirement,
> while new to Mozilla Policy, was not new to publicly trusted CAs, as it
> matched an existing requirement from Microsoft's Root Program [2]. This
> requirement was first introduced by Microsoft in July 2015, with their
> Version 2.0 of their own policy.
> 
> It's a reasonable expectation to expect that all CAs in both Microsoft and
> Mozilla's program would have been conforming to the stricter requirement of
> Microsoft, which goes above-and-beyond the Baseline Requirements. However,
> Mozilla still allowed a grandfathering in of existing intermediates,
> setting the new requirement for their policy at 2019-01-01. Mozilla also
> set forth certain exclusions to account for cross-signing.
> 
> Despite that, four CAs have violated this requirement in 2019:
> * Microsoft: https://bugzilla.mozilla.org/show_bug.cgi?id=1586847
> * Actalis: https://bugzilla.mozilla.org/show_bug.cgi?id=1586787
> * QuoVadis: https://bugzilla.mozilla.org/show_bug.cgi?id=1586792
> * NetLock: https://bugzilla.mozilla.org/show_bug.cgi?id=1586795
> 
> # Authority Key Identifier issues
> 
> RFC 5280, Section 4.2.1.1 [3], defines the Authority Key Identifier
> extension. Within RFC 5280, it states that (emphasis added)
> 
>    The identification MAY be based on ***either*** the
>    key identifier (the subject key identifier in the issuer's
>    certificate) ***or*** the issuer name and serial number.
> 
> That is, it provides an either/or requirement for this field.

If this is to be read as an exclusive choice, then how do you interpret third 
paragraph of clause 4.2:

   Conforming CAs MUST support key identifiers (Sections 4.2.1.1 and
   4.2.1.2), basic constraints (Section 4.2.1.9), key usage (Section
   4.2.1.3), and certificate policies (Section 4.2.1.4) extensions.

Does that mean that CAs MUST exclusively choose between keyIdentifier or 
issuerName+serialNumber, while at the same time use keyIdentifier? Just get rid 
of the issuerName+serialNumber, then.

Now go down to Appendix A.2 containing the ASN.1 module, you'll find some 
comments in the definition (that's the way lazy ASN.1 writers try to express 
constraints):

AuthorityKeyIdentifier ::= SEQUENCE {
    keyIdentifier             [0] KeyIdentifier            OPTIONAL,
    authorityCertIssuer       [1] GeneralNames             OPTIONAL,
    authorityCertSerialNumber [2] CertificateSerialNumber  OPTIONAL }
    -- authorityCertIssuer and authorityCertSerialNumber MUST both
    -- be present or both be absent

Here, again, the constraint is on presence or absence of both issuer and 
serial, nothing on presence of both keyIdentifier and the (issuer,serial) tuple.

> Despite this
> not being captured in the updated ASN.1 module defined in RFC 5912 [4],
> Mozilla Root Store Policy has, since Version 1.0 [5], included a
> requirement that CAs MUST NOT issue certificates that have (emphasis added)
> "incorrect extensions (e.g., SSL certificates that exclude SSL usage,
> or ***authority
> key IDs that include both the key ID and the issuer's issuer name and
> serial number)***;"

Isn't it strange that while RFC5912 modified the ExtendedKeyIdentifier 
definition to add ASN.1 constraints on presence or absence of both 
authorityCertIssuer/authorityCertSerialNumber elements, nothing has been added 
to extend the same constraint forbidding presence of keyIdentifier and 
issuer+serial? It would have been really easy if it was intended that way.

I'll let participants read X.509 clause 8.2.2.1/9.2.2.1/12.2.2.1 (depending on 
the edition you're reading) to discover that the ASN.1 definition is equal to 
RFC5912's one since 1997 (first edition of X.509v3), and find that both 
keyIdentifier and issuer+serial are explicitly permitted (given that all is 
consistent). That's 6 successive revisions since, and it hasn't changed.


Now, if a strict compliancy to RFC5280 is required, I'd like to understand how 
Mozilla NSS can be compliant with the following paragraph, taken from RFC5280 
clause 4.2:

   At a minimum, applications conforming to this profile MUST recognize
   the following extensions: key usage (Section 4.2.1.3), certificate
   policies (Section 4.2.1.4), subject alternative name (Section
   4.2.1.6), basic constraints (Section 4.2.1.9), name constraints
   (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended
   key usage (Section 4.2.1.12), and inhibit anyPolicy (Section
   4.2.1.14).

To my knowledge, unless this has changed in the past months, NSS doesn't 
properly handle CertificatePolicies, PolicyConstraints, and InhibitAnyPolicy.

And also with the following paragraph taken from RFC5280 clause 6:

   This section describes an algorithm for validating certification
   paths.  Conforming implementations of this specification are not
   required to implement this algorithm, but MUST provide functionality
   equivalent to the external behavior resulting from this procedure.
   Any algorithm may be used by a particular implementation so long as
   it derives the correct result.

when a CA contains an ExtendedKeyUsage extension. You know that the algorithm 
described in this section doesn't use this extension and thus doesn't limit a 
certificate chain based on this extension.


Cordialement,
Erwann.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to