From: Phillip Hallam-Baker <hal...@gmail.com>
Date: Wednesday, June 5, 2013 1:26 PM
To: Carl Wallace <c...@redhoundsoftware.com>
Cc: Rob Stradling <rob.stradl...@comodo.com>, "wpkops@ietf.org"
<wpkops@ietf.org>, Adam Langley <a...@chromium.org>
Subject: Re: [wpkops] Some questions about revocation reasons
> Probably better to just ask what CRLs they issue and for each whether the
> frequency of issue for full and deltas, and whether they use distribution
> points
I don't think so. Part of the point could be to identify and stamp out some
of the unused corners. Denying the existence of such things does not seem
helpful. Documenting pervasive lack of support (which I thought was part of
this effort) may help.
>
> Indirect raises another issue. By definition an indirect CRL is not issued by
> the issuing CA. But that gets us into some complex semantic games. What does
> it mean if the GeoTrust CRL is signed by Thawte? Is that indirect or direct?
>
> What I am getting at here is that maybe the issues are going to be a little
> more complex than a binary choice. The term CA can get rather slippery. It is
> an organizational concept and PKIX only deals in certificates and trust
> anchors. From a processing standpoint it seems 'obvious' to me that there
> 'should' be a CRL associated with every certificate signing cert. But the spec
> was originally written from the assumption that a CA was identical to a trust
> anchor. So it gets rather murky, particularly as trust anchors were rolled
> over.
>
> Some points to ponder:
>
> * Could DigiNotar have issued a CRL that clients would have accepted as
> validating certs of other CAs?
Or if not a CRL, could DigiNotar have issued an OCSP responder certificate
that was authorized to provide responses for any CA?
>
> * There is no hierarchy of severity specified for revocation reasons, let
> alone a duty on CAs to update the reason code if they revoke a cert to correct
> an error and subsequently find that the certificate application was
> fraudulent. So relying on the partitioning of CRLs by reason code as defined
> in the spec looks unsafe to me.
>
>
>
>
> On Wed, Jun 5, 2013 at 12:53 PM, Carl Wallace <c...@redhoundsoftware.com>
> wrote:
>>
>> From: Phillip Hallam-Baker <hal...@gmail.com>
>> Date: Wednesday, June 5, 2013 12:04 PM
>> To: Carl Wallace <c...@redhoundsoftware.com>
>> Cc: Rob Stradling <rob.stradl...@comodo.com>, "wpkops@ietf.org"
>> <wpkops@ietf.org>, Adam Langley <a...@chromium.org>
>> 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 <c...@redhoundsoftware.com>
>>> wrote:
>>>>
>>>> On 6/5/13 10:16 AM, "Rob Stradling" <rob.stradl...@comodo.com> 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
>>>>>> <rob.stradl...@comodo.com
>>>>>> >> <mailto:rob.stradl...@comodo.com>> wrote:
>>>>>> >>
>>>>>> >> On 04/06/13 22:51, Phillip Hallam-Baker wrote:
>>>>>> >>
>>>>>> >> On Tue, Jun 4, 2013 at 5:39 PM, Adam Langley
>>>>>> >> <a...@chromium.org
>>>>>> >> <mailto:a...@chromium.org>
>>>>>> >> <mailto:a...@chromium.org <mailto:a...@chromium.org>>> 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
>>>>>> >> wpkops@ietf.org
>>>>>> >> 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
>>>>> >wpkops@ietf.org
>>>>> >https://www.ietf.org/mailman/listinfo/wpkops
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Website: http://hallambaker.com/
>
>
>
> --
> Website: http://hallambaker.com/
_______________________________________________
wpkops mailing list
wpkops@ietf.org
https://www.ietf.org/mailman/listinfo/wpkops
