[Cscwg-public] CRL Revocation Date Clarification Pre-Ballot

[Dimitris Zacharopoulos (HARICA)]

On 21/9/2021 6:02 μ.μ., Corey Bonnell wrote:
>
> Hi Dimitris,
>
> > If the CA already knows that the Subscriber Private Key was 
> compromised and malicious code was signed at a certain date in the 
> past, we should allow the CRL to contain that agreed revocation date 
> without requiring a first CRL and then a "subsequent" CRL entry.
>
> Agreed, that is the intent. In addition to the case you mentioned, I 
> also am attempting to address the case where a certificate is revoked 
> (and CRLs/OCSP responses have already been published denoting the 
> revoked status) but later it is discovered that the certificate should 
> be considered to be invalid starting from a different time. In this 
> case, the CA should be able to change the revocationDate in 
> subsequently published CRLs/OCSP responses to convey the new date.
>
> I tweaked the wording as follows (made some changes to the existing 
> third paragraph of 13.2.1 as well the new fourth paragraph):
>
> “A Certificate MAY have a one-to-one relationship or one-to-many 
> relationship with the signed Code. Regardless, revocation of a 
> Certificate may invalidate the Code Signatures on all signed Code, 
> some of which could be perfectly sound. Because of this, the CA MAY 
> specify the time at which the Certificate is first considered to be 
> invalid in the revocationDate field of a CRL entry or the 
> revocationTime field of a OCSP response to time-bind the set of 
> software affected by the revocation, and software should continue to 
> treat objects containing a timestamp dated before the revocation date 
> as valid.
>
> If a Code Signing Certificate previously has been revoked, and the CA 
> later becomes aware of a more appropriate revocation date, then the CA 
> MAY use that revocation date in subsequent CRL entries and OCSP 
> responses for that Code Signing Certificate.
>
> Effective 2022-02-01, if the CA includes the Invalidity Date CRL entry 
> extension in a CRL entry for a Code Signing Certificate, then the time 
> encoded in the Invalidity Date CRL extension SHALL be equal to the 
> time encoded in the revocationDate field of the CRL entry.”
>
> Does this revised wording help to clarify?
>

Yes, this is more clear, thank you.

Dimitris.
>
> Thanks,
>
> Corey
>
> *From:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
> *Sent:* Tuesday, September 21, 2021 2:01 AM
> *To:* Corey Bonnell <Corey.Bonnell at digicert.com>; 
> cscwg-public at cabforum.org
> *Subject:* Re: [Cscwg-public] CRL Revocation Date Clarification Pre-Ballot
>
> Hi Corey,
>
> If the CA already knows that the Subscriber Private Key was 
> compromised and malicious code was signed at a certain date in the 
> past, we should allow the CRL to contain that agreed revocation date 
> without requiring a first CRL and then a "subsequent" CRL entry.
>
>
> Thanks,
> Dimitris.
>
> On 20/9/2021 7:52 μ.μ., Corey Bonnell via Cscwg-public wrote:
>
>     Hello,
>
>     As discussed last week, it would be valuable to ensure that there
>     is clarity regarding how revocation/invalidity dates are encoded
>     in CRLs so that relying party software can make the correct trust
>     decisions regarding compromised code. Attached is a small change
>     to 13.2.1 to reflect that the revocationDate CRL entry field shall
>     be used to denote when a certificate is invalid. The proposed
>     language allows for the Invalidity Date CRL entry extension to
>     continue to appear, but the time encoded in it must be the same as
>     the revocationDate for the entry. I don’t believe this causes
>     issues with Windows CRL processing, please let me know if it does
>     and I’ll remove the provision.
>
>     For reference, here are the two proposed paragraphs to be added to
>     13.2.1:
>
>     If a Code Signing Certificate is revoked, and the CA later becomes
>     aware of a more appropriate revocation date, then the CA MAY use
>     that revocation date in subsequent CRL entries and OCSP responses
>     for that Code Signing Certificate.
>
>     Effective 2022-02-01, if the CA includes the Invalidity Date CRL
>     entry extension in a CRL entry for a Code Signing Certificate,
>     then the time encoded in the Invalidity Date CRL extension SHALL
>     be equal to the time encoded in the revocationDate field of the
>     CRL entry.
>
>     Given that the revocation date is potentially security sensitive,
>     I think it’s worthwhile to get this clarified prior to the RFC
>     3647/Pandoc effort. In addition to comments/questions on the
>     proposed language, we’re looking for two endorsers.
>
>     Thanks,
>
>     Corey
>
>
>
>     _______________________________________________
>
>     Cscwg-public mailing list
>
>     Cscwg-public at cabforum.org  <mailto:Cscwg-public at cabforum.org>
>
>     https://lists.cabforum.org/mailman/listinfo/cscwg-public  <https://lists.cabforum.org/mailman/listinfo/cscwg-public>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210922/2c237c20/attachment.html>