Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

From: Santosh Chokhani <[email-masked]>
Date: Sun, 22 Jan 2012 08:41:59 -0500

Per RFC 5280, Certificate Issuer  for the CRL Entry Extension is a GeneralNames, so no AKID is involved.

Both X,500 and RFC 5280 assume that the DN (name) and serial number uniquely identify the certificate based on the assumption that the names are unique.

It is not clear why you would need to access CA certificate via reference to CRL entry extension and thus I do not understand what you are trying to achieve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Saturday, January 21, 2012 4:51 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

Martin:

> If a PKI CA wanted to re-use CA DNames when rolling CA keys, and in 
> combination with indirect CRLs, how/where would the 
> AuthorityKeyIdentifier for the CRLEntryExtension.CertificateIssuer be 
> conveyed, that would be necessary to disambiguate between CA certs 
> with different keys and exact same SubjectName?
> 
> I seem to have difficulties locating an answer in ITU-T X.509 and rfc5280.

Does Section 4.4 of RFC 4210 provide an answer?  It has been a while since I looked at it, but I seem to remember it being very complete.

Russ

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 23 Jan 2012 14:21:06 +0000

On 1/22/12 7:41 AM, "Santosh Chokhani" <[email-masked]> wrote:

>Both X,500 and RFC 5280 assume that the DN (name) and serial number
>uniquely identify the certificate based on the assumption that the names
>are unique.

This is probably something that needs to be written out of the RFC.

-- T

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 23 Jan 2012 09:29:53 -0500

Are you saying that X.509 and RFC 5280 should NOT assume that the DN is unique?

-----Original Message-----
From: Miller, Timothy J. [mailto:[email-masked]] 
Sent: Monday, January 23, 2012 9:21 AM
To: Santosh Chokhani; Russ Housley; [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

On 1/22/12 7:41 AM, "Santosh Chokhani" <[email-masked]> wrote:

>uniquely identify the certificate based on the assumption that the 
>names are unique.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 23 Jan 2012 15:00:33 +0000

Not across different PKIs, no.  Current software treats Issuer+Serial as a
unique identifier; this is a security risk.  I can (and have, in the lab,
for compatibility testing purposes, honest!) created my own CAs that
collide names.

Both X.509 and RFC 5280 are not clear on this point.  They were written
with the understanding that the trust anchor needs to be included when
considering a DN, but this is a point that's lost on lots of
implementations.  For example of this error, see Figure 21 in  "Windows
Vista Smart Card Infrastructure" at:

http://msdn.microsoft.com/en-us/library/bb905527.aspx

Specifically, trace the thread for logon using the Subject+Issuer
alternative mapping.

-- T

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Jan 2012 16:19:10 +0100 (MET)

> GeneralNames, so no AKID is involved.

Correct, the AKID is missing there, and it is also missing in
the CRL Distribution point extension, both of which appear to
be a defect in the specs.

> uniquely identify the certificate based on the assumption that the

Yes, it looks like this was the original design, there was an
assumption/requirement that issuer names (i.e. Subject names of
CA certificates) would be unique.

> 
> It is not clear why you would need to access CA certificate via
> reference to CRL entry extension and thus I do not understand what
> you are trying to achieve

It appears that there was an exemption retrofitted into X.509/rfc5280
to allow two (or more) CA certificates with different public keys
to bear the exact same Subject DName, and in order to disabiguate
between those CA certificates, the AKID extension is required in
all places where the CA certificate is referenced by IssuerName
alone.  AKID was added as an X.509v3 certificate extension and
as a CRL extension, but it seesm to be missing in CRLEntryExtension
and the CRLDistributionPoint extension.

For simple (=direct) CRLs, the Cert IssuerName + Cert AKID match
the CRLSigner + CRLExtension.AKID and disambiguates for which CA (cert)
the CRL is authoritative.

For indirect CRLs, the CRLSigner + CRLExtension.AKID refer to the
indirect signer, and the Link between the Cert and the
CRLEntryExtension.CertificateIssuer is dangling, because it
lacks an AKID that refers back to the Cert's AKID.

And the CrlDistributionPoint extension seems to lack a seperate AKID
to uniquely identify an indirect CrlSigner matching the AKID on
the indirect CRL.CRLExtensions.

Russ Housley wrote:
> Martin Rex wrote:
> Does Section 4.4 of RFC 4210 provide an answer?  It has been a while
> since I looked at it, but I seem to remember it being very complete.

Section 4.4 is about rolling of RootCAs keys.  While my question
was in independent from the role of the CA, I was thinking of
intermediate CAs.

Usually, the CA key rollover is more of an issuer for intermediate CA
than rootCA certs, where the lifetime is usually 5-10 years and you
might worry about CRL size and appreciate a start-over by rolling
your intermediate CA cert.

When rolling your intermediate CA cert sensibly, you would at least
add a SerialNumber RDName to your intermediate CAs DName that will
preclude all ambiguities, but there seems to be software that not
prefers to reuse the DName and distinguish only by AKID.

But to me it looks like interect CRLs can not be made to work
reliably/safely with CAs that re-use DNames and require AKID
presence in order to distinguish CertificateIssuers.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Jan 2012 16:22:43 +0100 (MET)

(resend, with typos fixed below)

Martin Rex wrote:
> preclude all ambiguities, but there seems to be software that
> But to me it looks like indirect CRLs can not be made to work

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 23 Jan 2012 10:51:38 -0500

Martin,

The historical understanding on your part is not accurate.

The items you are identifying may protect against unintended name collisions, but would not protect against intentional attacker.

To see the general issue in this area, I encourage you to see my briefings to the IETF Meeting held in DC area circa Nov. 2004, if I recall correctly.  Also, see related briefing and paper in NIST PKI Research Symposium circa 2005 and 2006.

The items you identify are changes to the standard.  It may be possible to assure backward compatibility using optional fields, but I have not worked that out.

For specific comments, see comments in-line.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Monday, January 23, 2012 10:23 AM
To: [email-masked]
Cc: Santosh Chokhani; [email-masked]; [email-masked]
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

Martin Rex wrote:
> Correct, the AKID is missing there, and it is also missing in the CRL 
> Distribution point extension, both of which appear to be a defect in 
> the specs.
> 
> 
> > 
> assumption/requirement that issuer names (i.e. Subject names of CA 
> certificates) would be unique.
> 
> 
> > 
> to allow two (or more) CA certificates with different public keys to 
> bear the exact same Subject DName, and in order to disabiguate between 
> those CA certificates, the AKID extension is required in all places 
> where the CA certificate is referenced by IssuerName alone.
[Santosh] That was not the purpose of AKID.  AKID was intended to efficiently disambiguate between multiple signing keys held by the same CA, e.g., for due to key roll-over.

  AKID was 
> added as an X.509v3 certificate extension and as a CRL extension, but 
> it seesm to be missing in CRLEntryExtension and the 
> CRLDistributionPoint extension.
[Santosh] I do not see any value for it in CRL Entry extension since once the relying party trusts the CRL in question and assumes that the same authority would not service with two different CAs with the same name, it becomes a non-issue.

As to appearing in CRL DP, the CRL DP itself ensures that the correct indirect issuer is pointed to.  If you are concerned about mischief, AKID would not be the way to handle it since anyone can assert an AKID.  You would need to include the Indirect CRL Signer Public Key or Secure Hash thereof.  Note that this would be a change to the standard as well as remove flexibility from the indirect CRL issuer to rekey.

> 
> 
> For simple (=direct) CRLs, the Cert IssuerName + Cert AKID match the 
> CRLSigner + CRLExtension.AKID and disambiguates for which CA (cert) 
> CRLEntryExtension.CertificateIssuer is dangling, because it lacks an 
> AKID that refers back to the Cert's AKID.
[Santosh] As I said before, I do not think an Authority would service two different CAs with the same name.

> to uniquely identify an indirect CrlSigner matching the AKID on the 
> indirect CRL.CRLExtensions.
[Santosh] See response above.

> 
> 
> Russ Housley wrote:
> > 
> > Martin Rex wrote:
> > >
> > > If a PKI CA wanted to re-use CA DNames when rolling CA keys, and 
> > > in combination with indirect CRLs, how/where would the 
> > > AuthorityKeyIdentifier for the CRLEntryExtension.CertificateIssuer 
> > > be conveyed, that would be necessary to disambiguate between CA 
> > > certs with different keys and exact same SubjectName?
> > > 
> Section 4.4 is about rolling of RootCAs keys.  While my question was 
> in independent from the role of the CA, I was thinking of intermediate 
> CAs.
> 
> 
> might worry about CRL size and appreciate a start-over by rolling your 
> intermediate CA cert.
> 
> 
> preclude all ambiguities, but there seems to be software that prefers 
> to reuse the DName and distinguish only by AKID.
> 
> reliably/safely with CAs that re-use DNames and require AKID presence 
> in order to distinguish CertificateIssuers.
> 
> 
> -Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Jan 2012 17:50:27 +0100 (MET)

Santosh Chokhani wrote:
> [Santosh] That was not the purpose of AKID.  AKID was intended to
> efficiently disambiguate between multiple signing keys held by the
> same CA, e.g., for due to key roll-over.

I fail to see a different between what I wrote and what you wrote.

> 
> > AKID was added as an X.509v3 certificate extension and as a
> > CRL extension, but it seesm to be missing in CRLEntryExtension
> [Santosh] I do not see any value for it in CRL Entry extension since
> once the relying party trusts the CRL in question and assumes that
> the same authority would not service with two different CAs with
> the same name, it becomes a non-issue.

This is about one single CA holding certs with the exact same DName
and different keypairs.  This may be for different algorithms
in parallel (RSA and ECDSA), or same algorithm but different key&validity
for key roll-over.

If that single CA uses distinct CRLs for each of its CA certs, dinstinguishing
them only by AKID, then indirect CRLs will no longer work, because it
would become possible for an attacker to cheat RPs with CRLs that
refer to the other CA cert than the one they wanted to check, and due
to the lack of an AKID in the CRLEntryExtension, the RP will be
unable to detect that it is being spoofed.

> 
> As to appearing in CRL DP, the CRL DP itself ensures that the correct
> indirect issuer is pointed to.

When CAs reuse DNames for differen keypairs, that does not seem to work
with indirect CRLs, because of the lack of an AKID in the CRL DP
that could be matched to the AKID of indirect signer in the CRLExtension.

>
> If you are concerned about mischief, AKID would not be the way to handle
> it since anyone can assert an AKID.  You would need to include the
> Indirect CRL Signer Public Key or Secure Hash thereof.  Note that this
> would be a change to the standard as well as remove flexibility from
> the indirect CRL issuer to rekey.

I'm concerned about what looks like an undefined/unspecified area
ITU-T X.509 / rfc5280 when combining CA DName re-use with indirect CRLs.

> two different CAs with the same name.

The collision of CA Names from different PKIs or different sections
of the same PKI is not what I'm currently worrying about.

I'm talking about one single organization/administrative entity
holding multiple CA certs with the same Subject DName but distinct
public key pairs.

Every "self-issued" CA certificate is a DName re-use.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 23 Jan 2012 12:07:25 -0500

Martin,

See in-line with deletions..

I fail to see a different between what I wrote and what you wrote.
[Santosh] The difference is that we are not trying to ensure that two distinct CAs with the same name can be disambiguated,  We are simply introducing efficiency mechanism to select appropriate certificate for signature checking which can be computationally expensive.  AKID is NOT a security mechanism.

> 
> > AKID was added as an X.509v3 certificate extension and as a CRL 
> > extension, but it seesm to be missing in CRLEntryExtension and the 
> once the relying party trusts the CRL in question and assumes that the 
> same authority would not service with two different CAs with the same 
> name, it becomes a non-issue.

This is about one single CA holding certs with the exact same DName and different keypairs.  This may be for different algorithms in parallel (RSA and ECDSA), or same algorithm but different key&validity for key roll-over.
[Santosh] Since that CA is not supposed to repeat serial numbers, DN and serial number tuple will unique identify a certificate for that CA.

If that single CA uses distinct CRLs for each of its CA certs, dinstinguishing them only by AKID, then indirect CRLs will no longer work, because it would become possible for an attacker to cheat RPs with CRLs that refer to the other CA cert than the one they wanted to check, and due to the lack of an AKID in the CRLEntryExtension, the RP will be unable to detect that it is being spoofed.
[Santosh] I assume in the first part you mean issue distinct CRL using different keys.  The CA that signs partial CRLs, albeit using different keys is supposed to issue partitioned CRL asserting IDP in CRL extension.  The relying parties are supposed to match DP in CRL DP and DP in IDP to counter the threat you mentioned.

> indirect issuer is pointed to.

When CAs reuse DNames for differen keypairs, that does not seem to work with indirect CRLs, because of the lack of an AKID in the CRL DP that could be matched to the AKID of indirect signer in the CRLExtension.
[Santosh] See a prior response.

>
> If you are concerned about mischief, AKID would not be the way to 
> handle it since anyone can assert an AKID.  You would need to include 
> the Indirect CRL Signer Public Key or Secure Hash thereof.  Note that 
> this would be a change to the standard as well as remove flexibility 
> from the indirect CRL issuer to rekey.

I'm concerned about what looks like an undefined/unspecified area ITU-T X.509 / rfc5280 when combining CA DName re-use with indirect CRLs.
[Santosh] There is nothing undefined if you are thinking of the same CA DN having multiple keys.  The CRL needs to be partitioned or you can combine all the revocation information and sign with each key.  Thus, the list would be the same and complete but some of the other information would be different.  Also, based on the certificate entry, you can declare a different CRL DP to ensure that the relying party gets the CRL signed with the same algorithm as the certificate.  If you running the same CA, you also need to keep the serial number unique regardless of key.

I would also suggest you using different DN for the CAs and running them as separate CAs.  But, that is an engg. and product limitation function.

BTW, in none of your scenarios, would the CRL be called in indirect CRL.   When a CA rolls over its key, it does not issue indirect CRL from the X.509 and 5280 viewpoints.  It is issuing a direct CRL.

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 23 Jan 2012 12:27:06 -0500

Martin,

As Santosh noted, your comments seem to be based on a misunderstanding 
of X.509.  There was no exemption/retrofit to allow to allow two or more 
CA certificates with different public keys to bear the same subject DN.  
In X.509, entities are identified by name, but by the key(s) they use to 
sign things, so there was no need for an exemption/retrofit to allow a 
CA to use more than one key to create signatures.  The key identifier 
extensions are merely non-critical extensions that aid in determining 
which key was used to sign something/which certificate can be used to 
verify a signature.

You have made a common mistake in misinterpreting the meaning of an 
indirect CRL.  An indirect CRL is a "revocation list that at least 
contains revocation information about certificates issued by authorities 
other than that which issued this CRL", where an authority is "[a]n 
entity, responsible for the issuance of certificates."  In the scenario 
that you present, the same authority signs both the CRL and all of the 
certificates covered by the CRL, so it is NOT an indirect CRL.  The fact 
that the CA used different keys to sign the certificates and CRL is 
immaterial.

> unable to detect that it is being spoofed.

As noted above this has nothing to do with indirect CRLs (even though 
many people incorrectly refer to this scenario as involving indirect 
CRLs).  In the scenario you described above, the CA is broken.  The AKID 
only aids the relying party in determining which key is needed to verify 
the signature on the CRL, it does not affect the scope of the CRL.  As 
RFC 5280 says:

    A full and complete CRL lists all unexpired
    certificates issued by a CA that have been revoked for any reason.
    (Note that since CAs and CRL issuers are identified by name, the
    scope of a CRL is not affected by the key used to sign the CRL or the
    key(s) used to sign certificates.)

X.509 is also clear on this:

    If the issuing distribution point field, the AA issuing distribution 
point field,
    and the CRL scope field are all absent, the CRL shall contain 
entries for all
    revoked unexpired public-key certificates issued by the CRL issuer.

In the scenario above, if the CA signs certificates using two different 
keys and issues two CRLs, each CRL covering the certificates that were 
signed using the same key as the CRL, then the CRLs need to include a 
critical issuingDistributionPoint extension.  In particular, each of the 
CRLs would have to be assigned a different DistributionPointName and 
this name would have to appear in the issuingDistributionPoint 
extensions of the CRLs and the cRLDistributionPoints extensions of the 
certificates.  It would be the distribution point names that would 
distinguish between the CRLs and would inform relying parties which CRL 
provided revocation information for any given certificate, not the key 
identifiers.

Dave

On 01/23/2012 11:50 AM, Martin Rex wrote:
> .

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 23 Jan 2012 12:46:00 -0500

X.509 is very clear.  It requires names to be unambiguous.  Where did 
you get the idea that X.509 was written with the understanding that the 
trust anchor needs to be included when considering a DN?  Can you point 
to any text (other than unsubstantiated assertions made by other people 
on the mail list) to support this claim?

On 01/23/2012 10:00 AM, Miller, Timothy J. wrote:
> On 1/23/12 8:29 AM, "Santosh Chokhani"<[email-masked]>  wrote:
>
>> On 1/22/12 7:41 AM, "Santosh Chokhani"<[email-masked]>  wrote:
>>

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Jan 2012 18:59:51 +0100 (MET)

> CA certificates with different public keys to bear the same subject DN.  

Now I am confused.

> which key was used to sign something/which certificate can be used to 

This contradicts the previous statements.  If CA certs that differ in
public key are also required to differ in subject DName, then there exists
no ambiguity that AKID would have to resolve.

> that the CA used different keys to sign the certificates and CRL is 

That is not how I understand (and implemented) CRL checking.
Direct CRL is the case when the CRLIssuer is the same as the
certificate issuer, and that means during path validation,
that I use the *EXACT* same CA certificate to verify the
CA signature as the CRL signature.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 23 Jan 2012 13:51:32 -0500

X.509 is very clear in its scope: "The Directory: Public-key and
attribute certificate frameworks".   When X.509 is used outside the
scope of a global Directory, bad things can happen.

It is impossible for any CA to determine (much less prove) the negative:
"no X.509 certificate has been issued anywhere in the world with DN
<x>", and only universal participation in a naming framework (such as a
global Directory) can ensure name uniqueness*.  Where is that naming
framework?  You can do your best to comply with X.509, but as soon as
someone else issues a cert containing a DN that you also use, you are
both non-compliant.

Dave

* excluding names with verified cryptographic uniqueness, of course.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David A. Cooper
Sent: Monday, January 23, 2012 12:46 PM
To: Miller, Timothy J.
Cc: [email-masked]
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

On 01/23/2012 10:00 AM, Miller, Timothy J. wrote:
> Not across different PKIs, no.  Current software treats Issuer+Serial 
> as a unique identifier; this is a security risk.  I can (and have, in 
> the lab, for compatibility testing purposes, honest!) created my own 
> CAs that collide names.
>
> Both X.509 and RFC 5280 are not clear on this point.  They were 
> written with the understanding that the trust anchor needs to be 
> included when considering a DN, but this is a point that's lost on 
> lots of implementations.  For example of this error, see Figure 21 in

> "Windows Vista Smart Card Infrastructure" at:
>

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 23 Jan 2012 14:43:28 -0500

On 01/23/2012 01:51 PM, Kemp, David P. wrote:

If the scope of X.509 is so clearly limited to the use of
certificates as part of a global Directory, while doesn't the
document say that somewhere, such as in the "Scope" section?  The
existence of the words "The Directory" in the title proves nothing.

X.509 says:

For every name form used in the GeneralName type,
there shall

be a name registration system that ensures that any "name used

unambiguously identifies one entity to both certificate issuer
and

certificate users.

Contrary to your assertion this does not require the existence of a
global Directory.  There is no global directory for object
identifiers, and yet no one is saying that we can't use OIDs to
unambiguously identify things (algorithms, certificate policies,
naming attributes, extensions, etc.).

The IETF has even accepted a document (RFC 4122) that claims a
Universally Unique IDentitifer (UUID), even though RFC 4122 says
that "A UUID is 128 bits long, and can guarantee uniqueness across
space and time" and that the creation of UUIDs "requires no central
registration process."  Did I miss the part in RFC 4122 where it
imposes a requirement for there to be a global directory of UUIDs in
order to ensure uniqueness?

The fact is that X.509 requires names to be unambiguous, regardless
of whether a global Directory is being used.  Any argument about how
CAs cannot ensure that this requirement is satisfied is an argument
against X.509, not an argument that the requirement doesn't exist.

Dave

Dave

-----Original Message-----

-- T

Are you saying that X.509 and RFC 5280 should NOT assume that the DN
is unique?

-----Original Message-----
From: Miller, Timothy J. [mailto:[email-masked]]
Sent: Monday, January 23, 2012 9:21 AM
To: Santosh Chokhani; Russ Housley; [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

On 1/22/12 7:41 AM, "Santosh Chokhani"<[email-masked]>

wrote:

Per RFC 5280, Certificate Issuer for the CRL Entry Extension is a
GeneralNames, so no AKID is involved.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 23 Jan 2012 19:53:32 +0000

>on the mail list) to support this claim?

If I give you the chain:

CN=CooperCo Root CA,O=CooperCo,C=US
  CN=CooperCo Issuing CA,O=CooperCo,C=US
    CN=David.Cooper,O=CooperCo,C=US
      serialNumber=0x0100

And the chain:

CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU=(c)
2006 VeriSign, Inc. - For authorized use only,OU=VeriSign Trust
Network,O=Verisign, Inc.,C=US
  CN=CooperCo Issuing CA,O=CooperCo,C=US
    CN=David.Cooper,O=CooperCo,C=US
      serialNumber=0x0100

If I give you the pair:

("CN=CooperCo Issuing CA,O=CooperCo,C=US","serialNumber=0x0100")

To which certificate does it refer?

-- T

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 23 Jan 2012 15:00:01 -0500

Yes, it is very clear that you are confused. You apparently have an 
incorrect model of the way that X.509 works and you are attempting to 
interpret every X.509 says and everything I say in a way that is 
consistent with your flawed model.

At no point did I say that CA certs differ in public key that they are 
also required to differ in subject DN.  What I said is that entities, 
including CAs and CRL issuers, are identified by name only, not by the 
key they use to sign things.

Your understanding of CRL checking is incorrect, as you are 
misinterpreting the meaning of "same issuer".  X.509 says that "CAs are 
unambiguously defined by a distinguished name".  So, "same issuer" means 
"same distinguished name".  It does not necessarily mean that they were 
signed by the same key or that the same certificate may be used to 
verify the signatures on both objects.

If I sign two documents, but sign one with my left hand and one with my 
right hand, weren't both documents still signed by the same entity 
(person)?  It's the same with X.509 and keys.  If a CA, which is 
"unambiguously defined by a distinguished name", signs two objects, but 
uses different keys to sign the two documents, both documents were still 
signed by the same CA.

Dave

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 23 Jan 2012 15:27:27 -0500

While I can only guess at how to interpret your certificate chains, it 
appears that the CA "CN=CooperCo Issuing CA,O=CooperCo,C=US" has issued 
a certificate to "CN=David.Cooper,O=CooperCo,C=US" with serial number 
0x0100, and that two different CAs ("CN=CooperCo Root 
CA,O=CooperCo,C=US" and "CN=VeriSign Class 3 Public Primary 
Certification Authority - G5,OU=(c) 2006 VeriSign, Inc. - For authorized 
use only,OU=VeriSign Trust Network,O=Verisign, Inc.,C=US") have issued 
certificates to "CN=CooperCo Issuing CA,O=CooperCo,C=US".  I have no 
idea what you mean by "To which certificate does it refer?"

Are suggesting that "CN=CooperCo Root CA,O=CooperCo,C=US" and 
"CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU=(c) 
2006 VeriSign, Inc. - For authorized use only,OU=VeriSign Trust 
Network,O=Verisign, Inc.,C=US" have actually issued certificates to two 
different CAs that both issue certificates under the name "CN=CooperCo 
Issuing CA,O=CooperCo,C=US"?  If so, how does this in any way prove that 
X.509 was  "written with the understanding that the trust anchor needs 
to be included when considering a DN"?  I can create a certificate that 
has a negative serial number, but that's not proof that RFC 5280 doesn't 
say "The serial number MUST be a positive integer assigned by the CA to 
each certificate."

Dave

On 01/23/2012 02:53 PM, Miller, Timothy J. wrote:
> On 1/23/12 11:46 AM, "David A. Cooper"<[email-masked]>  wrote:
>

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 23 Jan 2012 15:57:43 -0500

An argument that X.509 cannot ensure uniqueness of DNs (in the absence
of a Directory or global DN registry) is, as you say, an argument
against X.509.

The proposal to associate Issuer/Serial with a trust anchor addresses
that argument against X.509 with a mechanism that guarantees global
uniqueness as long as each trust anchor ensures local uniqueness, and
confines any collisions within a single trust anchor to its local scope.

The requirement exists.  And it is circular and specious to argue that
the enhancement is unnecessary "because X.509 requires DNs to be
globally unique".  That's like arguing there's no need to install street
lights because there's already a regulation for streets to be adequately
lit.

Dave K

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]] 
Sent: Monday, January 23, 2012 2:43 PM
To: Kemp, David P.
Cc: [email-masked]
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

	X.509 is very clear in its scope: "The Directory: Public-key and
	attribute certificate frameworks".   When X.509 is used outside
the
	scope of a global Directory, bad things can happen.

If the scope of X.509 is so clearly limited to the use of certificates
as part of a global Directory, while doesn't the document say that
somewhere, such as in the "Scope" section?  The existence of the words
"The Directory" in the title proves nothing.

	It is impossible for any CA to determine (much less prove) the
negative:
	"no X.509 certificate has been issued anywhere in the world with
DN
	<x>", and only universal participation in a naming framework
(such as a
	global Directory) can ensure name uniqueness*.  Where is that
naming
	framework?  You can do your best to comply with X.509, but as
soon as
	someone else issues a cert containing a DN that you also use,
you are
	both non-compliant.

X.509 says:

      For every name form used in the GeneralName type, there shall
      be a name registration system that ensures that any "name used
      unambiguously identifies one entity to both certificate issuer and
      certificate users.

Contrary to your assertion this does not require the existence of a
global Directory.  There is no global directory for object identifiers,
and yet no one is saying that we can't use OIDs to unambiguously
identify things (algorithms, certificate policies, naming attributes,
extensions, etc.).

The IETF has even accepted a document (RFC 4122) that claims a
Universally Unique IDentitifer (UUID), even though RFC 4122 says that "A
UUID is 128 bits long, and can guarantee uniqueness across space and
time" and that the creation of UUIDs "requires no central registration
process."  Did I miss the part in RFC 4122 where it imposes a
requirement for there to be a global directory of UUIDs in order to
ensure uniqueness?

The fact is that X.509 requires names to be unambiguous, regardless of
whether a global Directory is being used.  Any argument about how CAs
cannot ensure that this requirement is satisfied is an argument against
X.509, not an argument that the requirement doesn't exist.

Dave

	Dave
	
	* excluding names with verified cryptographic uniqueness, of
course.

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On
Behalf Of
	David A. Cooper
	Sent: Monday, January 23, 2012 12:46 PM
	To: Miller, Timothy J.
	Cc: [email-masked]
	Subject: Re: [pkix] AuthKeyId and
CrlEntryExtension.CertificateIssuer
	
	X.509 is very clear.  It requires names to be unambiguous.
Where did
	you get the idea that X.509 was written with the understanding
that the
	trust anchor needs to be included when considering a DN?  Can
you point
	to any text (other than unsubstantiated assertions made by other
people
	on the mail list) to support this claim?

		Not across different PKIs, no.  Current software treats
Issuer+Serial 
		as a unique identifier; this is a security risk.  I can
(and have, in 
		the lab, for compatibility testing purposes, honest!)
created my own 
		CAs that collide names.
		
		Both X.509 and RFC 5280 are not clear on this point.
They were 
		written with the understanding that the trust anchor
needs to be 
		included when considering a DN, but this is a point
that's lost on 
		lots of implementations.  For example of this error, see
Figure 21 in

		
		Specifically, trace the thread for logon using the
Subject+Issuer 
		alternative mapping.
		
		-- T
		
		On 1/23/12 8:29 AM, "Santosh
Chokhani"<[email-masked]> <mailto:[email-masked]>
wrote:

			Are you saying that X.509 and RFC 5280 should
NOT assume that the DN 
			is unique?
			
			-----Original Message-----
			From: Miller, Timothy J.
[mailto:[email-masked]]
			Sent: Monday, January 23, 2012 9:21 AM
			To: Santosh Chokhani; Russ Housley; [email-masked]
			Cc: [email-masked]
			Subject: Re: [pkix] AuthKeyId and
CrlEntryExtension.CertificateIssuer
			
			On 1/22/12 7:41 AM, "Santosh
Chokhani"<[email-masked]> <mailto:[email-masked]> 

	wrote:

				Per RFC 5280, Certificate Issuer  for
the CRL Entry Extension is a 
				GeneralNames, so no AKID is involved.
				
				Both X,500 and RFC 5280 assume that the
DN (name) and serial number 
				uniquely identify the certificate based
on the assumption that the 
				names are unique.

			This is probably something that needs to be
written out of the RFC.
			
			-- T

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Jan 2012 22:12:05 +0100 (MET)

> verify the signatures on both objects.

If this would be true, this would entirely kill section 6.3 CRL checking
out of rfc5280.

When I'm doing certificate path validation, then all I have is the
chain that I received from the peer.  If a CRL without indirect
issuer does not verify with the exact same cert that verifies the
signature on the cert, then I fail path validation.

> uses different keys to sign the two documents, both documents were still 

The same entity that signed the certificate in my reading
refers to the the exact same signer cert.  There is no other
trusted (verified) CA cert available at that point, anyway.

-Martin

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 23 Jan 2012 16:19:46 -0500

David,

I suggest you read what people actually say before falsely accusing
them of making "circular and specious" arguments.  Timothy Miller
did not propose "to associate Issuer/Serial with a trust
anchor".  He said:

implementations.

There is a major difference between prosing something and stating
that the standard was "written with the understanding that...."

I asked for evidence to support his assertion that "[X.509 and RFC
5280] were written with the understanding that the trust anchor
needs to be included when considering a DN".

The fact that you are referring to this as a "proposal" and an
"enhancement" only demonstrates that you agree with me.

On 01/23/2012 03:57 PM, Kemp, David P. wrote:

No, this would be someone claiming that the lights on a certain
street don't meet the regulations, and then me arguing that the
street does meet the regulations since the regulations only require
one street light every 100m and the street has one street light
every 90m, and then you falsely accusing me of having said that the
street was adequately lit, even though I never suggested that the
regulations were adequate.

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]]
Sent: Monday, January 23, 2012 2:43 PM
To: Kemp, David P.
Cc: [email-masked]
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

X.509 says:

Dave

Dave

-----Original Message-----

-- T

-----Original Message-----
From: Miller, Timothy J.

wrote:

-- T

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 23 Jan 2012 16:33:47 -0500

> If this would be true, this would entirely kill section 6.3 CRL checking

No it wouldn't.  See Section 6.3.3., step (f):

       (f)  Obtain and validate the certification path for the issuer of
            the complete CRL.  The trust anchor for the certification
            path MUST be the same as the trust anchor used to validate
            the target certificate.  If a key usage extension is present
            in the CRL issuer's certificate, verify that the cRLSign bit
            is set.

This is completely separate from step (b)(1):

       (b)  Verify the issuer and scope of the complete CRL as follows:

          (1)  If the DP includes cRLIssuer, then verify that the issuer
               field in the complete CRL matches cRLIssuer in the DP and
               that the complete CRL contains an issuing distribution
               point extension with the indirectCRL boolean asserted.
               Otherwise, verify that the CRL issuer matches the
               certificate issuer.

> signature on the cert, then I fail path validation.

Are we talking about X.509/RFC 5280 or your particular implementation of 
certification path validation?  This may be what your code does, but 
where is your support for the argument that this is what X.509/RFC 5280 
requires?

> refers to the the exact same signer cert.

That may be your reading, but that is not what was meant and there is no 
text in X.509 or RFC 5280 to support that reading.

> There is no other

That is why step (f) says that you may have to "obtain and validate the 
certification path for issuer of the complete CRL."

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 23 Jan 2012 16:49:44 -0500

Folks,

I just wanted to say something broader here.

Folks like David Cooper, myself and Dave Kemp who have been around and have wrestled with the issues, know the problems and various ways to fix them.  We do not always agree on which solution to use since using some of the solutions imposes added requirements on relying parties.

Lot of questions Martin Rex and Tim Miller ask arise from lack of understanding on how X.509 and 5280 work.

There are days I feel it is 1999 and then I say, I really need a new gig, really.......

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Jan 2012 00:38:59 +0100 (MET)

>             in the CRL issuer's certificate, verify that the cRLSign bit

Well, I'm not implementing a part of an X.500 or LDAP directory,
which the premise that I can securely(!) access the entire universe
of existing certificates.

I'm looking at an average RP, who keeps a small store of trust anchors,
and receives a certificate path from the communication peer, such
as in a TLS Certificate handshake message, and performs certificate
path validation on that path.  So that RPs universe is pretty small.

For such an environment, when performing certificate revocation checking
during certificate path validation for a direct CRL, that "obtain and
validate the certification path for the issuer of the complete CRL",
refers exactly to the validated subset of the certification path
that was input to 6.1.

When talking about conformance to rfc5280, this is about independent
interoperable implementations that can be built from this document
and those that are explicitly listed as prerequisites.  If something
is not specified or designed, it is not relevant for minimum
interoperability.

In case that you assume that those words in (f) might refer to some
fancy "certificate path discovery algorithm" that is completely
unrelated to the certification path that an RP is currently processing,
that would be a misunderstanding.

That could only be conceivable if such an algorithm was (a) spelled out
so that it can be independently implemented in an interoperable
fashion and (b) secure.  I don't see any other path described
in rfc5280 that is available to a generic RP other than the one
in 6.1 obtained from the communication peer.

-Martin

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 24 Jan 2012 09:00:06 +0100

> To which certificate does it refer?
this doest look like an  authority key  identifier.

you want to identify which of the possible two

you want,  cn=verisign .. serial xxx  or   cn= root cooperca + serial=yyy

---

From: Bruce Stephens <[email-masked]>
Date: Tue, 24 Jan 2012 11:03:54 +0000

Martin Rex <[email-masked]> writes:

[...]

> refers exactly to the validated subset of the certification path

Such an RP will presumably have to reject many valid paths, but that
may well be acceptable.

As an alternative (even without access to the Global Directory) an RP
could use extensions such as AIA and CRLDP to gather further
certificates and CRLs.

[...]

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 24 Jan 2012 13:08:52 +0000

>idea what you mean by "To which certificate does it refer?"

Exactly.  :)

>say "The serial number MUST be a positive integer assigned by the CA to

The point is the idea that (Issuer DN, EE serial number) is an unambiguous
identifier is flawed.  (Issuer DN, EE serial number, trust anchor key
identifier) is the minimum set necessary for disambiguation.

While this should be obvious to anyone as deeply involved in PKI as most
of the participants on this list) it is *not* obvious to everyone else.
Any text or concepts in any of the PKIX work items that state or imply
that (Issuer DN, EE serial number) is an unambiguous identifier need to be
caveated or changed.

-- T

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 24 Jan 2012 08:13:54 -0500

In this world of cross certified PKI, Bridges and no name constraints due to SSP, TA does not disambiguate DN.

Also, note that 5280 in security considerations did add the language that the certificate and its CRL need to emanate from the same TA as a result of 2004 Nov IETF meeting, but that only reduces the problem.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miller, Timothy J.
Sent: Tuesday, January 24, 2012 8:09 AM
To: David A. Cooper
Cc: [email-masked]
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

On 1/23/12 2:27 PM, "David A. Cooper" <[email-masked]> wrote:

>Certification Authority - G5,OU=(c) 2006 VeriSign, Inc. - For 
>authorized use only,OU=VeriSign Trust Network,O=Verisign, Inc.,C=US") 
>have issued certificates to "CN=CooperCo Issuing CA,O=CooperCo,C=US".  
>I have no idea what you mean by "To which certificate does it refer?"

Exactly.  :)

>has a negative serial number, but that's not proof that RFC 5280 
>doesn't say "The serial number MUST be a positive integer assigned by 
>the CA to each certificate."

The point is the idea that (Issuer DN, EE serial number) is an unambiguous identifier is flawed.  (Issuer DN, EE serial number, trust anchor key
identifier) is the minimum set necessary for disambiguation.

While this should be obvious to anyone as deeply involved in PKI as most of the participants on this list) it is *not* obvious to everyone else.
Any text or concepts in any of the PKIX work items that state or imply that (Issuer DN, EE serial number) is an unambiguous identifier need to be caveated or changed.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 24 Jan 2012 13:55:30 +0000

On 1/23/12 3:49 PM, "Santosh Chokhani" <[email-masked]> wrote:

>Folks like David Cooper, myself and Dave Kemp who have been around and
>have wrestled with the issues, know the problems and various ways to fix
>them.  We do not always agree on which solution to use since using some
>of the solutions imposes added requirements on relying parties.
>
>Lot of questions Martin Rex and Tim Miller ask arise from lack of
>understanding on how X.509 and 5280 work.

That's more than a little unfair.  And if I *am* misunderstanding, I'm not
alone.  E.g., from RFC5652:

SignerIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier }

This allows an attacker who can issue certs from *any* trust anchor in the
victim's trust store to spoof *any* identity.  Given that many PKIs are
private entities with no obligation to disclose fraud (or may be coerced
into issuing fraudulent certs by national governments), does this really
seem like a good idea to anyone?

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 24 Jan 2012 14:09:24 +0000

And another thing: 

While it's true that 5280 doesn't make this error, I think 5280 promotes
this error.  It's fair to say that this isn't a PKIX problem, but IMHO
implementors rely on 5280 and if this is an error that occurs more than
once (it does) then I think this indicates something that 5280 can
improve.  If nothing else, a specific security note to the effect that
this kind of identifier is a *bad idea* would be warranted.

-- T

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Jan 2012 16:40:34 +0100 (MET)

After having checked various parts of rfc5280 and ITU-T X.509 and
slept over it, I believe to have found the relevant information
that caused my confusion.  So I'll try to clarify this myself.

I originally assumed that one possible reason for intermediate CA key
rollover would be that the CA's current CRL size has grown beyond
a reasonable size.  (I know US DOD CAs with CRLs of > 1 million entries
that I consider unreasonably sized).

During discussion with consultants of another vendor of PKI software
I was told that their product does not support rolling your own
intermediate CAs subject name when rolling its keypair, so based on
that description I assumed that X.509 would define partitioning of
CRLs based on AKIDs in order to allow restarting with an empty CRL
for the new intermediate CA keypair.

That is not the case.  X.509 does *NOT* allow partitioning of CRLs
based on AKIDs. (this would have required, among several other things,
CRLEntryExtension and CRL DP to include AKIDs).

So whenever a CA is operating with multiple CA certs with different
public keys, complexity goes up.  The CA will have to provide
a complete CRLs covering all CA certs with the same Subject Name,
and must distribute it in several variants, signed with each and
every one those CA certs and must configure the CRL DPs so that each
issued cert references the CRL DP with the CRLSigner cert matching
EXACTLY the certificate signer CA cert.

> Such an RP will presumably have to reject many valid paths, but that

It is the most reasonable RP behaviour, essentially required by X.509 
and recommended by rfc5280 to request such a questionable path.

> could use extensions such as AIA and CRLDP to gather further

Using CRL DP is safe (because you look at it only after verifying
the signature to check for revocation), but it does not get you anywhere.

Using (URLs) from AIA on the other hand is folly because it is unsafe,
and no sensible implementation would be doing this as part of an RP
performing unattended certificate path validation.
Per X.509 it is a SHALL NOT, per rfc5280 it is a RECOMMENDED must not.

Quoting from rfc5280 Section 6.1 Basic Path Validation (3rd paragraph):

   http://tools.ietf.org/html/rfc5280#section-6.1

   While the certificate and CRL profiles specified in Sections 4 and 5
   of this document specify values for certificate and CRL fields and
   extensions that are considered to be appropriate for the Internet
   PKI, the algorithm presented in this section is not limited to
   accepting certificates and CRLs that conform to these profiles.
!! Therefore, the algorithm only includes checks to verify that the
!! certification path is valid according to X.509 and does not include
!! checks to verify that the certificates and CRLs conform to this
!! profile.  While the algorithm could be extended to include checks for
!! conformance to the profiles in Sections 4 and 5, this profile
!! RECOMMENDS against including such checks.

With this explicit caveat, it is conforming to rfc5280 to use instead the
algorithm specified in ITU-T X.509 for performing certificate path
validation and CRL checking.  And in several places, X.509 is significantly
clearer.

Quoting from ITU-T X.509

   B.1.2 CRL processing

                                             [...] The algorithm used
   by a particular implementation to derive the correct output
   (i.e., revocation status for a certificate) from the given inputs
   (the certificate itself and input from local policy) is not
   standardized. For example, although this procedure is described
   as a sequence of steps to be processed in order, an implementation
   may use CRLs which are in its local cache rather than retrieving
   CRLs each time it processes a certificate, provided those CRLs are
   complete for the scope of the certificate and do not violate any
   of the parameters of the certificate or policy.
 
   The following general steps are described in B.2 through B.5 below:
      1) Determine Parameters for CRLs;
      2) Determine CRLs Required;
      3) Obtain the CRLs;
      4) Process the CRLs.

   B.5.3 Validity and currency checks on the base CRL

   In order to verify that a base CRL is accurate and has not been
   modified since its issuance, all of the following conditions shall
   be satisfied:

     * The relying party shall be able to obtain the public key of the
       issuer identified in the CRL using authenticated means; and

     * The signature on the base CRL shall be verified using this
       authenticated public key; and+

     * If the nextUpdate field is present, the current time should be
       prior to the nextUpdate field; and

     * The issuer name in the CRL shall match the issuer name in the
       certificate that is being checked for revocation, unless the CRL
       is retrieved from the CRL DP in the certificate and the
       CRL DP extension contains the CRL issuer component. In that case,
       one of the names in CRL issuer component in the CRL DP extension
       shall match issuer name in the CRL.

X.509 (B.1.2 CRL) processing does not include any dowloading of other
CA certificates besides the certification path that an RP is
currently validating, and while it suggests caching of CRLs,
it does not suggest any caching of certs.

X.509 (B.5.3) first bullet is very explicit about what is and is
not sensible for obtaining the public key of the CRL issuer.

   * using locally available trusted information is OK, such as
      - trust anchors

   * using locally available certs is OK *AFTER* successful validation
     of these certs
      - locally cached certs
      - certs from a remote _trusted_ store
      - certs that have been conveyed in-band within the communication
        with the network peer, such as a peer certificate chain,

Only querying a trusted store for an AKID found in AIA can be implemented
with a managable risk, while attempting to download certs from arbitrary
untrusted resources specified in the AIA of a unverified certificate
is always a serious security problem and contrary to
"obtain ... using authenticated means".

An RP doing forward path discovery of AIA URLs would be vulnerable to
attackers abusing that facility to entice the peer into doing
stupid, dangerous or nasty stuff, including:

   - port/service-scanning on the peers local network
   - arbitrarily poking at the peers firewall&proxies from the inside
   - have the peer arbitrarily access statcounters
   - perform ad-click fraud
   - access kiddy-pr0n URLs,
     potentially earning you a visit from law enforcment
   - hang on tcp connect timeouts

Conclusion: The typical compliant RP, with no access to an online trusted
directory, will perform certificate path validation and CRL
checking based on the following information:

   - the certification path supplied by the communication peer
   - a set of preconfigured trust anchors
   - CRLs retrieved (and optionally cached) for CRL-DPs of certs
     that have been verified to chain to an existing trust anchor

And btw. since support for AKID is strictly optional (not required
for minimum compliant implementations of rfc5280), it is up to
the CAs and the more feature-rich implementations to ensure that
certification paths sent to peers can be validated by RPs
conforming to minimum requirements.

-Martin

---

From: Bruce Stephens <[email-masked]>
Date: Tue, 24 Jan 2012 16:04:33 +0000

[...]

> it does not suggest any caching of certs.

Hmm. Then NIST.gov's Path Discovery Test Suite ought to be updated? For
example, test 4.1.2.11:

    4.1.2.11 Rudimentary LDAP Path Discovery Test11

    In this test, the end entity certificate is hierarchically
    subordinate to the trust anchor CA. The intermediate CA has used a
    different key to sign its CRL than the key used to sign the end
    entity certificate. The certificate issued by the Trust Anchor Root
    CA certifies the key needed to verify the end entity
    certificate. The self-issued certificate issued by the intermediate
    CA is signed by the key used to sign the end entity certificate and
    certifies the key needed to verify the CRL.

[...]

>    - hang on tcp connect timeouts

Yes, I guess that's all true. That suggests an update to RFC 4158 (I'm
not sure exactly what; some of the risks could presumably be mitigated
in various ways)?

>      that have been verified to chain to an existing trust anchor

So the HTTP URI tests in NIST's PDTS ought to be removed and the LDAP
URI tests ignored?

In these tests you start just with trust anchors and the EE certificates
(and access to an LDAP directory) so there's no certification path
(which is rather the point).

[...]

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 24 Jan 2012 11:48:33 -0500

Tim,

The AKID, SKID, AIA, CDO< and signer identifier etc. are efficiency mechanisms to mine the data.

An attacker can only use these to cause denial of service.

They do not identify anything except help you locate and/or disambiguate.

Section 6 of 5280 is the one that helps you establish trust in a public key and these items play no role in validation of the public key.

-----Original Message-----
From: Miller, Timothy J. [mailto:[email-masked]] 
Sent: Tuesday, January 24, 2012 8:56 AM
To: Santosh Chokhani; [email-masked]
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

On 1/23/12 3:49 PM, "Santosh Chokhani" <[email-masked]> wrote:

>have wrestled with the issues, know the problems and various ways to 
>fix them.  We do not always agree on which solution to use since using 
>some of the solutions imposes added requirements on relying parties.
>

That's more than a little unfair.  And if I *am* misunderstanding, I'm not alone.  E.g., from RFC5652:

This allows an attacker who can issue certs from *any* trust anchor in the victim's trust store to spoof *any* identity.  Given that many PKIs are private entities with no obligation to disclose fraud (or may be coerced into issuing fraudulent certs by national governments), does this really seem like a good idea to anyone?

-- T

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 24 Jan 2012 11:49:31 -0500

OK, I admit that it was poor judgment on my part to use a physical
analogy.  So amend that to the security analog of the Internet
Interoperability Principle:  Be strict in what you send means that the
Internet PKI must comply with the requirement that DNs be unique.  Be
safe in what you receive means that both senders and RPs should take
measures to limit damage when senders fail to comply.  That is
particularly important in the case where 1) it is possible for a
well-meaning sender to not comply in the absence of a global DN
registry, and 2) it is an obvious attack for an adversary to
deliberately not comply.

Because X.509 and 5280 do not clearly articulate the possibility that
DNs may not be unique due to error or maliciousness, I agree with you
that addressing the problem is an enhancement to the standards, not a
clarification of something that should already be understood by
developers.  What I do not agree with is any statement, if one was ever
made, that "there is an unambiguous requirement for DN uniqueness,
therefore it is safe to assume that DNs are always unique."

Dave K

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]] 
Sent: Monday, January 23, 2012 4:20 PM
To: Kemp, David P.
Cc: [email-masked]
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

David,

I suggest you read what people actually say before falsely accusing them
of making "circular and specious" arguments.  Timothy Miller did not
propose "to associate Issuer/Serial with a trust anchor".  He said:

	Both X.509 and RFC 5280 are not clear on this point.  They were
written
	with the understanding that the trust anchor needs to be
included when
	considering a DN, but this is a point that's lost on lots of
	implementations.

There is a major difference between prosing something and stating that
the standard was "written with the understanding that...."

I asked for evidence to support his assertion that "[X.509 and RFC 5280]
were written with the understanding that the trust anchor needs to be
included when considering a DN".

	An argument that X.509 cannot ensure uniqueness of DNs (in the
absence
	of a Directory or global DN registry) is, as you say, an
argument
	against X.509.
	
	The proposal to associate Issuer/Serial with a trust anchor
addresses
	that argument against X.509 with a mechanism that guarantees
global
	uniqueness as long as each trust anchor ensures local
uniqueness, and
	confines any collisions within a single trust anchor to its
local scope.
	
	The requirement exists.  And it is circular and specious to
argue that
	the enhancement is unnecessary "because X.509 requires DNs to be
	globally unique".  That's like arguing there's no need to
install street
	lights because there's already a regulation for streets to be
adequately
	lit.

No, this would be someone claiming that the lights on a certain street
don't meet the regulations, and then me arguing that the street does
meet the regulations since the regulations only require one street light
every 100m and the street has one street light every 90m, and then you
falsely accusing me of having said that the street was adequately lit,
even though I never suggested that the regulations were adequate.

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 24 Jan 2012 11:59:42 -0500

You misunderstand partitioning of CRL.

A CA can use any process (stochastic or deterministic) to partition CRLs and use IDP in the CRL appropriately.

If a CA wishes to partition CRL based on CA signing keys, it can do so by asserting proper DP in CDP in the certificates and proper DP in IDP in the CRL.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Tuesday, January 24, 2012 10:41 AM
To: Bruce Stephens
Cc: [email-masked]
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

After having checked various parts of rfc5280 and ITU-T X.509 and slept over it, I believe to have found the relevant information that caused my confusion.  So I'll try to clarify this myself.

I originally assumed that one possible reason for intermediate CA key rollover would be that the CA's current CRL size has grown beyond a reasonable size.  (I know US DOD CAs with CRLs of > 1 million entries that I consider unreasonably sized).

During discussion with consultants of another vendor of PKI software I was told that their product does not support rolling your own intermediate CAs subject name when rolling its keypair, so based on that description I assumed that X.509 would define partitioning of CRLs based on AKIDs in order to allow restarting with an empty CRL for the new intermediate CA keypair.

That is not the case.  X.509 does *NOT* allow partitioning of CRLs based on AKIDs. (this would have required, among several other things, CRLEntryExtension and CRL DP to include AKIDs).

So whenever a CA is operating with multiple CA certs with different public keys, complexity goes up.  The CA will have to provide a complete CRLs covering all CA certs with the same Subject Name, and must distribute it in several variants, signed with each and every one those CA certs and must configure the CRL DPs so that each issued cert references the CRL DP with the CRLSigner cert matching EXACTLY the certificate signer CA cert.

Bruce Stephens wrote:
> > For such an environment, when performing certificate revocation 
> > checking during certificate path validation for a direct CRL, that 
> > "obtain and validate the certification path for the issuer of the 
> > complete CRL", refers exactly to the validated subset of the 
> > certification path that was input to 6.1.
> 

It is the most reasonable RP behaviour, essentially required by X.509 and recommended by rfc5280 to request such a questionable path.

> could use extensions such as AIA and CRLDP to gather further 

Using CRL DP is safe (because you look at it only after verifying the signature to check for revocation), but it does not get you anywhere.

Using (URLs) from AIA on the other hand is folly because it is unsafe, and no sensible implementation would be doing this as part of an RP performing unattended certificate path validation.
Per X.509 it is a SHALL NOT, per rfc5280 it is a RECOMMENDED must not.

!! Therefore, the algorithm only includes checks to verify that the !! certification path is valid according to X.509 and does not include !! checks to verify that the certificates and CRLs conform to this !! profile.  While the algorithm could be extended to include checks for !! conformance to the profiles in Sections 4 and 5, this profile !! RECOMMENDS against including such checks.

With this explicit caveat, it is conforming to rfc5280 to use instead the algorithm specified in ITU-T X.509 for performing certificate path validation and CRL checking.  And in several places, X.509 is significantly clearer.

Quoting from ITU-T X.509

   B.1.2 CRL processing

                                             [...] The algorithm used

X.509 (B.1.2 CRL) processing does not include any dowloading of other CA certificates besides the certification path that an RP is currently validating, and while it suggests caching of CRLs, it does not suggest any caching of certs.

X.509 (B.5.3) first bullet is very explicit about what is and is not sensible for obtaining the public key of the CRL issuer.

Only querying a trusted store for an AKID found in AIA can be implemented with a managable risk, while attempting to download certs from arbitrary untrusted resources specified in the AIA of a unverified certificate is always a serious security problem and contrary to "obtain ... using authenticated means".

An RP doing forward path discovery of AIA URLs would be vulnerable to attackers abusing that facility to entice the peer into doing stupid, dangerous or nasty stuff, including:

Conclusion: The typical compliant RP, with no access to an online trusted directory, will perform certificate path validation and CRL checking based on the following information:

And btw. since support for AKID is strictly optional (not required for minimum compliant implementations of rfc5280), it is up to the CAs and the more feature-rich implementations to ensure that certification paths sent to peers can be validated by RPs conforming to minimum requirements.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Jan 2012 19:26:34 +0100 (MET)

Santosh Chokhani wrote:
> A CA can use any process (stochastic or deterministic) to
> partition CRLs and use IDP in the CRL appropriately.
> 
> If a CA wishes to partition CRL based on CA signing keys, it can do so by
> asserting proper DP in CDP in the certificates and proper DP in IDP
> in the CRL.

This works *ONLY* by using distinct issuer DNames, in which case we
are talking about different issuers, even when they're operated by the
exact same entity and differ only by e.g. a SerialNumber RDName.

The rules defined by X.509 for processing CRLs will not protect you from
accepting one partial CRL instead of another partial CRL for the exact
same issuer name that do not differ by reason code.

If you try to use operational tricks in an attempt to protect
against exploitation of protocol features for which the underlying
architecture design does not provide any protection, then you are
often going miss some scenarios and loose.  

It is much better to stay within the design limits of the base specification
and rely on the features that can reasonably be expected to be available
(the minimum interoperable set).

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 24 Jan 2012 13:43:52 -0500

Martin,

Your understanding remains in error.  You need to read and understand the CRL processing rules annex (which is normative) in X.509.

The CA DN remains unchanged.

The relying party matches the DP in CRL DP and the DP in IDP to ensure that it has the correct partition.

May be you are not understanding the approach or are thinking that the CRL DP must match the CA DN, which is not the case.

Basically it works as follows.  Let us say that the CA DN is X and the CA has n keys and decides to partition based on keys.  It uses DP Y1, Y2, Y3... Yn.

When key j is used, the DP in corresponding CRL DP in that certificate is Yj and DP in IDP in CRL for key j partition is Yj.

When the relying party gets the CRL with critical IDP, and sees Yj in DP, it ensures that the corresponding certificate has Yj in DP in CRL DP.  Note that both the objects are signed by the CA.

BTW, partitioned CRL is secure and very powerful; powerful in the sense that the CA can change its approach to partitioning unbeknownst to the relying parties since the only stipulation the relying party needs to verify to ensure that it got the correct CRL is matching two signed objects from the CA: DP in CRL DP in the certificate and DP in IDP in CRL.

Feel free to tell us where the security issue is.  We have analyzed this since 1995 and documented it in X.509 and fail to see security problem/

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, January 24, 2012 1:27 PM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

Santosh Chokhani wrote:
> A CA can use any process (stochastic or deterministic) to partition 
> CRLs and use IDP in the CRL appropriately.
> 
> If a CA wishes to partition CRL based on CA signing keys, it can do so 
> by asserting proper DP in CDP in the certificates and proper DP in IDP 
> in the CRL.

This works *ONLY* by using distinct issuer DNames, in which case we are talking about different issuers, even when they're operated by the exact same entity and differ only by e.g. a SerialNumber RDName.

The rules defined by X.509 for processing CRLs will not protect you from accepting one partial CRL instead of another partial CRL for the exact same issuer name that do not differ by reason code.

If you try to use operational tricks in an attempt to protect against exploitation of protocol features for which the underlying architecture design does not provide any protection, then you are often going miss some scenarios and loose.  

It is much better to stay within the design limits of the base specification and rely on the features that can reasonably be expected to be available (the minimum interoperable set).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Jan 2012 20:29:58 +0100 (MET)

Santosh Chokhani wrote:
> Feel free to tell us where the security issue is.  We have analyzed this
> since 1995 and documented it in X.509 and fail to see security problem/

Your scheme appears to rely on the CRL DP of the cert always being compared
to the CRL DP on the CRL.  Tough luck--the CRL DP in the CRL is optional,
so you will have to expect some RPs to implement an efficient CRL caching
(completely unwrapped) where the CRL DP on the CRL is completely ignored
for the actual revocation lookup.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 24 Jan 2012 14:40:44 -0500

Originally, CRL DP was designed to partition the CRL.  If CRL DP is not included in a certificate, that certificate cannot go in a partition.

When you ignore a critical IDP extension in CRL, you are insecure.  So, the relying party has a choice when IDP is present in the CRL (IDP is always a critical extension) to either understand and process it or reject the CRL.

Most PKE clients I know such as CAPI, PKIF and NSS do not have problem handling this,

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, January 24, 2012 2:30 PM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [pkix] AuthKeyId and CrlEntryExtension.CertificateIssuer

Santosh Chokhani wrote:
> Feel free to tell us where the security issue is.  We have analyzed 
> this since 1995 and documented it in X.509 and fail to see security 
> problem/

Your scheme appears to rely on the CRL DP of the cert always being compared to the CRL DP on the CRL.  Tough luck--the CRL DP in the CRL is optional, so you will have to expect some RPs to implement an efficient CRL caching (completely unwrapped) where the CRL DP on the CRL is completely ignored for the actual revocation lookup.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 24 Jan 2012 21:38:28 +0100 (MET)

Santosh Chokhani wrote:
> 
> Originally, CRL DP was designed to partition the CRL.
> If CRL DP is not included in a certificate, that certificate
> cannot go in a partition.
> 
> When you ignore a critical IDP extension in CRL, you are insecure.

Actually, I believe your envisioned PKI setup is insecure because
it is outside of the design limits of X.509.

If someone fubars his PKI so badly, so that there is no
CRL DP with full scope listed in his certs, or that the CRL
returned from that URL is unusable for the promised purpose,
then for our RP the customer will have to manually configure a download
URL for that issuerName so that our CRL cache can populated/updated
out-of-band with conforming CRLs ... or disable revocation checking
for that issuerName.

Quoting from the last paragraph of rfc5280 section 5

    http://tools.ietf.org/html/rfc5280#page-55

                                            Conforming applications
   that support CRLs are REQUIRED to process both version 1 and version
   2 complete CRLs that provide revocation information for all
   certificates issued by one CA.  Conforming applications are not
   required to support processing of delta CRLs, indirect CRLs, or CRLs
   with a scope other than all certificates issued by one CA.

The obvious and straightforward approach to partitioning CRLs
by CA certs is to create CA certs that differ in the issuerName e.g.
by adding a SerialNumber RDName component.  That will work
reliably with every RP that supports CRLs.

Telling apart intermediate CA DNames during troubleshooting is
magnitudes harder when they do not differ in name (especially
when error messages only quote the supposedly unique issuerNames).

And you get fresh empty CRLs for free whenever you roll your CA cert.

-Martin

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 24 Jan 2012 22:33:16 +0100

> > When you ignore a critical IDP extension in CRL, you are insecure.

This point is important.
If you ignore a *critical* extension, then you fail. Completely. You're
free to ignore any non critical extension (at least in X.509, not RFC5280),
but if you encounter a critical extension that you don't understand, you
MUST reject the object.

> out-of-band with conforming CRLs ... or disable revocation checking

Would you trust such a CA?

-- 
Erwann.