Subject: [wpkops] Some questions about revocation reasons

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 4 Jun 2013 16:20:58 -0400

OK so working on the draft and trying to get a handle on how to sort out
all these degrees of freedom.

While I was doing so discovered that RFC 5280 doesn't really specify a
certificate lifecycle as such, it describes a mechanism for reporting CRLs
which is not quite the same thing.

The other thing I was somewhat surprised to find is that the cACompromise
reason code is defined but at no point in the document does the
string cACompromise occur in the context of defining when it should be
used. Same for the other reason codes.

-- 
Website: http://hallambaker.com/

---

From: Adam Langley <[email-masked]>
Date: Tue, 4 Jun 2013 17:39:12 -0400

On Tue, Jun 4, 2013 at 4:20 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> OK so working on the draft and trying to get a handle on how to sort out all
> these degrees of freedom.
>
> reason code is defined but at no point in the document does the string
> cACompromise occur in the context of defining when it should be used. Same
> for the other reason codes.

Not to mention, does anyone have any idea what an aACompromise could mean?

Cheers

AGL

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 4 Jun 2013 17:51:57 -0400

> 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.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 05 Jun 2013 10:21:35 +0100

On 04/06/13 22:51, Phillip Hallam-Baker wrote:
> On Tue, Jun 4, 2013 at 5:39 PM, Adam Langley <[email-masked]
> <mailto:[email-masked]>> wrote:
<snip>
> 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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 5 Jun 2013 10:12:18 -0400

Heh, I was hoping not to have to reference that one.

The RFCs are meant to specify everything needed to interpret the specs.

On Wed, Jun 5, 2013 at 5:21 AM, Rob Stradling <[email-masked]>wrote:

> 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;
> information in the certificate has been modified but there is no cause to
>   - 'aACompromise' indicates that it is known or suspected that aspects of
> the AA validated in the attribute certificate, have been compromised."
>
> --
> Rob Stradling

---

From: Rob Stradling <[email-masked]>
Date: Wed, 05 Jun 2013 15:16:45 +0100

> 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.

> On Wed, Jun 5, 2013 at 5:21 AM, Rob Stradling <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>     <snip>
>
>              Not to mention, does anyone have any idea what an
>         aACompromise could
>              mean?
>
>
>        - '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;
>     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
> _______________________________________________
> wpkops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wpkops
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
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.

---

From: Carl Wallace <[email-masked]>
Date: Wed, 05 Jun 2013 11:07:03 -0400

>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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 5 Jun 2013 12:02:45 -0400

The historical reason for this is that we were too cheap to pay for a spec.

But now there are political reasons that might well force a break with
ITU-T.

On Wed, Jun 5, 2013 at 10:16 AM, Rob Stradling <[email-masked]>wrote:

>> <mailto:rob.stradling@comodo.**com <[email-masked]>>> wrote:
>>
>> ______________________________**_________________
>> wpkops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/wpkops<https://www.ietf.org/mailman/listinfo/wpkops>
>>
>>
> --
> Rob Stradling
> 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.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 5 Jun 2013 12:04:56 -0400

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.

---

From: Carl Wallace <[email-masked]>
Date: Wed, 05 Jun 2013 12:53:37 -0400

From:  Phillip Hallam-Baker <[email-masked]>
Date:  Wednesday, June 5, 2013 12:04 PM
To:  Carl Wallace <[email-masked]>
Cc:  Rob Stradling <[email-masked]>, "[email-masked]"
<[email-masked]>, Adam Langley <[email-masked]>
Subject:  Re: [wpkops] Some questions about revocation reasons

> 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.

>>> >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>
>>> >

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 5 Jun 2013 13:26:28 -0400

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

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?

* 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 <[email-masked]>wrote:

> Cc: Rob Stradling <[email-masked]>, "[email-masked]" <
> [email-masked]>, Adam Langley <[email-masked]>
> Having some means of naming the combinations may be helpful.  X.509 sort
> of has a scheme.  Maybe something like:
>
> 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

---

From: Carl Wallace <[email-masked]>
Date: Wed, 05 Jun 2013 13:33:11 -0400

Date:  Wednesday, June 5, 2013 1:26 PM

> frequency of issue for full and deltas, and whether they use distribution

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?
> 
> 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
> '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:
> 

Or if not a CRL, could DigiNotar have issued an OCSP responder certificate
that was authorized to provide responses for any CA?

> 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.
> 
> 
> 
> 
>> then there are at least 48 types.  This is ignoring the attribute certificate
>> stuff entirely and assumes I have not missed a relevant knob.
>> 
>> 
>>> 
>>> 
>>> 
>>>

---

From: Erwann ABALEA <[email-masked]>
Date: Wed, 5 Jun 2013 19:45:03 +0200

> helpful.  Documenting pervasive lack of support (which I thought was part of

Do we only consider pure web PKI here, or can we also consider
specific PKIs that are based on RFC5280 but choose to deviate from it?
I'm thinking of CSCA PKIs and recent changes in CRL production, with
implied indirect CRLs not indicated by an adhoc extension. Ugly, but
it does exist in the wild.

> 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:
>

Because an OCSP responder can also be accepted based on local client
configuration, then local configuration does matter (that problem
doesn't exist with CRL).
On Windows, it has yet to be confirmed if a CA for which an effective
id-kp-ocspSigning EKU is associated can be considered as a valid OCSP
responder for all the CAs. There are 81 of them.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 5 Jun 2013 13:45:29 -0400

On Wed, Jun 5, 2013 at 1:33 PM, Carl Wallace <[email-masked]>wrote:

> 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.
>

I thought we were talking about the CAs...

For the Clients I would expect the situation to be binary, either they
support a feature or not. If they support direct delta CRLs  and indirect
but not indirect deltas we are in trouble.

> 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:
>

Another good question.

Easy to say what we think they should do in that one situation. But there
are many corner cases that the clients have to support.

Very easy to assume that we know the answers.

---

From: Carl Wallace <[email-masked]>
Date: Wed, 05 Jun 2013 13:51:49 -0400

From:  Phillip Hallam-Baker <[email-masked]>
Date:  Wednesday, June 5, 2013 1:45 PM

<snip>
> For the Clients I would expect the situation to be binary, either they support
> a feature or not. If they support direct delta CRLs  and indirect but not
> indirect deltas we are in trouble.

You can limit the scope to CAs and identify the same subset of possibilities
which could be used to prune what (new) implementations ought to be required
to support.  Maybe a taxonomy is not required and simply asking on a per
feature basis is good enough.  The combinations can get pretty nasty though.

>  <snip>
>> Another good question.
> 
> Easy to say what we think they should do in that one situation. But there are
> many corner cases that the clients have to support.
> 

I think we can safely say that nothing in a mass market trust anchor store
ought to be configured by default such that subordinate OCSP responders can
issue responses for any CA.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 05 Jun 2013 19:12:02 +0100

On 05/06/13 18:45, Erwann ABALEA wrote:
<snip>
> responder for all the CAs. There are 81 of them.

Until November 2008, the "DigiNotar Root CA" was enabled for the OCSP 
Signing trust purpose in the Microsoft Root Certificate Program.  After 
then, it wasn't.

(I have a record of all authroot.stl files since January 2007).

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 6 Jun 2013 12:22:02 -0400

This is getting to be a little more complicated than I thought. Rather than
plough on into yet more weeds, perhaps it might help to put out a very
early albeit very incomplete draft tomorrow so people can see what the
weeds look like?

OK more fun out in revocation land...

Indirect CRLs. Should these be considered a substitute for the direct CRL
or could they be merely an adjunct?

Reading through RFC 5280 it seems like indirect CRLs are just thrown in
there without much thought as to the implications of allowing someone else
to sign the CRL. The problem is that a CRL is both an explicit assertion
that a set of certs is invalid and an implicit assertion that all unlisted
certs are valid.

What is an RP to assume from an indirect CRL?

RFC 5280 seems to suggest that an indirect CRL is just like a direct CRL
but it really doesn't seem to anticipate the issue. Which is going to make
marking them as indirect utterly pointless. To the extent that the indirect
flag has a meaning it becomes an evil bit. Working out if a CRL is direct
is something a client should CHECK and arrive at as a conclusion. If it
matters it should be configured into the trust anchor metadata.

The only reason for telling the RP that the CRL is indirect that I can see
would be to warn them that it is incomplete.

[Now Rob is going to tell me X.509... But I don't want to read that because
I am pretty certain the majority of client side implementers did not.]

---

From: Rob Stradling <[email-masked]>
Date: Thu, 06 Jun 2013 20:03:14 +0100

On 06/06/13 17:22, Phillip Hallam-Baker wrote:
<snip>
> [Now Rob is going to tell me X.509... But I don't want to read that
> because I am pretty certain the majority of client side implementers did
> not.]

I'll keep quiet then.  :-)

---

From: Carl Wallace <[email-masked]>
Date: Thu, 06 Jun 2013 15:20:04 -0400

From:  Phillip Hallam-Baker <[email-masked]>
Date:  Thursday, June 6, 2013 12:22 PM
To:  Rob Stradling <[email-masked]>
Cc:  Erwann ABALEA <[email-masked]>, Carl Wallace
<[email-masked]>, Adam Langley <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject:  Re: [wpkops] Some questions about revocation reasons

> What is an RP to assume from an indirect CRL?

Is this relevant to the tasks this working group is currently working on?  I
thought the task being discussed here was the (possibly) easier task of
identifying what is actually used in the web PKI w.r.t. revocation status
determination.  I suggested a taxonomy be used to identify what is actually
used to give some structure to the discussion and to potentially serve as a
precursor to deprecating options no one uses so client code could lose some
needless complexity.

<snip>