From: Phillip Hallam-Baker <[email protected]> Date: Wednesday, June 5, 2013 12:04 PM To: Carl Wallace <[email protected]> Cc: Rob Stradling <[email protected]>, "[email protected]" <[email protected]>, Adam Langley <[email protected]> Subject: Re: [wpkops] Some questions about revocation reasons
> I am trying to unpack what you are saying here. > > The best way forward as far as I can see is to start of and ask CAs to > describe what types of revocation they support and describe their > implementation. Then ask what clients take notice of. > Having some means of naming the combinations may be helpful. X.509 sort of has a scheme. Maybe something like: Full: CRL (all types), EPRL (ee only), CARL (CA only) Indirect: iCRL, iEPRL, iCARL Delta: dCRL, dEPRL, dCARL Indirect Delta: idCRL, idEPRL, idCARL Distribution Point: dpCRL, dpEPRL, dpCARL Indirect Distribution Point: idpCRL, idpEPRL, idpCARL Delta Distribution Point: ddpCRL, ddpEPRL, ddpCARL Indirect Delta Distribution Point: iddpCRL, iddpEPRL, iddpCARL Any of these types could be further subdivided by reason code. If you just accept there are two categories of reason code partitioning, some or all, then there are at least 48 types. This is ignoring the attribute certificate stuff entirely and assumes I have not missed a relevant knob. > > > > > On Wed, Jun 5, 2013 at 11:07 AM, Carl Wallace <[email protected]> > wrote: >> >> On 6/5/13 10:16 AM, "Rob Stradling" <[email protected]> wrote: >> >>> >On 05/06/13 15:12, Phillip Hallam-Baker wrote: >>>> >> Heh, I was hoping not to have to reference that one. >>>> >> >>>> >> The RFCs are meant to specify everything needed to interpret the specs. >>> > >>> >Indeed. It seems odd to me that RFC5280 only references X.509 >>> >Informatively rather than Normatively. >> >> It'd be nice if your doc included a taxonomy of the various types of CRLs >> that can exist based on the combinations of {dp name/no dp name}, {some >> reasons/all reasons}, {ee only/ca only/all}, {direct/indirect} etc. and >> perhaps indicated what combinations are present in the web pki. I assume >> one need not grapple with DSA parameter inheritance while processing >> indirect DP CRLs that use relative to issuer names and cover only EE certs >> for the keyCompromise reason code with a delta CRL stream available where >> the CRL issuer's certificate has been signed by a rolled over CA key and >> whose revocation status is checked using pregenerated OCSP responses >> signed by a delegated responder that requires signed OCSP requests with >> noCheck asserted in the responder's certificate. >> >>> > >>>> >> On Wed, Jun 5, 2013 at 5:21 AM, Rob Stradling <[email protected] >>>> >> <mailto:[email protected]>> wrote: >>>> >> >>>> >> On 04/06/13 22:51, Phillip Hallam-Baker wrote: >>>> >> >>>> >> On Tue, Jun 4, 2013 at 5:39 PM, Adam Langley <[email protected] >>>> >> <mailto:[email protected]> >>>> >> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>>> >> >>>> >> <snip> >>>> >> >>>> >> Not to mention, does anyone have any idea what an >>>> >> aACompromise could >>>> >> mean? >>>> >> >>>> >> >>>> >> Its an attribute authority. For attribute certs. >>>> >> >>>> >> Well actually that is only a supposition because none of the >>>> >> terms seem >>>> >> to be defined. >>>> >> >>>> >> >>>> >> X.509 (11/2008) defines the reason codes as follows... >>>> >> >>>> >> "8.5.2.2 Reason code extension >>>> >> ... >>>> >> The following reason code values indicate why a certificate was >>>> >>revoked: >>>> >> - 'unspecified' can be used to revoke certificates for reasons >>>> >> other than the specific codes; >>>> >> - 'keyCompromise' is used in revoking an end-entity certificate; >>>> >> it indicates that it is known or suspected that the subject's >>>> >> private key, or other aspects of the subject validated in the >>>> >> certificate, have been compromised; >>>> >> - 'cACompromise' is used in revoking a CA-certificate; it >>>> >> indicates that it is known or suspected that the subject's private >>>> >> key, or other aspects of the subject validated in the certificate, >>>> >> have been compromised; >>>> >> - 'affiliationChanged' indicates that the subject's name or other >>>> >> information in the certificate has been modified but there is no >>>> >> cause to suspect that the private key has been compromised; >>>> >> - 'superseded' indicates that the certificate has been superseded >>>> >> but there is no cause to suspect that the private key has been >>>> >> compromised; >>>> >> - 'cessationOfOperation' indicates that the certificate is no >>>> >> longer needed for the purpose for which it was issued but there is >>>> >> no cause to suspect that the private key has been compromised; >>>> >> - 'privilegeWithdrawn' indicates that a certificate (public-key >>>> >> or attribute certificate) was revoked because a privilege contained >>>> >> within that certificate has been withdrawn; >>>> >> - 'aACompromise' indicates that it is known or suspected that >>>> >> aspects of the AA validated in the attribute certificate, have been >>>> >> compromised." >>>> >> >>>> >> -- >>>> >> Rob Stradling >>>> >> Senior Research & Development Scientist >>>> >> COMODO - Creating Trust Online >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Website: http://hallambaker.com/ >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> wpkops mailing list >>>> >> [email protected] >>>> >> https://www.ietf.org/mailman/listinfo/wpkops >>>> >> >>> > >>> >-- >>> >Rob Stradling >>> >Senior Research & Development Scientist >>> >COMODO - Creating Trust Online >>> >Office Tel: +44.(0)1274.730505 <tel:%2B44.%280%291274.730505> >>> >Office Fax: +44.(0)1274.730909 <tel:%2B44.%280%291274.730909> >>> >www.comodo.com <http://www.comodo.com> >>> > >>> >COMODO CA Limited, Registered in England No. 04058690 >>> >Registered Office: >>> > 3rd Floor, 26 Office Village, Exchange Quay, >>> > Trafford Road, Salford, Manchester M5 3EQ >>> > >>> >This e-mail and any files transmitted with it are confidential and >>> >intended solely for the use of the individual or entity to whom they are >>> >addressed. If you have received this email in error please notify the >>> >sender by replying to the e-mail containing this attachment. Replies to >>> >this email may be monitored by COMODO for operational or business >>> >reasons. Whilst every endeavour is taken to ensure that e-mails are free >>> >from viruses, no liability can be accepted and the recipient is >>> >requested to use their own virus checking software. >>> >_______________________________________________ >>> >wpkops mailing list >>> >[email protected] >>> >https://www.ietf.org/mailman/listinfo/wpkops >> >> > > > > -- > Website: http://hallambaker.com/
_______________________________________________ wpkops mailing list [email protected] https://www.ietf.org/mailman/listinfo/wpkops
