I did some searching in this area after Microsoft announced the new root 
program requirement back in February [1] and it appears that v1 CRLs are still 
being actively published in the webPKI. Notably, v1 CRLs do not support 
extensions in revoked entries, so there is no way to encode the reasonCode 
extension.

Although RFC 5280, section 5 [2] mandates that conforming CAs MUST produce v2 
CRLs, the CAs issuing v1 CRLs pre-date any browser root requirements that 
mandate adherence to the RFC 5280 profile. Switching to v2 CRLs may present 
interoperability concerns for legacy clients that consume CRLs issued from such 
CAs. Additionally, RFC 5280 specifies that conforming clients must be able to 
consume both v1 and v2 CRLs, so modern clients should be able to consume v1 
CRLs.

Given the requirement as specified originally by Microsoft (and later in the 
BRs), I'd think that only v2 CRLs are acceptable moving forward but the 
potential legacy client interoperability issues may pose challenges with 
transitioning to v2 CRLs. I'm interested to hear if anyone has any thoughts on 
this.

Thanks,
Corey

[1] 
https://cabforum.org/2020/03/20/minutes-for-ca-browser-forum-f2f-meeting-49-bratislava-19-20-february-2020/#Microsoft-Root-Program-Update
[2] https://tools.ietf.org/html/rfc5280#section-5

________________________________
From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> on 
behalf of Rob Stradling via dev-security-policy 
<dev-security-policy@lists.mozilla.org>
Sent: Wednesday, September 30, 2020 11:58:45 AM
To: dev-security-policy@lists.mozilla.org 
<dev-security-policy@lists.mozilla.org>
Subject: Mandatory reasonCode analysis

Starting today, the BRs require a reasonCode in CRLs and OCSP responses for 
revoked CA certificates.  Since crt.sh already monitors CRLs and keeps track of 
reasonCodes, I thought I would conduct some analysis to determine the level of 
(non)compliance with these new rules.

It's not clear to me if (1) the new BR rules should be applied only to CRLs and 
OCSP responses with thisUpdate timestamps dated today or afterwards, or if (2) 
every CRL and OCSP response currently being served by distribution points and 
responders (regardless of the thisUpdate timestamps) is required to comply.  
(I'd be interested to hear folks' opinions on this).

This gist contains my crt.sh query, the results as .tsv, and a .zip containing 
all of the referenced CRLs:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Frobstradling%2F3088dd622df8194d84244d4dd65ffd5f&amp;data=02%7C01%7C%7Cfb1686dae6bf4f0475ea08d86559bf9b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637370783420551771&amp;sdata=7kogxCZ1c%2F1ksbkNYEfMyP91gyIpJ8ppG%2F%2BOjevVl1Y%3D&amp;reserved=0


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally privileged, 
confidential, or proprietary information. If you are not the intended 
recipient, you are not permitted to use, copy, or forward it, in whole or in 
part without the express consent of the sender. Please notify the sender by 
reply email, disregard the foregoing messages, and delete it immediately.


_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy&amp;data=02%7C01%7C%7Cfb1686dae6bf4f0475ea08d86559bf9b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637370783420551771&amp;sdata=fkGX6tVkyTLHNtQkoiEdoF13ypjqCm6%2Ffq7FywIpa%2Fo%3D&amp;reserved=0
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to