Hi Aaron,

 

> As long as we do not publish the CRLs, they are not required to be updated on 
> specific timetables.

 

My understanding is that absent the inclusion of a URI in a CRLDP extension of 
a Certificate that is subject to the BRs or some other Root Program 
requirement, there is no obligation by the CA to publish and update CRL-based 
revocation information on any specific cadence.

 

Given this, I believe that it’s compliant to not publish CRLs that are signed 
by the CA.

 

Thanks,

Corey

 

From: 'Aaron Gable' via [email protected] 
<[email protected]> 
Sent: Thursday, August 4, 2022 4:10 PM
To: [email protected] <[email protected]>
Subject: CRL Issuance Frequency for non-published CRLs

 

Hi MDSP,

 

Section 4.9.7 of the Baseline Requirements says (emphasis added):

 

> If the CA publishes a CRL, then the CA SHALL update and reissue CRLs at least 
> once every seven days, and the value of the nextUpdate field MUST NOT be more 
> than ten days beyond the value of the thisUpdate field.

 

Let's Encrypt is currently in the final stages of standing up infrastructure to 
issue and publish CRLs, in compliance with the upcoming Apple and Mozilla root 
program requirements that go into effect on October 1st.

 

As with many systems, we would like to test this as thoroughly as possible 
prior to making it fully available. Of course we're already running it in our 
non-production environment with an untrusted hierarchy of issuers. But there's 
a risk that, if we were to run the new infrastructure in our production 
environment and discover some sort of fault, we would not be able to turn it 
off again due to the reissuance and update requirements.

 

It is our interpretation of the above-quoted text from Section 4.9.7 that this 
risk does not actually exist. As long as we do not publish the CRLs, they are 
not required to be updated on specific timetables.

 

Does anyone disagree with this interpretation? Are there other requirements 
that I'm missing that would prevent us from turning the new infrastructure off?

 

Thanks,

Aaron

-- 
You received this message because you are subscribed to the Google Groups 
"[email protected] <mailto:[email protected]> " 
group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected] 
<mailto:[email protected]> .
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErfY4g7_6yz%2BLZ-mO0k_bDaSrxy4d9AJ8O8BQD-Et888tA%40mail.gmail.com
 
<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErfY4g7_6yz%2BLZ-mO0k_bDaSrxy4d9AJ8O8BQD-Et888tA%40mail.gmail.com?utm_medium=email&utm_source=footer>
 .

-- 
You received this message because you are subscribed to the Google Groups 
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186BFE4B53C139E80C133DC929E9%40DM6PR14MB2186.namprd14.prod.outlook.com.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to