Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Mandatory reasonCode analysis
390 views
Skip to first unread message
Rob Stradling
Sep 30, 2020, 11:59:03 AM9/30/20
to dev-secur...@lists.mozilla.org
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://gist.github.com/robstradling/3088dd622df8194d84244d4dd65ffd5f
--
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.
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://gist.github.com/robstradling/3088dd622df8194d84244d4dd65ffd5f
--
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.
Jeremy Rowley
Sep 30, 2020, 12:41:29 PM9/30/20
to Mozilla
This is a good question. I read the requirements as applying only to CRLs and OCSP published after the effective date since the BRs always say explicitly when they apply to items before the effective date.
I also read this language:
If a CRL entry is for a Certificate not subject to these Requirements and was either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30, the CRLReason MUST NOT be certificateHold (6).
Which made me think the language applied only to CRLs and OCSP issued after 9-30. However, the language does only reference certificateHold and not the inclusion of reasonCode language.
That was the analysis I had anyway - that any CRLs and OCSP published after 9-30 had to have reasonCode.
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
I also read this language:
If a CRL entry is for a Certificate not subject to these Requirements and was either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30, the CRLReason MUST NOT be certificateHold (6).
Which made me think the language applied only to CRLs and OCSP issued after 9-30. However, the language does only reference certificateHold and not the inclusion of reasonCode language.
That was the analysis I had anyway - that any CRLs and OCSP published after 9-30 had to have reasonCode.
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Doug Beattie
Sep 30, 2020, 12:54:07 PM9/30/20
to Rob Stradling, mozilla-dev-s...@lists.mozilla.org
Hi Rob,
I'm not sure you filtered this report by "thisUpdate", maybe you did it by
nextUpdate by mistake?
The GlobalSign CRL on this report was created in 2016, thus the question.
Doug
I'm not sure you filtered this report by "thisUpdate", maybe you did it by
nextUpdate by mistake?
The GlobalSign CRL on this report was created in 2016, thus the question.
Doug
Rob Stradling
Sep 30, 2020, 12:56:15 PM9/30/20
to Mozilla, Jeremy Rowley
> I also read this language:
> If a CRL entry is for a Certificate not subject to these Requirements and was either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30, the CRLReason MUST NOT be certificateHold (6).
I think "was either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30" is talking about "a Certificate not subject to these Requirements", not about when the CRL was issued.
> If a CRL entry is for a Certificate not subject to these Requirements and was either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30, the CRLReason MUST NOT be certificateHold (6).
________________________________
From: dev-security-policy <dev-security-...@lists.mozilla.org> on behalf of Jeremy Rowley via dev-security-policy <dev-secur...@lists.mozilla.org>
Sent: 30 September 2020 17:41
To: Mozilla <mozilla-dev-s...@lists.mozilla.org>
Subject: RE: Mandatory reasonCode analysis
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
This is a good question. I read the requirements as applying only to CRLs and OCSP published after the effective date since the BRs always say explicitly when they apply to items before the effective date.
I also read this language:
If a CRL entry is for a Certificate not subject to these Requirements and was either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30, the CRLReason MUST NOT be certificateHold (6).
Which made me think the language applied only to CRLs and OCSP issued after 9-30. However, the language does only reference certificateHold and not the inclusion of reasonCode language.
That was the analysis I had anyway - that any CRLs and OCSP published after 9-30 had to have reasonCode.
Jeremy Rowley
Sep 30, 2020, 1:05:53 PM9/30/20
to Rob Stradling, Mozilla
That's probably true since CRL entries are published instead of issued and they don't have a notBefore date.
Regardless, I can see why someone would read it as requiring an update for all next published CRLs/OCSP given the historical way the BRs worked.
To be safe, we did update all of the DigiCert CRLs/OCSP for ICAs capable of issuing TLS. Looks like your report is flagging the legacy Symantec ICAs that are no longer trusted for TLS and are part of a root removal request.
From: Rob Stradling <r...@sectigo.com>
Sent: Wednesday, September 30, 2020 10:56 AM
To: Mozilla <mozilla-dev-s...@lists.mozilla.org>; Jeremy Rowley <jeremy...@digicert.com>
Subject: Re: Mandatory reasonCode analysis
> I also read this language:
> If a CRL entry is for a Certificate not subject to these Requirements and was either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30, the CRLReason MUST NOT be certificateHold (6).
I think "was either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30" is talking about "a Certificate not subject to these Requirements", not about when the CRL was issued.
________________________________
From: dev-security-policy <dev-security-...@lists.mozilla.org<mailto:dev-security-...@lists.mozilla.org>> on behalf of Jeremy Rowley via dev-security-policy <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>>
https://lists.mozilla.org/listinfo/dev-security-policy
Regardless, I can see why someone would read it as requiring an update for all next published CRLs/OCSP given the historical way the BRs worked.
To be safe, we did update all of the DigiCert CRLs/OCSP for ICAs capable of issuing TLS. Looks like your report is flagging the legacy Symantec ICAs that are no longer trusted for TLS and are part of a root removal request.
From: Rob Stradling <r...@sectigo.com>
Sent: Wednesday, September 30, 2020 10:56 AM
To: Mozilla <mozilla-dev-s...@lists.mozilla.org>; Jeremy Rowley <jeremy...@digicert.com>
Subject: Re: Mandatory reasonCode analysis
> I also read this language:
> If a CRL entry is for a Certificate not subject to these Requirements and was either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30, the CRLReason MUST NOT be certificateHold (6).
I think "was either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30" is talking about "a Certificate not subject to these Requirements", not about when the CRL was issued.
________________________________
Sent: 30 September 2020 17:41
To: Mozilla <mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org>>
Subject: RE: Mandatory reasonCode analysis
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
This is a good question. I read the requirements as applying only to CRLs and OCSP published after the effective date since the BRs always say explicitly when they apply to items before the effective date.
I also read this language:
If a CRL entry is for a Certificate not subject to these Requirements and was either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30, the CRLReason MUST NOT be certificateHold (6).
Which made me think the language applied only to CRLs and OCSP issued after 9-30. However, the language does only reference certificateHold and not the inclusion of reasonCode language.
That was the analysis I had anyway - that any CRLs and OCSP published after 9-30 had to have reasonCode.
-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org<mailto:dev-security-...@lists.mozilla.org>> On Behalf Of Rob Stradling via dev-security-policy
Sent: Wednesday, September 30, 2020 9:59 AM
To: dev-secur...@lists.mozilla.org<mailto:dev-secur...@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://gist.github.com/robstradling/3088dd622df8194d84244d4dd65ffd5f
--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com<mailto:r...@sectigo.com>
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
This is a good question. I read the requirements as applying only to CRLs and OCSP published after the effective date since the BRs always say explicitly when they apply to items before the effective date.
I also read this language:
If a CRL entry is for a Certificate not subject to these Requirements and was either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30, the CRLReason MUST NOT be certificateHold (6).
Which made me think the language applied only to CRLs and OCSP issued after 9-30. However, the language does only reference certificateHold and not the inclusion of reasonCode language.
That was the analysis I had anyway - that any CRLs and OCSP published after 9-30 had to have reasonCode.
-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org<mailto:dev-security-...@lists.mozilla.org>> On Behalf Of Rob Stradling via dev-security-policy
Sent: Wednesday, September 30, 2020 9:59 AM
To: dev-secur...@lists.mozilla.org<mailto:dev-secur...@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://gist.github.com/robstradling/3088dd622df8194d84244d4dd65ffd5f
--
Rob Stradling
Senior Research & Development Scientist
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-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
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
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
_______________________________________________
dev-security-policy mailing list
https://lists.mozilla.org/listinfo/dev-security-policy
Rob Stradling
Sep 30, 2020, 1:12:58 PM9/30/20
to Doug Beattie, mozilla-dev-s...@lists.mozilla.org
Hi Doug. I didn't filter by any CRL fields, as per option (2) in my original post.
________________________________
From: Doug Beattie
Sent: Wednesday, September 30, 2020 17:53
To: Rob Stradling
Cc: mozilla-dev-s...@lists.mozilla.org
________________________________
From: Doug Beattie
Sent: Wednesday, September 30, 2020 17:53
To: Rob Stradling
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: RE: Mandatory reasonCode analysis
Hi Rob,
I'm not sure you filtered this report by "thisUpdate", maybe you did it by
nextUpdate by mistake?
The GlobalSign CRL on this report was created in 2016, thus the question.
Doug
I'm not sure you filtered this report by "thisUpdate", maybe you did it by
nextUpdate by mistake?
The GlobalSign CRL on this report was created in 2016, thus the question.
Doug
-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On
Behalf Of Rob Stradling via dev-security-policy
Sent: Wednesday, September 30, 2020 11:59 AM
To: dev-secur...@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://gist.github.com/robstradling/3088dd622df8194d84244d4dd65ffd5f
--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
From: dev-security-policy <dev-security-...@lists.mozilla.org> On
Behalf Of Rob Stradling via dev-security-policy
Sent: Wednesday, September 30, 2020 11:59 AM
To: dev-secur...@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://gist.github.com/robstradling/3088dd622df8194d84244d4dd65ffd5f
--
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-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
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-secur...@lists.mozilla.org
Kurt Roeckx
Sep 30, 2020, 1:21:36 PM9/30/20
to Rob Stradling, dev-secur...@lists.mozilla.org
On Wed, Sep 30, 2020 at 03:58:45PM +0000, Rob Stradling via dev-security-policy wrote:
> 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).
I read the text as that effect today, every CRL or OCSP get get
> 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).
should comply with the requirements. It's also covers CA
certificates that were revoked in the past.
The text talks about a CRL entry for a root CA. That it, a root CA
says it's own certificate has been revoked. That doesn't seem very
useful.
Kurt
Ryan Sleevi
Sep 30, 2020, 2:18:24 PM9/30/20
to Kurt Roeckx, Rob Stradling, dev-secur...@lists.mozilla.org
that's covered as part of the auditing criteria, FWIW), and also solves any
issues with cross-certificates, by making it clear it's any CRL for
anything with CA:TRUE, "regardless" of how its used.
To Rob's question, the intent in drafting this requirement, which was an
existing (and long-standing) requirement from Microsoft that is also
consistent with past requests (not requirements) from Mozilla, Google, and
Apple, is that revocation information is updated by this deadline. This was
discussed during the balloting phase, precisely to allow CAs to schedule
ceremonies to generate new CRLs to ensure that, as of the deadline, all
revocation services provided were and are compliant.
This was explicitly called out in
https://github.com/cabforum/documents/pull/195 , which stated:
"These requirements come into effect 2020-09-30, as issuing new CRLs
requires a new ceremony."
As of today (intentionally chosen to be a Wednesday, so that there were no
beginning/end of week surprises), the published CRLs and OCSP responses
available via the CA's repository were and are expected to comply with the
profile set forth in the Baseline Requirements. A reasonCode was and is
expected to be published today, and so the question is "Does the published
CRL contain a reasonCode"?
Ryan Sleevi
Sep 30, 2020, 2:58:11 PM9/30/20
to Rob Stradling, Mozilla, Jeremy Rowley
On Wed, Sep 30, 2020 at 12:56 PM Rob Stradling via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> > I also read this language:
> > If a CRL entry is for a Certificate not subject to these Requirements
> and was either issued on-or-after 2020-09-30 or has a notBefore on-or-after
> 2020-09-30, the CRLReason MUST NOT be certificateHold (6).
>
> I think "was either issued on-or-after 2020-09-30 or has a notBefore
> on-or-after 2020-09-30" is talking about "a Certificate not subject to
> these Requirements", not about when the CRL was issued.
>
Yes. Yet another reason I think our approach to stating requirements in
dev-secur...@lists.mozilla.org> wrote:
> > I also read this language:
> > If a CRL entry is for a Certificate not subject to these Requirements
> and was either issued on-or-after 2020-09-30 or has a notBefore on-or-after
> 2020-09-30, the CRLReason MUST NOT be certificateHold (6).
>
> I think "was either issued on-or-after 2020-09-30 or has a notBefore
> on-or-after 2020-09-30" is talking about "a Certificate not subject to
> these Requirements", not about when the CRL was issued.
>
"plain English" does more harm than good.
The correct parse tree:
If a CRL entry is for:
* a Certificate not subject to these Requirements; and
* either:
* was issued on-or-after 2020-09-30; or
* has a notBefore on-or-after 2020-09-30
then:
* the CRLReason MUST NOT be certificateHold (6).
This was hoped to be "obvious", given that a "CRL entry" (a specific thing
within a CRL, c.f. https://tools.ietf.org/html/rfc5280#section-5.3 and
X.509) is neither issued nor has a notBefore.
pfuen...@gmail.com
Oct 1, 2020, 2:47:08 AM10/1/20
to mozilla-dev-s...@lists.mozilla.org
Hello,
as we are in the "list of shame" and as a way to ensure we are following these discussions, I'd like to say that the OISTE CA that is referenced here (it's an old intermediate CA expiring in December 2020, and its CRL contains some unspecified revocations for Issuing CAs from 2015 and older) is under a root for which we already requested to remove the TLS trust bit to the different CA programs (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1653092), so now is out of the scope of BR.
Best,
Pedro
as we are in the "list of shame" and as a way to ensure we are following these discussions, I'd like to say that the OISTE CA that is referenced here (it's an old intermediate CA expiring in December 2020, and its CRL contains some unspecified revocations for Issuing CAs from 2015 and older) is under a root for which we already requested to remove the TLS trust bit to the different CA programs (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1653092), so now is out of the scope of BR.
Best,
Pedro
Corey Bonnell
Oct 1, 2020, 6:39:31 AM10/1/20
to Rob Stradling, dev-secur...@lists.mozilla.org
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-...@lists.mozilla.org> on behalf of Rob Stradling via dev-security-policy <dev-secur...@lists.mozilla.org>
Sent: Wednesday, September 30, 2020 11:58:45 AM
To: dev-secur...@lists.mozilla.org <dev-secur...@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).
--
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-secur...@lists.mozilla.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy&data=02%7C01%7C%7Cfb1686dae6bf4f0475ea08d86559bf9b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637370783420551771&sdata=fkGX6tVkyTLHNtQkoiEdoF13ypjqCm6%2Ffq7FywIpa%2Fo%3D&reserved=0
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-...@lists.mozilla.org> on behalf of Rob Stradling via dev-security-policy <dev-secur...@lists.mozilla.org>
Sent: Wednesday, September 30, 2020 11:58:45 AM
To: dev-secur...@lists.mozilla.org <dev-secur...@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&data=02%7C01%7C%7Cfb1686dae6bf4f0475ea08d86559bf9b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637370783420551771&sdata=7kogxCZ1c%2F1ksbkNYEfMyP91gyIpJ8ppG%2F%2BOjevVl1Y%3D&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-secur...@lists.mozilla.org
Ryan Sleevi
Oct 1, 2020, 10:12:39 AM10/1/20
to Corey Bonnell, Rob Stradling, dev-secur...@lists.mozilla.org
On Thu, Oct 1, 2020 at 6:39 AM Corey Bonnell via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> 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.
To clarify: You mean the CAs were issued prior to 2012, yet are still
dev-secur...@lists.mozilla.org> wrote:
>
> 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.
trusted? That seems an easy enough problem to fix, in the spirit of
removing roots and hierarchies that predate the Baseline Requirements 1.0
effective date
0 new messages