(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 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. > 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 4.2.1.1 and 4.2.1.2) and policy mappings (Section 4.2.1.5) 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 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. > 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
