[Cscwg-public] FW: [Cscwg-management] Code Signing Certificate expiration

[Dean Coclin]

Editing out dial in info, changing subject and moving further discussion to public list

-----Original Message-----
From: Cscwg-management <cscwg-management-bounces at cabforum.org> On Behalf Of Tomas Gustavsson
Sent: Friday, March 29, 2019 2:52 AM
To: Doug Beattie <doug.beattie at globalsign.com>; Wiedenhorst, Matthias <M.Wiedenhorst at tuvit.de>; cscwg-management at cabforum.org
Subject: Re: [Cscwg-management] Code Signing Working Group bi-weekly calls


Those ETSI references are related yes, great.

In addition there were national legislation before eIDAS. Italy, if I remember correctly, had in their legislation (before eIDAS when they could make local amendments) to keep signature certificates on CRLs forever.

I did not hear about requirements to add entries to a CRL after expiry of the CA.

(I'm ready to move to public list :-))

Regards,
Tomas

On 2019-03-28 19:36, Doug Beattie wrote:
> Hello,
> 
> Did you see any provisions for adding entries to a CRL once the CA has expired?  There are apparently some cases where a CA might be requested to revoke a certificate after the expiration date of the CA certificate. 
> 
> Also, on the consumption side, if the CA that signed the CRL has expired, will clients still validate the signature and accept the CRL as valid?  Assuming the CRL next update is set to "99991231235959Z", but the CA that signed the certificate has expired, will code signing clients generally still process the CRL as valid?
> 
> Maybe the requirement is that CAs must keep their Code Signing CAs alive and running for ~10 years past its expiration date and continue issuing CRLs on a normal cycle using their expired CA.
> 
> -----Original Message-----
> From: Cscwg-management <cscwg-management-bounces at cabforum.org> On 
> Behalf Of Wiedenhorst, Matthias
> Sent: Thursday, March 28, 2019 2:20 PM
> To: tomas.gustavsson at primekey.com; cscwg-management at cabforum.org
> Subject: Re: [Cscwg-management] Code Signing Working Group bi-weekly 
> calls
> 
> Hello,
> 
> I suppose this refers to requirements from ETSI EN 319 411-2 for EU qualified certificates.
> This one states in section 6.3.10:
> 
> CSS-6.3.10-02: Revocation status information shall be made available beyond the validity period of the certificate.
> Where CRLs are provided:
> [...]
> • CSS-6.3.10-04 [CONDITIONAL]: If CRLs are provided and no alternative means (e.g. OCSP) are provided for revocation status information on expired certificates, the TSP shall not remove from the CRL revoked certificates after they have expired.
> • CSS-6.3.10-05 [CONDITIONAL]: If CRLs are provided and the TSP does not remove from the CRL revoked certificates after they have expired, the CRL shall include the X.509 "ExpiredCertsOnCRL" extension as defined in ISO/IEC 9594-8/Recommendation ITU-T X.509 [4].
> [...]
> • CSS-6.3.10-07 [CONDITIONAL]: If CRLs are provided and the TSP decides or is required to terminate a CRL, the TSP should issue and publish at the corresponding CRL Distribution Point a last CRL with a nextUpdate field value as defined in ETSI EN 319 411-1 [2], clause 6.3.9. Requirement CSS-6.3.9-06.
> NOTE 3: CRL termination can occur when there are no more valid certificates in the scope of the CRL, and e.g. potentially in addition, when the CRL's signing entity certificate expires or when the CRL's signing entity private key is decommissioned.
> 
> The referenced requirement from ETSI EN 319 411-1 reads:
> CSS-6.3.9-06 [CONDITIONAL]: If Certificate Revocation Lists (CRLs) concerning end users certificates including any variants (e.g. Delta CRLs) are used, every CRL shall state a time for next scheduled CRL issue, unless it is the last CRL issued for those certificates in the scope of the CRL, in which case the nextUpdate field in the CRL defined in IETF RFC 5280 [7], should be set to "99991231235959Z"; NOTE 4: This value, defined in IETF RFC 5280 [7] for certificates that have no well-defined expiration date, is here extended for CRL.
> 
> Best regards
> Matthias
> 
>> -----Ursprüngliche Nachricht-----
>> Von: Cscwg-management <cscwg-management-bounces at cabforum.org> Im 
>> Auftrag von Tomas Gustavsson
>> Gesendet: Donnerstag, 28. März 2019 17:29
>> An: cscwg-management at cabforum.org
>> Betreff: Re: [Cscwg-management] Code Signing Working Group bi-weekly 
>> calls
>>
>>
>> Hi,
>>
>> This sounds similar to some requirements in EU (I'm not sure about 
>> the references right now but), keeping digital signature certificates 
>> on the CRL forever.
>>
>> Is it related to the CRL extension I assume:
>> ExpiredCertsOnCRL ::= GeneralizedTime
>>
>> Is it ok so say "at least 10 years"? Code signing certificates are 
>> probably not, in most cases, issued and revoked in huge amounts. So 
>> it would not harm to keep them on the CRL until the CA expires would it, if it's longer than 10 years?
>>
>> As an implementor, it would be nice to use the same feature for this 
>> and not add additional options to revocation handling (and currently 
>> we can keep expired on CRL for eternity).
>>
>> Regards,
>> Tomas
>>
>> On 2019-03-28 16:53, Doug Beattie wrote:
>>> Hi Dean,
>>>
>>>
>>>
>>> I had asked how we keep entries on a CRL for 10 years when the CA 
>>> expires before then.  We should re-look at the requirement that code 
>>> signing certificates must remain on the CRL for 10 years after the 
>>> code signing certificate expires.
>>>
>>>
>>>
>>> Doug
>>>
>>>
>>>
>>>
>>> Doug-if you have that list of improvements/changes to the current 
>>> MRs, please have them ready for the call.
>>>
>>>
>>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4916 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/cscwg-public/attachments/20190330/5e733c53/attachment.p7s>