[cabfpub] Fwd: [pkix] Straw-poll on OCSP responses for non-revoked certificates.

Yngve N. Pettersen (Developer Opera Software ASA) yngve at opera.com
Thu Nov 8 17:36:19 UTC 2012





On Thu, 08 Nov 2012 18:16:36 +0100, Rick Andrews  
<Rick_Andrews at symantec.com> wrote:

> Erwann, Iñigo,
>
> I definitely see the utility of suspend and resume for end-user  
> certificates in smart cards. I don’t think it makes sense for SSL certs,  
> but I don’t feel strongly about it.
>
> I was under the impression that certs couldn’t be unrevoked and I  
> thought everyone had that impression, but I stand corrected. Thanks,

Please note that Ballot 93 (approved yesterday) says that a certificate  
covered by the BR cannot be unrevoked.

Issue 21, sec 13.2.7

>
> From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net]
> Sent: Thursday, November 08, 2012 12:31 AM
> To: erwann.abalea at keynectis.com; Rick Andrews
> Cc: public at cabforum.org
> Subject: RE: [cabfpub] Fwd: [pkix] Straw-poll on OCSP responses for  
> non-revoked certificates.
>
> Rick,
>
> Erwann is right. For example, we don´t have deltaCRLs, only fullCRLs and  
> allow suspension and reactivation. Once the certificate is suspended, we  
> generate a new CRL (so, it means it´s revoked and you can see the  
> reason) and the OCSP says is revoked. When you actívate it again, a new  
> CRL is created and you don´t see this cert and the OCSP says good.
>
> A practical example, one citizen calls saying he can´t find his  
> smartcard so ask for suspension, so a period time is allowed, for  
> example 15 days, to find it (after that time the certificate can be  
> automatically revoked) but if he finds the smartcard in the couch or in  
> another wallet, etc. then he can calls the CA back (or use another  
> procedure) and say, hey, I found it, can you actívate it back? And  
> that´s it.
> Other example can be when delivering the smartcards to the users by  
> post, this can be done in suspended mode (the certs are issued in  
> suspended mode or just turn into suspend mode after being issued or  
> whatever procedure has been implemented), then when the user receives  
> the card and also the pin and puk, so can call to actívate it or use a  
> web application or whatever mechanish the TSP has adopted.
>
> regards
>
>
> Iñigo Barreira
> Responsable del Área técnica
> i-barreira at izenpe.net<mailto:i-barreira at izenpe.net>
> 945067705
>
> [cid:image001.png at 01CDBD91.B6D173E0]
> ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta  
> egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada  
> (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari,  
> korreo honi erantzuna. KONTUZ!
> ATENCION! Este mensaje contiene informacion privilegiada o confidencial  
> a la que solo tiene derecho a acceder el destinatario. Si usted lo  
> recibe por error le agradeceriamos que no hiciera uso de la informacion  
> y que se pusiese en contacto con el remitente.
>
> De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En  
> nombre de Erwann ABALEA
> Enviado el: miércoles, 07 de noviembre de 2012 23:08
> Para: Rick Andrews
> CC: public at cabforum.org
> Asunto: Re: [cabfpub] Fwd: [pkix] Straw-poll on OCSP responses for  
> non-revoked certificates.
>
> Bonsoir Rick,
>
> If you don't allow resumption, then the certificate status stays revoked  
> with certificateHold reason.
>
> If you allow resumption but don't offer deltaCRLs, then you can't  
> express this resumption (i.e. explicitely tell the certificate is now in  
> a removeFromCRL state). But the certificate isn't revoked anymore and  
> disappears from the complete CRL.
>
> Nothing in the RFC or X.509 forbids suspension of certificates in  
> complete CRLs. X.509 is again more clear on how to deal with it, here's  
> an excerpt of clause 8.5.2.2 (200811 edition):
>
> -----
>
> Once a hold has been issued, it may be handled in one of three ways:
>
> a) it may remain on the CRL with no further action, causing users to  
> reject transactions issued during the hold period; or,
>
> b) it may be replaced by a (final) revocation for the same certificate,  
> in which case the reason shall be one of the standard reasons for  
> revocation, the revocation date shall be the date the certificate was  
> placed on hold, and the optional instruction code extension field shall  
> not appear; or,
>
> c) it may be explicitly released and the entry removed from the CRL.
> -----
>
> Just after follows the description and use-case of removeFromCRL reason  
> code.
>
> (this email will be rejected by cabfpub because I'm not posting from  
> work, can you manually forward it, please?)
>
> 2012/11/7 Rick Andrews  
> <Rick_Andrews at symantec.com<mailto:Rick_Andrews at symantec.com>>
> Erwann,
>
> I agree that resumption (removeFromCRL) is allowed only in delta CRLs,  
> but I don’t understand your interpretation of the RFC. If you’re using  
> full CRLs and you allow suspension but not resumption, then either
>
> (a)    The cert must must remain suspended until it expires, or
>
> (b)   The cert status can change from suspended (certificateHold) to  
> valid
>
> If (a), why use certificateHold at all? Why not use one of the other  
> revocation reasons?
> If (b), it seems that most people who have commented in this thread  
> believe that should not be allowed.
>
> -Rick
>
> From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org>  
> [mailto:public-bounces at cabforum.org<mailto:public-bounces at cabforum.org>]  
> On Behalf Of Erwann Abalea
> Sent: Wednesday, November 07, 2012 10:53 AM
> To: public at cabforum.org<mailto:public at cabforum.org>
>
> Subject: Re: [cabfpub] Fwd: [pkix] Straw-poll on OCSP responses for  
> non-revoked certificates.
>
> Resumption is necessary in deltaCRLs, and is only allowed in deltaCRLs.
> Suspension is allowed in every type of CRLs.
> We produce deltaCRLs for some CAs but no public one.
>
> --
>
> Erwann ABALEA
>
>
> Le 07/11/2012 19:25, Rick Andrews a écrit :
> When I looked at the RFC some time ago, it seemed that suspension and  
> resumption were only allowed in delta CRLs. I don’t know of any CAs or  
> browsers that support delta CRLs.
>
> -Rick
>
> From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org>  
> [mailto:public-bounces at cabforum.org] On Behalf Of  
> i-barreira at izenpe.net<mailto:i-barreira at izenpe.net>
> Sent: Wednesday, November 07, 2012 12:52 AM
> To: eddy_nigg at startcom.org<mailto:eddy_nigg at startcom.org>;  
> public at cabforum.org<mailto:public at cabforum.org>
> Subject: Re: [cabfpub] Fwd: [pkix] Straw-poll on OCSP responses for  
> non-revoked certificates.
>
> On the CRL you can suspend a certificate (the response is revoked) and  
> turned it back to a good status and this is perfectly valid.
>
>
> Iñigo Barreira
> Responsable del Área técnica
> i-barreira at izenpe.net<mailto:i-barreira at izenpe.net>
> 945067705
>
> [cid:image001.png at 01CDBD91.B6D173E0]
> ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta  
> egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada  
> (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari,  
> korreo honi erantzuna. KONTUZ!
> ATENCION! Este mensaje contiene informacion privilegiada o confidencial  
> a la que solo tiene derecho a acceder el destinatario. Si usted lo  
> recibe por error le agradeceriamos que no hiciera uso de la informacion  
> y que se pusiese en contacto con el remitente.
>
> De: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org>  
> [mailto:public-bounces at cabforum.org] En nombre de Eddy Nigg (StartCom  
> Ltd.)
> Enviado el: miércoles, 31 de octubre de 2012 21:45
> Para: public at cabforum.org<mailto:public at cabforum.org>
> Asunto: Re: [cabfpub] Fwd: [pkix] Straw-poll on OCSP responses for  
> non-revoked certificates.
>
>
> On 10/31/2012 10:32 PM, From Ben Wilson:
> If a modification of RFC 2560 allows an extension to change the meaning  
> of a “1” response to something else.  It was you who said “[it] might be  
> good, …, either due to migration and update time or other reasons  
> (out-of-sync cor whatever).”
>
> Yes, that's why I think using "Unknown" is the correct response and not  
> revoked for those. A revoked certificate can't be made valid ever after  
> as long as it hasn't expired. And "Unknown" != "Good".
>
> However once a certificate was marked as revoked, in my opinion a client  
> doesn't have to check again ever.
> Regards
>
>
>
> Signer:
>
> Eddy Nigg, COO/CTO
>
>
>
> StartCom Ltd.<http://www.startcom.org>
>
> XMPP:
>
> startcom at startcom.org<mailto:startcom at startcom.org>
>
> Blog:
>
> Join the Revolution!<http://blog.startcom.org>
>
> Twitter:
>
> Follow Me<http://twitter.com/eddy_nigg>
>
>
>
>
>
>
> _______________________________________________
>
> Public mailing list
>
> Public at cabforum.org<mailto:Public at cabforum.org>
>
> https://cabforum.org/mailman/listinfo/public
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org<mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public
>
>
>
> --
> Erwann.


-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: yngve at opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 96 90 41 51              Fax:    +47 23 69 24 01
********************************************************************



More information about the Public mailing list