(Sorry for the second e-mail, Erwann still having some Groups issues - this
will be the one that shows up on the list)

On Tue, Oct 8, 2019 at 6:43 PM Erwann Abalea via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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 and
>, basic constraints (Section, key usage (Section
>, and certificate policies (Section 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.

English language plurality? That is talking about "subject key identifiers
and authority key identifiers" - not about keyIdentifiers. From that same
section you're quoting (4.2), the phrase is repeated for applications, but
with a slight twist:

   In addition, applications conforming to this profile SHOULD recognize
   the authority and subject key identifier (Sections and and policy mappings (Section extensions.

It was just an editorial quirk by the RFC editor relating to there being
"two" items on the latter list, but "four" items on the former.

> > 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 don't think that "strange" is relevant here, particularly as it relates
to Mozilla policy? I was trying to head off that argument, but you jumped
full into it with the reference to A.2. That is, even if you want to
suggest that A.2. of 5280 permits it, or that 5912 permits it, or that
X.509 (which no browser really pays attention to, ITU-T being what it is),
that argument would be a moot argument in the presence of the Policy 1.0.

> 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, certificate
>    policies (Section, subject alternative name (Section
>, basic constraints (Section, name constraints
>    (Section, policy constraints (Section, extended
>    key usage (Section, and inhibit anyPolicy (Section
> To my knowledge, unless this has changed in the past months, NSS doesn't
> properly handle CertificatePolicies, PolicyConstraints, and
> InhibitAnyPolicy.

It's entirely consistent to require CAs to conform to the RFC 5280 profile,
without requiring applications like NSS conform to the 5280 profile. It's
not even a double-standard: it's two entirely separable pieces. So it's not
worth responding to.
dev-security-policy mailing list

Reply via email to