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

[Dimitris Zacharopoulos (HARICA)]

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
> https://lists.cabforum.org/mailman/listinfo/cscwg-public

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