CRL AuthorityKeyIdentifier Allowed Fields

[Corey Bonnell]

Hello,

Mozilla Root Policy section 5.2 has the following restriction:

“CAs MUST NOT issue certificates that have:…

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

Previous discussion [1] has established that this restriction on the certificate profile is not rooted in RFC 5280, but rather is a Mozilla-specific policy requirement. Given that RFC 5280 similarly does not profile CRLs to prohibit both the use of the keyIdentifier and (authorityCertIssuer, authorityCertSerialNumber) tuple in the authorityKeyIdentifier extension [2], it is not clear whether including both identifier types is allowed from a Mozilla policy standpoint. Given the lack of written restriction in Mozilla policy, I am inclined to think it is currently allowed, but I’m interested to hear others’ opinions.

As a follow-up to that, if both the keyIdentifier and (authorityCertIssuer, authorityCertSerialNumber) tuple is allowed in CRL authorityKeyIdentifiers, but the issuing CA’s certificate has a negative serial number or otherwise violates the constraints in RFC 5280 section 4.1.2.2, can CAs still populate the (authorityCertIssuer, authorityCertSerialNumber) tuple in CRL authorityKeyIdentifierExtensions?

Thanks,

Corey

 

[1] https://groups.google.com/g/mozilla.dev.security.policy/c/3iuG8KGryC4/m/0p6WyxlEBwAJ

[2] https://tools.ietf.org/html/rfc5280#section-5.2.1

[3] https://tools.ietf.org/html/rfc5280#section-4.1.2.2

[Ben Wilson]

Hi Corey,

I agree that section 5.2 of the Mozilla Root Store Policy is not 100% clear "whether including both identifier types is allowed from a Mozilla policy standpoint."  The phrase you cite is in a parenthetical as an example.  I suppose your question is about the source of this requirement and/or a suggestion that it be removed as an example in MRSP section 5.2? Once I know where you're coming from, then I can try to research its origin, if that helps.

Your second question is about CRL key identifiers and it also introduces either a hypothetical or a real case in which an issuing CA’s certificate has a negative serial number. The question is whether CAs can populate the (authorityCertIssuer, authorityCertSerialNumber) tuple in CRL authorityKeyIdentifierExtensions? I don't know the answer to that question, but it seems like it wouldn't be allowed because the negative serial number would be a violation, but it would also depend on how the key-matching algorithm works, which we'd have to explore.

Thanks,

Ben

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/65eb36c6-2066-47a6-92b0-c27f42941afen%40mozilla.org.

[Corey Bonnell]

Hi Ben,

 

> I agree that section 5.2 of the Mozilla Root Store Policy is not 100% clear "whether including both identifier types is allowed from a Mozilla policy standpoint."  The phrase you cite is in a parenthetical as an example.  I suppose your question is about the source of this requirement and/or a suggestion that it be removed as an example in MRSP section 5.2? Once I know where you're coming from, then I can try to research its origin, if that helps.

 

I think it would be very helpful to understand the underlying motivation for this Mozilla certificate profile requirement to see if it is applicable to CRLs. If you could find and share this information, that would be great.

 

> Your second question is about CRL key identifiers and it also introduces either a hypothetical or a real case in which an issuing CA’s certificate has a negative serial number. The question is whether CAs can populate the (authorityCertIssuer, authorityCertSerialNumber) tuple in CRL authorityKeyIdentifierExtensions? I don't know the answer to that question, but it seems like it wouldn't be allowed because the negative serial number would be a violation, but it would also depend on how the key-matching algorithm works, which we'd have to explore.

 

Historically, the Mozilla program has allowed some root certificates with negative serial numbers to be included in the program. What I’m unsure of is whether those root CAs issuing CRLs with authorityKeyIdentifier values that contain the (negative) serial number of the root certificate on an ongoing basis (i.e. at least annually and whenever there is a revocation of an ICA certificate) is acceptable.

 

Thanks,

Corey

[Kathleen Wilson]

I filed https://github.com/mozilla/pkipolicy/issues/226 to track this for our next policy update.

I think we should update our policy to add clarification about negative serial numbers, e.g. prohibit negative serial numbers in CRLs unless it's to be consistent with preexisting certificates. Mozilla code treats serial numbers as opaque sequences of bytes, but someone  should double-check what NSS does.

Thanks,

Kathleen

--
You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsub...@mozilla.org.