Subject: RE: Briefing on CRL Path for IETF PKIX WG Meeting

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 3 Nov 2004 10:17:04 -0500

Denis,

See response in-line in [SC:]

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Wednesday, November 03, 2004 9:47 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

> Denis,

> The CA name is defined by DN.  Since multiple CAs could have the same 
> name, in order to disambiguate the CA, you should consider the ancestors.

So we both agree.

> That is  what the algorithm does.

However, the above argument does not validate the algorithm in anyway.

[SC: Please identify what is wrong with the algorithm.]

Denis

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Thursday, October 28, 2004 9:59 AM
> To: Santosh Chokhani
> Cc: 'Jean-Marc Desperrier'; [email-masked]
> Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> Santosh,
> 
> 
>>Jean-Marc:
> 
> 
>>I agree that X.509 and 3280 define a CA by name.
> 
> 
> You disagree since you said: "a CA name is disambiguated by 
> ancestors", which is true.
> 
> Denis
> 
> 
>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]] On Behalf Of Jean-Marc 
>>Desperrier
>>Sent: Wednesday, October 27, 2004 11:32 AM
>>To: [email-masked]
>>Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting
>>
>>
>>
>>Denis Pinkas wrote:
>>
>>
>>
>>>Jean-Marc,
>>>
>>>
>>>
>>>>I'd say that the X509 rule is that a CA is defined by it's DN alone,
>>>>therefore one should never try to create two CA with the same DN in a 
>>>>properly managed hierarchy.
>>>
>>>For X.509, I do *not* say X.500, a DN is only relative to the CA who
>>>has given it.
>>
>>
>>I had no idea we had established that.
>>I only remember several messages asking why we would try to handle in 
>>PKIX the case of several CA with the same DN as it's invalid.
>>
>>In his presentation, to show that a CA is defined by name alone,
>>Santosh
>>refers specifically only to section 7 of X.509, and I think that must be 
>>in reference to the following sentence :
>>NOTE 1 - Although the CAs are unambiguously defined by a distinguished 
>>name in the DIT, this does not imply that there is any relationship 
>>between the organization of the CAs and the DIT
>>which I don't see as supporting what you say.
>>
>>I can see that you already said the same thing from this message
>>http://www.imc.org/ietf-pkix/mail-archive/msg03305.html
>>Quote :
>>"[Denis : a CA can never be defined by a name only. It is a name 
>>issued
>>by a given CA. It can also be a root key with a sequence of names. These 
>>are the only ways names can be unambiguous].
>>
>>[Santosh: I do not find support for anything other than Issuer being
>>identified by DN only in X.509 and 3280.]"
>>
>>But I can not find any message in which you gave additional info in
>>answer to Santosh's doubts.
>>
>>
> 
> 
> 
>

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 03 Nov 2004 15:46:30 +0100

Santosh,

> The CA name is defined by DN.  Since multiple CAs could have the same name,
> in order to disambiguate the CA, you should consider the ancestors.  

So we both agree.

Denis

> You disagree since you said: "a CA name is disambiguated by ancestors",
> which is true.
> 
> Denis
> 
>

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 04 Nov 2004 18:38:45 +0100

Santosh,

See response in-line in [DP:]

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Wednesday, November 03, 2004 9:47 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

So we both agree.

[DP: Please correct first the algorithm to include CA names instead of CRL 
Issuer names]

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 4 Nov 2004 15:51:31 -0500

Denis,

See responses in-line.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Thursday, November 04, 2004 12:39 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Wednesday, November 03, 2004 9:47 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

 > The CA name is defined by DN.  Since multiple CAs could have the same  >

So we both agree.

[SC: As I said 1-2 weeks ago, CA variables were chosen to differentiate
between CAs in certificate certification path and CAs in the CRL
certification path,  I am sure most people on this list understand that
these are all CAs]

Denis

---

From: "Julien Stern" <[email-masked]>
Date: Fri, 5 Nov 2004 19:37:47 +0100

All,

I believe X509 and PKIX are even much more flawed with respect to
CRL validation that underligned by Santosh. The flaw appear as soon
as it valid to sign a certificate and a CRL with different keys.

I think the flaw CANNOT be solved without modifying the existing
certificates or simply disallowing these different keys.
Let me explain:

We all agree that a CA is defined by name. However, if two CAs have the
same name, one of them may be able to revoke the other CA certificates.
I believe we agree on this flaw of X509 and RFC3280, but I think the
algorithm proposed by Santosh does not change the situation.

The flaw is more severe and is due to the fact that, when
a CA is using two different certificates for signing certificate and
signing CRLs, they are unrelated. In order to solve the flaw, we need
to link these two certificates by an other mean that the ancestors.
Actually, we probably need to sign the CRL signing certificate with the
certificate signing certificate.

More precisely, if a CA, _any_ CA, whose certificate validates with
respect to one of your Trust Anchor, agrees to deliver me a certificate
whose DN is the same DN as Verisign, I will easily be able to revoke
all Verisign certificates.

The simple attack goes as follow:

1) Find any moderately honest CA who agrees to sign me a
certificate signing certificate and a CRL signing certificate
whose DNs match Verisign DN.

2) For the certificate signing certificate, send a CSR whose public
key matches the _real_ Verisign CA certificate.

3) For the CRL signing certificate, send a CSR whose public key
correspond to a private key I know.

4) Finally, simply revoke any legitimate Verisign user by producing
CRLs signed with this private key.

A path building algorithm will have two choices to go up when validating
a Verisign certificate, (that is, two certificate with matching DN and
key). It it chooses mine, then, the path building chain will go up
to the same TA as the chain coming from my CRL and all the DNs will
match.

Conclusions:

- The current CRL checking algorithm is flawed
- Santosh proposal solves some problems but unfortunately, not all
- A possible way to solve the problem would be:

1) Simply disallow different keys for certificate and CRL signing 
2) If different keys are allowed, then the CRL signing key MUST
be signed with the certificate signing key with an appropriate
delegation extension (aka ~ indirect CRLs)

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 5 Nov 2004 16:07:08 -0500

Julien,

The algorithm proposed specifically eliminates the risk.

The certificate certification path and the CRL certification path will not
match because CRL certification path has the node VeriSign CA in it and the
certificate certification path has the node real_VersiSign CA in it.

May be you mean that the two CAs have really the same DN.  Well, in that
case, the algorithm makes sure that all the DNs of the CAs in the two paths
match (one for one) starting with the DN of the trust anchor.  So, in order
for the attack to work, a CA in the system must have certified two distinct
CAs for the same subject DN.  If a CA does that, all bets are off.

Please look at the algorithm closely.  It is match two different paths.

Also, look at the extension that cryptographically binds the CA's keys to
the CRL.

BTW, Step 2 should not happen in a PKI.  A CA must not bind a public key to
a wrong subject (specially, when the subject is a CA).  This is one of the
reasons we require proof of possession of a private key.  But, even with
Step 2 that no CA would do, the algorithm will not let another claim to be
you.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Friday, November 05, 2004 1:38 PM
To: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

All,

I believe X509 and PKIX are even much more flawed with respect to CRL
validation that underligned by Santosh. The flaw appear as soon as it valid
to sign a certificate and a CRL with different keys.

I think the flaw CANNOT be solved without modifying the existing
certificates or simply disallowing these different keys. Let me explain:

We all agree that a CA is defined by name. However, if two CAs have the same
name, one of them may be able to revoke the other CA certificates. I believe
we agree on this flaw of X509 and RFC3280, but I think the algorithm
proposed by Santosh does not change the situation.

The flaw is more severe and is due to the fact that, when
a CA is using two different certificates for signing certificate and signing
CRLs, they are unrelated. In order to solve the flaw, we need to link these
two certificates by an other mean that the ancestors. Actually, we probably
need to sign the CRL signing certificate with the certificate signing
certificate.

More precisely, if a CA, _any_ CA, whose certificate validates with respect
to one of your Trust Anchor, agrees to deliver me a certificate whose DN is
the same DN as Verisign, I will easily be able to revoke all Verisign
certificates.

1) Find any moderately honest CA who agrees to sign me a certificate signing
certificate and a CRL signing certificate whose DNs match Verisign DN.

2) For the certificate signing certificate, send a CSR whose public key
matches the _real_ Verisign CA certificate.

3) For the CRL signing certificate, send a CSR whose public key correspond
to a private key I know.

4) Finally, simply revoke any legitimate Verisign user by producing CRLs
signed with this private key.

A path building algorithm will have two choices to go up when validating a
Verisign certificate, (that is, two certificate with matching DN and key).
It it chooses mine, then, the path building chain will go up to the same TA
as the chain coming from my CRL and all the DNs will match.

Conclusions:

1) Simply disallow different keys for certificate and CRL signing 
2) If different keys are allowed, then the CRL signing key MUST be signed
with the certificate signing key with an appropriate delegation extension
(aka ~ indirect CRLs)

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 05 Nov 2004 16:37:52 -0500

Julien,

I don't believe that the scenario you described indicates a flaw in 
X.509/RFC 3280. Your scenario begins with the assumption that your were 
able to get a CA to issue you a CA certificate with a subject DN of 
Verisign (you further assumed that were valid certification paths from 
one or more trust anchors used by relying parties to this CA).

Once an attacker has been issued a valid CA certificate the system is 
compromised (until the certificate that has been issued to the attacker 
has been revoked). In your scenario, you could just as easily have 
obtained a CA certificate (with keyCertSign set) with a public key 
corresponding to a private key that you knew. You would then be able to 
issue bogus certificates, not just revoke legitimate ones. If an 
attacker were issued a CA certificate from one of the CAs in my PKI 
(such that my relying parties would validate certificates issued by that 
CA), that CA's ability to revoke valid certificates would be the least 
of my concerns since the CA could also issue bogus certificates.

I would also like to point out that a PKI in which two different CAs 
have the same name is invalid. The algorithm that Santosh has proposed 
works to mitigate the damage that would result if two different CAs in a 
PKI were using the same DN, but this is a scenario that should never 
happen in the first place. From my point of view, the main benefit of 
Santosh's proposal is that it improves efficiency by reducing the number 
of paths that one needs to consider during path discovery without 
putting undue restrictions on the PKI architecture.

I know that Denis Pinkas has stated: "For X.509, I do *not* say X.500, a 
DN is only relative to the CA who has given it." Presumably he is 
arguing that it is perfectly legitimate for two CAs in a PKI to have the 
same name; the only requirement being that a CA can not issue two 
certificates with the same subject DN in which the subjects are 
different entities. If this is the case though, I would like to know 
where X.509 says this or even what text in X.509 implies that this is 
the case. Section 7 of X.509 states "CAs are unambiguously defined by a 
distinguished name in the DIT", which seems to contradict Denis' claim.

In conclusion, in X.509 it is not legitimate for two different entities 
to have the same DN and it is particularly important to ensure that two 
different CAs in a PKI do not use the same DN. At the same time, 
defense-in-depth is always a good strategy and in that light Santosh's 
algorithm does a good job of protecting against the risk that a PKI will 
evolve in which two different CAs do use the same DN.

Dave

---

From: "Julien Stern" <[email-masked]>
Date: Sat, 6 Nov 2004 14:38:23 +0100

Santosh,

See response in-line.

> Please look at the algorithm closely.  It is match two different paths.

Well, I might be wrong, be I believe my scenario is NOT eliminated by
your proposal.

You say that your assumption is that a CA in the system must not certify
two distincts CAs for the same subject DN. Which would be:

     CA1
     DN1
    /   \
  CA2   CA3
  DN2   DN2

In the scenario I envisionned, the "graph" would be:

    CA1        ROGUECA
    DN1          DN3
     |          /   \
    CA2       CA3   CA3  <- CA3 is a single CA with Cert and CRL keys
    DN2       DN2   DN2
    KEY1      KEY1  KEY2

Now, I have a legitime certificate EE issued by CA2, with DN2 and KEY2.
The path building algorithm has TWO choices to reconstruct the path
(well unless specific helper extensions are used, but we should not
rely on them for security), namely:

    CA1        ROGUECA
    DN1          DN3
     |          /   \
    CA2       CA3   CA3  <- CA3 is a single CA with Cert and CRL keys
    DN2       DN2   DN2
    KEY1      KEY1  KEY2
       \      /      |
         \  /        |
          EE      Fake CRL

If it goes on the "left" side, you proposal prevents the attack.
If it goes on the "right" side, you proposal does not, because the CRL
has a match for all the ancestors.
Consequently, we are in a situation where the same certificate will
be seen as revoked or not depending on the first path chosen by the
path building algorithm, which is believe is bad.

> Step 2 that no CA would do, the algorithm will not let another claim to be

I agree step 2 should not happen. I guess that if I could possibly
convince a CA to give a a CA cert with Verisign DN, I could also
convince it to "forget" to verify the POP :)

But serioulsy, I believe that such a RogueCA can indeed publish fake
CRLs that would be validated even by your improved algorithm.

Please let me know if you believe I overlooked something

Sincerely,

--
Julien

---

From: "Julien Stern" <[email-masked]>
Date: Sat, 6 Nov 2004 15:43:20 +0100

David,

See response in-line.

> of my concerns since the CA could also issue bogus certificates.

I do not think that the issue you describe and the one I described
are situed at the same level.

Let me explain:
Assume your configuration trusts exactly two TAs, say Verisign
and Thawte. Also assume that both of them have a complex hierarchy
of CAs below them.  

Now, all the CAs in these two hierarchies can produce "valid" EE certs,
that is, certs that will be validated by path verification algorithm.

The fact that one of the CA low in the hierarchy would have the same
DN as Verisign does not change anything to the problem. And while this
"should not happen", this does not endanger security as long as your TAs
are legitimate. If a CA produces bogus certificates, (which cannot be
theoretically prevented), its certificate should be revoked, but the DN
is irrelevant.

Now, in my (admitedly twisted, my possible) scenario, 
the DN _is_ relevant for security. A dishonest CA with a normal unique
DN cannot revoke all Verisign certificates, but a dishonest CA with
the same DN as Verisign could revoke all verisign certificates even
if located low below Thawte hierarchy.

> putting undue restrictions on the PKI architecture.

I think Santosh algorithm is very nice, but as you said, it only
mitigates the risk, and I believe I proposed a scenario in which
I can fool this algorithm.

A also personally agree that a PKI in which two different entities have
the same DN is invalid (although the consensus on this does not seem
to be general). However, we have to assume it could happen, possibly
due to a dishonest participant. And, in fact, for pure certificate path
verification, this possibly invalid situation does not adversely affect
security. Hence, we also have to ensure that it does not affect security
when processing CRLs. We all agree it currently does, and IMHO the issue
is not entirely solved by Santosh algorithm. If a CRL signer key belongs
to a given CA, I think it has to be cryptographically binded to the CA
certificate signing key in some way.

> evolve in which two different CAs do use the same DN.

As I have just said before, I personally concur with your analysis,
but think that the proposed defence-in-depth is not sufficient and that
we need cryptographic binding.

Sincerely,

--
Julien

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 6 Nov 2004 11:56:04 -0500

Julien,

A CA is not permitted to issue certificates to two distinct entities with
the same name.  Your example violates this constraint.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Saturday, November 06, 2004 8:38 AM
To: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

See response in-line.

On Fri, Nov 05, 2004 at 04:07:08PM -0500, Santosh Chokhani wrote:
> The certificate certification path and the CRL certification path will 
> not match because CRL certification path has the node VeriSign CA in 
> it and the certificate certification path has the node real_VersiSign 
> CA in it.
> 
> May be you mean that the two CAs have really the same DN.  Well, in 
> that case, the algorithm makes sure that all the DNs of the CAs in the 
> two paths match (one for one) starting with the DN of the trust 
> anchor.  So, in order for the attack to work, a CA in the system must 
> have certified two distinct CAs for the same subject DN.  If a CA does 
> that, all bets are off.
> 

Well, I might be wrong, be I believe my scenario is NOT eliminated by your
proposal.

You say that your assumption is that a CA in the system must not certify two
distincts CAs for the same subject DN. Which would be:

     CA1
     DN1
    /   \
  CA2   CA3
  DN2   DN2

    CA1        ROGUECA
    DN1          DN3
     |          /   \

Now, I have a legitime certificate EE issued by CA2, with DN2 and KEY2. The
path building algorithm has TWO choices to reconstruct the path (well unless
specific helper extensions are used, but we should not rely on them for
security), namely:

    CA1        ROGUECA
    DN1          DN3
     |          /   \

If it goes on the "left" side, you proposal prevents the attack. If it goes
on the "right" side, you proposal does not, because the CRL has a match for
all the ancestors. Consequently, we are in a situation where the same
certificate will be seen as revoked or not depending on the first path
chosen by the path building algorithm, which is believe is bad.

> Also, look at the extension that cryptographically binds the CA's keys 
> to the CRL.
> 
> BTW, Step 2 should not happen in a PKI.  A CA must not bind a public 
> key to a wrong subject (specially, when the subject is a CA).  This is 
> one of the reasons we require proof of possession of a private key.  
> But, even with Step 2 that no CA would do, the algorithm will not let 
> another claim to be you.

I agree step 2 should not happen. I guess that if I could possibly convince
a CA to give a a CA cert with Verisign DN, I could also convince it to
"forget" to verify the POP :)

But serioulsy, I believe that such a RogueCA can indeed publish fake CRLs
that would be validated even by your improved algorithm.

Sincerely,

--
Julien

> [mailto:[email-masked]] On Behalf Of Julien Stern
> validation that underligned by Santosh. The flaw appear as soon as it 
> valid to sign a certificate and a CRL with different keys.
> 
> We all agree that a CA is defined by name. However, if two CAs have 
> the same name, one of them may be able to revoke the other CA 
> certificates. I believe we agree on this flaw of X509 and RFC3280, but 
> I think the algorithm proposed by Santosh does not change the 
> situation.
> 
> Actually, we probably need to sign the CRL signing certificate with 
> the certificate signing certificate.
> 
> respect to one of your Trust Anchor, agrees to deliver me a 
> certificate whose DN is the same DN as Verisign, I will easily be able 
> to revoke all Verisign certificates.
> 
> 1) Find any moderately honest CA who agrees to sign me a certificate 
> signing certificate and a CRL signing certificate whose DNs match 
> Verisign DN.
> 
> A path building algorithm will have two choices to go up when 
> validating a Verisign certificate, (that is, two certificate with 
> matching DN and key). It it chooses mine, then, the path building 
> chain will go up to the same TA as the chain coming from my CRL and 
> all the DNs will match.
> 
> Conclusions:
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 6 Nov 2004 12:02:20 -0500

Julien,

Even if a CA down in the chain had the same name as VeriSign, the matching
algorithm will work since all the CA DNs starting and including that of the
trust anchor and up to the end of the CRL path (in case of direct CRL) must
match those in the certificate certification path.  Thus, a downstream
VeriSign can not masquerade an upstream VeriSign.

The only way a CA can masquerade as another CA is if all the CASs in their
paths (including the trust anchor) have the same DN.  In order for that to
happen, a CA at same level must certify two distinct authorities for the
same DN.  X.509 does not permit. That.  If CA does this wrong, all bets are
off.  For that matter, a CA could post its private key on the Internet.  We
do not have defense against that.

You are encouraged to carefully read, analyze, and understand the algorithm.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Saturday, November 06, 2004 9:43 AM
To: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

David,

See response in-line.

> of my concerns since the CA could also issue bogus certificates.

I do not think that the issue you describe and the one I described are
situed at the same level.

Let me explain:
Assume your configuration trusts exactly two TAs, say Verisign and Thawte.
Also assume that both of them have a complex hierarchy of CAs below them.  

Now, all the CAs in these two hierarchies can produce "valid" EE certs, that
is, certs that will be validated by path verification algorithm.

The fact that one of the CA low in the hierarchy would have the same DN as
Verisign does not change anything to the problem. And while this "should not
happen", this does not endanger security as long as your TAs are legitimate.
If a CA produces bogus certificates, (which cannot be theoretically
prevented), its certificate should be revoked, but the DN is irrelevant.

Now, in my (admitedly twisted, my possible) scenario, 
the DN _is_ relevant for security. A dishonest CA with a normal unique DN
cannot revoke all Verisign certificates, but a dishonest CA with the same DN
as Verisign could revoke all verisign certificates even if located low below
Thawte hierarchy.

> putting undue restrictions on the PKI architecture.

I think Santosh algorithm is very nice, but as you said, it only mitigates
the risk, and I believe I proposed a scenario in which I can fool this
algorithm.

A also personally agree that a PKI in which two different entities have the
same DN is invalid (although the consensus on this does not seem to be
general). However, we have to assume it could happen, possibly due to a
dishonest participant. And, in fact, for pure certificate path verification,
this possibly invalid situation does not adversely affect security. Hence,
we also have to ensure that it does not affect security when processing
CRLs. We all agree it currently does, and IMHO the issue is not entirely
solved by Santosh algorithm. If a CRL signer key belongs to a given CA, I
think it has to be cryptographically binded to the CA certificate signing
key in some way.

> evolve in which two different CAs do use the same DN.

As I have just said before, I personally concur with your analysis, but
think that the proposed defence-in-depth is not sufficient and that we need
cryptographic binding.

Sincerely,

--
Julien

> >certificates. I believe we agree on this flaw of X509 and RFC3280, 
> >but I think the algorithm proposed by Santosh does not change the 
> >situation.
> >
> >certificate whose DN is the same DN as Verisign, I will easily be 
> >able to revoke all Verisign certificates.
> >

---

From: "Julien Stern" <[email-masked]>
Date: Sat, 6 Nov 2004 23:49:22 +0100

Santosh,

As I have stated in my previous email, my example does not violates
this constraint. No CA ever issues certificates to two distincts
entities with the same name. I simply have two DIFFERENT CAs that issue
certificates to different entities with the same name.

Consequently , I still this my example is valid.

--
Julien

---

From: "Julien Stern" <[email-masked]>
Date: Sat, 6 Nov 2004 23:57:56 +0100

> do not have defense against that.

I disagree with the previous paragraph.
What you describe is one way to masquerade as an other CA.
My example is an other way to do so. You seem to assume that
certification paths from EE to TAs are unique. If a create a rogue
cert which matches a real CA DN and key, the path building algorithm
might pick my certificate.

Consequently, your algorithm works if
1) No CA issues two certificates to two entities with the same DN.
AND
2) No CA issues a certificate matching the DN and key of another CA.

My example uses the second case, not the first one.

> You are encouraged to carefully read, analyze, and understand the algorithm.

I read it very carefully, analyzed it, hopefully understood it, and
actually implemented it. It was during the implementation that what I
think is a the flaw was highlighted.

If you also have a implementation, would you like me to produce a set of
certificates which highlight the problem I talking about ?

--
Julien

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 6 Nov 2004 20:22:04 -0500

Julien,

If you have certification path for the certificate ending at the rogue root,
all bets about 3280 not just CRL path matching are off.

For example, all the rogue PKI hierarchy needs to do is issue the end
certificates (by certifying the legitimate EE public keys) using its keys
and then it can also issue CRLs even using a key that matches the
certificate signing keys.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Saturday, November 06, 2004 5:58 PM
To: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

On Sat, Nov 06, 2004 at 12:02:20PM -0500, Santosh Chokhani wrote:
> 
> Julien,
> 
> Even if a CA down in the chain had the same name as VeriSign, the 
> matching algorithm will work since all the CA DNs starting and 
> including that of the trust anchor and up to the end of the CRL path 
> (in case of direct CRL) must match those in the certificate 
> certification path.  Thus, a downstream VeriSign can not masquerade an 
> upstream VeriSign.
> 
> The only way a CA can masquerade as another CA is if all the CASs in 
> their paths (including the trust anchor) have the same DN.  In order 
> for that to happen, a CA at same level must certify two distinct 
> authorities for the same DN.  X.509 does not permit. That.  If CA does 
> this wrong, all bets are off.  For that matter, a CA could post its 
> private key on the Internet.  We do not have defense against that.

I disagree with the previous paragraph.
What you describe is one way to masquerade as an other CA.
My example is an other way to do so. You seem to assume that certification
paths from EE to TAs are unique. If a create a rogue cert which matches a
real CA DN and key, the path building algorithm might pick my certificate.

Consequently, your algorithm works if
1) No CA issues two certificates to two entities with the same DN. AND
2) No CA issues a certificate matching the DN and key of another CA.

> You are encouraged to carefully read, analyze, and understand the 

I read it very carefully, analyzed it, hopefully understood it, and actually
implemented it. It was during the implementation that what I think is a the
flaw was highlighted.

--
Julien

> > X.509/RFC 3280. Your scenario begins with the assumption that your 
> > were able to get a CA to issue you a CA certificate with a subject 
> > DN of Verisign (you further assumed that were valid certification 
> > paths from one or more trust anchors used by relying parties to this 
> > CA).
> > 
> > Once an attacker has been issued a valid CA certificate the system 
> > is compromised (until the certificate that has been issued to the 
> > attacker has been revoked). In your scenario, you could just as 
> > easily have obtained a CA certificate (with keyCertSign set) with a 
> > public key corresponding to a private key that you knew. You would 
> > then be able to issue bogus certificates, not just revoke legitimate 
> > ones. If an attacker were issued a CA certificate from one of the 
> > CAs in my PKI (such that my relying parties would validate 
> > certificates issued by that CA), that CA's ability to revoke valid 
> > certificates would be the least of my concerns since the CA could 
> > also issue bogus certificates.
> 
> Assume your configuration trusts exactly two TAs, say Verisign and 
> Thawte. Also assume that both of them have a complex hierarchy of CAs
below them.
> 
> Now, all the CAs in these two hierarchies can produce "valid" EE 
> certs, that is, certs that will be validated by path verification 
> algorithm.
> 
> "should not happen", this does not endanger security as long as your 
> TAs are legitimate. If a CA produces bogus certificates, (which cannot 
> be theoretically prevented), its certificate should be revoked, but 
> the DN is irrelevant.
> 
> > have the same name is invalid. The algorithm that Santosh has 
> > proposed works to mitigate the damage that would result if two 
> > different CAs in a PKI were using the same DN, but this is a 
> > scenario that should never happen in the first place. From my point 
> > of view, the main benefit of Santosh's proposal is that it improves 
> > efficiency by reducing the number of paths that one needs to 
> > consider during path discovery without putting undue restrictions on 
> > the PKI architecture.
> 
> mitigates the risk, and I believe I proposed a scenario in which I can 
> fool this algorithm.
> 
> A also personally agree that a PKI in which two different entities 
> have the same DN is invalid (although the consensus on this does not 
> seem to be general). However, we have to assume it could happen, 
> possibly due to a dishonest participant. And, in fact, for pure 
> certificate path verification, this possibly invalid situation does 
> not adversely affect security. Hence, we also have to ensure that it 
> does not affect security when processing CRLs. We all agree it 
> currently does, and IMHO the issue is not entirely solved by Santosh 
> algorithm. If a CRL signer key belongs to a given CA, I think it has 
> to be cryptographically binded to the CA certificate signing key in 
> some way.
> 
> > I know that Denis Pinkas has stated: "For X.509, I do *not* say 
> > X.500,
> > a

> but think that the proposed defence-in-depth is not sufficient and 
> that we need cryptographic binding.
> 
> Sincerely,
> 
> --
> Julien
> 
> > Julien Stern wrote:
> > 
> > >All,
> > >
> > >CRL
> > >The flaw is more severe and is due to the fact that, when a CA is 
> > >using two different certificates for signing certificate and 
> > >signing CRLs, they are unrelated. In order to solve the flaw, we 
> > >need to link these two certificates by an other mean that the 
> > >ancestors. Actually, we probably need to sign the CRL signing 
> > >certificate with the certificate signing certificate.
> > >
> > >certificate
> > >2) If different keys are allowed, then the CRL signing key MUST be 
> > >signed with the certificate signing key with an appropriate

---

From: "Julien Stern" <[email-masked]>
Date: Sun, 7 Nov 2004 17:04:14 +0100

Santosh,

As I said in my other email,
the fact that any CA ("rogue" or not) can issue a cert to any EE and
revoke this very cert is normal behavior. The problem I was underligning
is that a rogue CA can revoke an EE cert already issued by an _other_
unrelated CA.

--
Julien

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 7 Nov 2004 13:27:53 -0500

Julien,

In your example also, the rouge CA is not able to impact the behavior of the
certificate chain under the proper CA hierarchy.  There is no PKI security
to a certificate taken alone without a certification path starting at a
trust anchor.  If you trust the certificate chain starting with a rogue CA,
you are in trouble.

The rogue CA can only revoke a certificate in its certification path.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Sunday, November 07, 2004 11:04 AM
To: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

On Sat, Nov 06, 2004 at 08:22:04PM -0500, Santosh Chokhani wrote:
> 
> Julien,
> 
> If you have certification path for the certificate ending at the rogue 
> root, all bets about 3280 not just CRL path matching are off.
> 
> certificates (by certifying the legitimate EE public keys) using its 
> keys and then it can also issue CRLs even using a key that matches the 

Santosh,

As I said in my other email,
the fact that any CA ("rogue" or not) can issue a cert to any EE and revoke
this very cert is normal behavior. The problem I was underligning is that a
rogue CA can revoke an EE cert already issued by an _other_ unrelated CA.

--
Julien

> If you also have a implementation, would you like me to produce a set 
> of certificates which highlight the problem I talking about ?
> 
> --
> Julien
> 
> 
> > the DN _is_ relevant for security. A dishonest CA with a normal 
> > unique DN cannot revoke all Verisign certificates, but a dishonest 
> > CA with the same
> DN
> > as Verisign could revoke all verisign certificates even if located 
> > low
> below
> > Thawte hierarchy.
> > 
> > > In conclusion, in X.509 it is not legitimate for two different 
> > > entities to have the same DN and it is particularly important to 
> > > ensure that two different CAs in a PKI do not use the same DN. At 
> > > the same time, defense-in-depth is always a good strategy and in 
> > > that light Santosh's algorithm does a good job of protecting 
> > > against the risk that a PKI will
> 

> > > >We all agree that a CA is defined by name. However, if two CAs 
> > > >have the same name, one of them may be able to revoke the other 
> > > >CA certificates. I believe we agree on this flaw of X509 and 
> > > >RFC3280, but I think the algorithm proposed by Santosh does not 
> > > >change the situation.
> > > >
> > > >More precisely, if a CA, _any_ CA, whose certificate validates 
> > > >with respect to one of your Trust Anchor, agrees to deliver me a 
> > > >2) For the certificate signing certificate, send a CSR whose 
> > > >public key matches the _real_ Verisign CA certificate.
> > > >
> > > >4) Finally, simply revoke any legitimate Verisign user by 
> > > >producing CRLs signed with this private key.
> > > >
> > > >chain will go up to the same TA as the chain coming from my CRL 
> > > >and all the DNs will match.
> > > >
> > > >Conclusions:
> > > >
> > > >be

---

From: "Julien Stern" <[email-masked]>
Date: Mon, 8 Nov 2004 13:44:33 +0100

Santosh,

I just don't understand your reasoning any more.
I though that the goal of your "path matching algorithm" was to prevent
a Rogue CA from revoking certificates issued by an other unrelated CA.

I though this very stated fairly clearly in
draft-ietf-pkix-certpathbuild-04.txt section 8.2 (although you are not
listed as a co-author so it may not represent your view (?)).

If we assume that there is no rogue CA at all then, we do not need to
check anything anyway. Now, if we assume there can indeed be a rogue CA,
the example I gave you shows that a Rogue CA can _still_ revoke any
certificate from any unrelated CA in spite of your proposal.

We seem to have a disagrement on the core security assumptions. I will
attempt in the next days to write a small note to formalize my points,
by precisely defining the security model I envision, then maybe we can
find the source of our mutual un-understanding.

--
Julien

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 08 Nov 2004 15:19:45 +0100

Julien,

You are quite right. There is a major problem with Santosh's proposal.

Instead of trying to debug the proposed algorithm, it would be much better 
to describe first what the trust model is.

Leaving aside indirect CRLs, which may be supported by a trillion of all 
different and unrelated models, there are several questions to answer:

First question: What is a CRL Issuer ?

Hereafter is a strawman proposal:

CRL Issuer : an authority that issues and signs CRLs. When the CRL is not 
signed by the CA itself, the CRL shall be signed by a CRL Issuer identified 
in the CRL distribution point extension of the certificate.

Second question : How is the CRL Issuer identified in the CRL distribution 
point extension of the certificate ?

Hereafter a strawman response: it is identified using cRLIssuer.

         cRLIssuer               [2]     GeneralNames

Third question: which form of name shall be used ?

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

GeneralName ::= CHOICE {
      otherName                       [0]     AnotherName,
      rfc822Name                      [1]     IA5String,
      dNSName                         [2]     IA5String,
      x400Address                     [3]     ORAddress,
      directoryName                   [4]     Name,
      ediPartyName                    [5]     EDIPartyName,
      uniformResourceIdentifier       [6]     IA5String,
      iPAddress                       [7]     OCTET STRING,
      registeredID                    [8]     OBJECT IDENTIFIER }

RFC 3280 states: "the cRLIssuer MUST contain at least one an X.500 
distinguished name (DN)".

Fourth question: which CA shall certify that name ?

Neither RFC 3280 nor X.509 provides a response for that question.
Put in another way, who will nominate the CRL Issuer and thus will issue the 
CRL Issuer certificate ?

  ... and we are back with the two proposals I made (on which I got no 
response from Santosh):

Here it is again:

The CRL Issuer is *not* the CA. This CA is called CA 1.
CA 2 is a CA that has issued a CA certificate to CA 1.

  a) the CRL Issuer is nominated by CA 1 that has issued
     the end-user certificate. This case would make sense
     when CA 2 has allowed CA 1 to issue CRLs but CA 1 delegates
     that role to one or more CRL Issuers. This means that
     a CRL Issuer certificate is issued by CA 1 to every CRL Issuer.

  b) the CRL Issuer is nominated by CA 2 that has issued a CA
     certificate to CA 1. This case would make sense when CA 2
     has not allowed CA 1 to issue CRLs. This means that a CRL Issuer
     certificate is issued by CA 2 to every CRL Issuer. CA 1 may
     then only choose a CRL Issuer that has been granted
     the authorization to issue CRLs by CA 2.

Other cases are the trillion cases of indirect CRLs.

Denis

>>>>>arguing that it is perfectly legitimate for two CAs in a PKI to have
>>>>
>>the
>>
>>>>>the case. Section 7 of X.509 states "CAs are unambiguously defined by
>>>>
>>a 
>>
>>>>>distinguished name in the DIT", which seems to contradict Denis'
>>>>
>>claim.
>>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 8 Nov 2004 10:14:56 -0500

Julien,

The security of the solution and assumptions are on par with what X.509 and
3280 are based on.

It disambiguates between two CRL Issuer with the same name.

The scenario of a rogue CA can cause all sorts of problems for the relying
party and not just in deciding if the CRL is from the correct issuer.

If the relying party recognizes the difference (which it should) between the
two CAs at the top of the trust graph in your example, then the rogue CA can
not fool the relying party into accepting its certification path and CRL.

Furthermore, you have provided one scenario where a rogue CA can revoke
certificates it did not issue.  I have provided another scenario where the
same rogue CA can fool the relying parties into using its (meaning rogue
CA's) certificates and CRLs for a subscriber.  The point being, that PKI
does not offer much protection against the rogue CA trusted by a relying
party aside from constraining trust graphs with respect to name spaces and
certificate policies.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Monday, November 08, 2004 7:45 AM
To: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

On Sun, Nov 07, 2004 at 01:27:53PM -0500, Santosh Chokhani wrote:
> Julien,
> 
> In your example also, the rouge CA is not able to impact the behavior 
> of the certificate chain under the proper CA hierarchy.  There is no 
> PKI security to a certificate taken alone without a certification path 
> starting at a trust anchor.  If you trust the certificate chain 
> starting with a rogue CA, you are in trouble.
> 

Santosh,

I just don't understand your reasoning any more.
I though that the goal of your "path matching algorithm" was to prevent a
Rogue CA from revoking certificates issued by an other unrelated CA.

If we assume that there is no rogue CA at all then, we do not need to check
anything anyway. Now, if we assume there can indeed be a rogue CA, the
example I gave you shows that a Rogue CA can _still_ revoke any certificate
from any unrelated CA in spite of your proposal.

We seem to have a disagrement on the core security assumptions. I will
attempt in the next days to write a small note to formalize my points, by
precisely defining the security model I envision, then maybe we can find the
source of our mutual un-understanding.

--
Julien

> revoke this very cert is normal behavior. The problem I was 
> underligning is that a rogue CA can revoke an EE cert already issued 
> by an _other_ unrelated CA.
> 
> --
> Julien
> 
> > > including that of the trust anchor and up to the end of the CRL 
> > > path (in case of direct CRL) must match those in the certificate 
> > > certification path.  Thus, a downstream VeriSign can not 
> > > masquerade an upstream VeriSign.
> > > 
> > > The only way a CA can masquerade as another CA is if all the CASs 
> > > in their paths (including the trust anchor) have the same DN.  In 
> > > order for that to happen, a CA at same level must certify two 
> > > distinct authorities for the same DN.  X.509 does not permit. 
> > > That.  If CA does this wrong, all bets are off.  For that matter, 
> > > a CA could post its private key on the Internet.  We do not have 
> > > defense against that.
> > 
> > What you describe is one way to masquerade as an other CA. My 
> > example is an other way to do so. You seem to assume that 

> > > > CA).
> > > > 
> > > > Once an attacker has been issued a valid CA certificate the 
> > > > system is compromised (until the certificate that has been 
> > > > issued to the attacker has been revoked). In your scenario, you 
> > > > could just as easily have obtained a CA certificate (with 
> > > > keyCertSign set) with a public key corresponding to a private 
> > > > key that you knew. You would then be able to issue bogus 
> > > > certificates, not just revoke legitimate ones. If an attacker 
> > > > were issued a CA certificate from one of the CAs in my PKI (such 
> > > > that my relying parties would validate certificates issued by 
> > > > that CA), that CA's ability to revoke valid certificates would 
> > > > be the least of my concerns since the CA could also issue bogus 
> > > > certificates.
> > > 
> > > The fact that one of the CA low in the hierarchy would have the 
> > > same DN as Verisign does not change anything to the problem. And 
> > > while this "should not happen", this does not endanger security as 
> > > long as your TAs are legitimate. If a CA produces bogus 
> > > certificates, (which cannot be theoretically prevented), its 
> > > certificate should be revoked, but the DN is irrelevant.
> > > 

> > > mitigates the risk, and I believe I proposed a scenario in which I 
> > > can fool this algorithm.
> > > 
> > > have the same DN is invalid (although the consensus on this does 
> > > not seem to be general). However, we have to assume it could 
> > > happen, possibly due to a dishonest participant. And, in fact, for 
> > > pure certificate path verification, this possibly invalid 
> > > situation does not adversely affect security. Hence, we also have 
> > > to ensure that it does not affect security when processing CRLs. 
> > > We all agree it currently does, and IMHO the issue is not entirely 
> > > solved by Santosh algorithm. If a CRL signer key belongs to a 
> > > given CA, I think it has to be cryptographically binded to the CA 
> > > > X.500, a
> > > > same name; the only requirement being that a CA can not issue 
> > > > two certificates with the same subject DN in which the subjects 
> > > > are different entities. If this is the case though, I would like 
> > > > to know where X.509 says this or even what text in X.509 implies 
> > > > that this is the case. Section 7 of X.509 states "CAs are 
> > > > unambiguously defined by
> a
> > > As I have just said before, I personally concur with your 
> > > analysis, but think that the proposed defence-in-depth is not 
> > > sufficient and that we need cryptographic binding.
> > > 
> > > Sincerely,
> > > 
> > > --
> > > Julien
> > > 
> > > > Julien Stern wrote:
> > > > 
> > > > >All,
> > > > >
> > > > >I believe X509 and PKIX are even much more flawed with respect 
> > > > >to CRL validation that underligned by Santosh. The flaw appear 
> > > > >as soon as it
> 
> > > > >The flaw is more severe and is due to the fact that, when a CA 
> > > > >is using two different certificates for signing certificate and 
> > > > >signing CRLs, they are unrelated. In order to solve the flaw, 
> > > > >we need to link these two certificates by an other mean that 
> > > > >the ancestors. Actually, we probably need to sign the CRL 
> > > > >signing certificate with the certificate signing certificate.
> > > > >

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 8 Nov 2004 10:51:50 -0500

Denis,

What you are describing is already in 3280 and X.509.

If you identity specific problem with the algorithm, I will be glad to act
on it or respond.

As to Julien scenario, I would generalize that a relying party is not safe
if it trusts a rogue CA for all name spaces and policies.  That is a fact of
life for the whole PKI, including (but not just for) the path matching
algorithm.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Monday, November 08, 2004 9:20 AM
To: Julien Stern
Cc: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Julien,

GeneralName ::= CHOICE {

Neither RFC 3280 nor X.509 provides a response for that question. Put in
another way, who will nominate the CRL Issuer and thus will issue the 
CRL Issuer certificate ?

Here it is again:

Denis

> I though that the goal of your "path matching algorithm" was to 
> prevent a Rogue CA from revoking certificates issued by an other 
> unrelated CA.
> 
> check anything anyway. Now, if we assume there can indeed be a rogue 
> CA, the example I gave you shows that a Rogue CA can _still_ revoke 
> any certificate from any unrelated CA in spite of your proposal.
> 
>>>>certification path.  Thus, a downstream VeriSign can not masquerade 
>>>>an upstream VeriSign.
>>>>
>>>>authorities for the same DN.  X.509 does not permit. That.  If CA 
>>>>does this wrong, all bets are off.  For that matter, a CA could post 
>>>>its private key on the Internet.  We do not have defense against 
>>>>that.
>>>
>>>What you describe is one way to masquerade as an other CA. My example 
>>>is an other way to do so. You seem to assume that certification paths 
>>>from EE to TAs are unique. If a create a rogue cert which matches a 
>>>>>then be able to issue bogus certificates, not just revoke 
>>>>>legitimate ones. If an attacker were issued a CA certificate from 
>>>>>one of the CAs in my PKI (such that my relying parties would 
>>>>>validate certificates issued by that CA), that CA's ability to 
>>>>>revoke valid certificates would be the least of my concerns since 
>>>>>the CA could also issue bogus certificates.
>>>>
>>>>DN as Verisign does not change anything to the problem. And while 
>>>>this "should not happen", this does not endanger security as long as 
>>>>your TAs are legitimate. If a CA produces bogus certificates, (which 
>>>>cannot be theoretically prevented), its certificate should be 
>>>>revoked, but the DN is irrelevant.
>>>>
>>>>>different entities. If this is the case though, I would like to 
>>>>>know where X.509 says this or even what text in X.509 implies that 
>>>>>this is the case. Section 7 of X.509 states "CAs are unambiguously 
>>>>>defined by
>>>>
>>a
>>
>>>>>>CRL validation that underligned by Santosh. The flaw appear as 
>>>>>>soon as it
>>>>>

---

From: Russ Housley <[email-masked]>
Date: Mon, 08 Nov 2004 11:22:45 -0500

>First question: What is a CRL Issuer ?

RFC 3280 says:

    CRL issuer: an optional system to which a CA delegates the
                publication of certificate revocation lists;

Russ

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 8 Nov 2004 11:43:34 -0500

Denis,

When you look at 3280 and add what I propose, what do you see is missing?

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Monday, November 08, 2004 11:35 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

> What you are describing is already in 3280 and X.509.

If it is the case, would you copy and paste that text, please ? Otherwise, I
understand that you agree with my text.

Denis

> If you identity specific problem with the algorithm, I will be glad to 
> act on it or respond.
> 
> As to Julien scenario, I would generalize that a relying party is not 
> safe if it trusts a rogue CA for all name spaces and policies.  That 
> is a fact of life for the whole PKI, including (but not just for) the 
> path matching algorithm.
> 
> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> Neither RFC 3280 nor X.509 provides a response for that question. Put 
> in another way, who will nominate the CRL Issuer and thus will issue 
> the CRL Issuer certificate ?
>

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 08 Nov 2004 17:34:49 +0100

Santosh,

> What you are describing is already in 3280 and X.509.

If it is the case, would you copy and paste that text, please ?
Otherwise, I understand that you agree with my text.

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 8 Nov 2004 11:40:33 -0500

Denis,

Please look at the pkix archives of 11/4/2003 t0 11/6/2003, specifically my
posting, your responses, and my responses to your issues.

The subject of e-mails is "CRL Certification Path"

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

Julien,

GeneralName ::= CHOICE {

Here it is again:

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 09 Nov 2004 09:30:32 +0100

Russ,

>                publication of certificate revocation lists;

True, but thus is vague. Page 43 adds further explanations:

    The cRLIssuer identifies the entity who signs and issues the CRL.
    If present, the cRLIssuer MUST contain at least one an X.500
    distinguished name (DN), ...

So here is a strawman proposal for 3280bis:

"CRL issuer: an authority that issues and signs CRLs. When a CRL is
not signed by the CA itself, the CRL shall be signed by a CRL Issuer
identified in the CRL distribution point extension of the certificate.

Note: in the later case, the CRL Issuer certificate shall be issued
       by that CA."

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 9 Nov 2004 06:26:22 -0500

Denis,

See responses in-line in [SC]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Tuesday, November 09, 2004 3:31 AM
To: Russ Housley
Cc: [email-masked]; David A. Cooper
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Russ,

"CRL issuer: an authority that issues and signs CRLs. When a CRL is not
signed by the CA itself, the CRL shall be signed by a CRL Issuer identified
in the CRL distribution point extension of the certificate.

{SC: I do not have objections to it, but I am not sure of the difference
between the two.  Also, note that if the certificate issuer signs the CRL,
crlIssuer field must be absent in the CRL DP.]

[SC: I have objection to this on two grounds: One, this is a new constraints
and breaks some existing implementations,  Two, if the CA wanted to delegate
all CRL issuance, having this requirement will either cause a circular
problem (insecure) or not permit the CA to promulgate the revocation status
of the certificate issued to the CRL Issuer.]

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 09 Nov 2004 15:12:19 +0100

Santosh,

This was a response to Russ that you intercepted.

 > crlIssuer field must be absent in the CRL DP.]

   ... which is covered by the sentence :
       "When a CRL is not signed by the CA itself, ..."

 > and breaks some existing implementations,

Let us see what the second objection is.

 > Two, if the CA wanted to delegate
 > problem (insecure)

With this sentence, you have not demonstrated any circular problem,
nor any insecurity.

 > or not permit the CA to promulgate the revocation status

What would be the content of the CRL DP extension from the CRL Issuer
certificate ?

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 09 Nov 2004 15:24:29 +0100

Santosh,

> When you look at 3280 and add what I propose, what do you see is missing?

Since you asked ... I will explain what is wrong in your slides.

Slide 5. The statement " A CA is defined by name alone" is
wrong. A CA is not simply defined by a name alone. A name,
for X.509, is always relative to the CA which has issued it.
So the "clarification' to say that a CA is unambiguously
defined by name is wrong. Then since the other slides are
based on that wrong assumption, they are wrong as well.

Slide 7:  There is no "need to account for multiple CAs with
the same name". This formulation is pretty bad. A CA must
provide different names to two different entities. Since a CA
name is relative to another CA name space, there cannot be
two CAs with the same name.

Slide 8: The statement : "There can be more than one CA with
the same name" is wrong. Once again, a (CA) name is always
relative to a CA name space.

Slide 8: The statement "starting from a TA, the relying party
can match the CA names in [ ] the CRL certification paths" is
wrong as well. There is no such notion of a "CRL
certification path".

As indicated in RFC 3280, a CRL issuer is an optional
system to which a CA delegates the publication of CRLs.
This sentence is correct, but vague. (X.509 does not provide
a clear definition of what a CRL Issuer is).

Page 43 from RFC 3280: "The cRLIssuer identifies the entity
who signs and issues the CRL. If present, the cRLIssuer MUST
contain at least one an X.500 distinguished name (DN).

A CA will thus identify the DN of the CRL Issuer in the
cRLIssuer field from a CRL distribution point extension.

That DN needs to be be compared with a subject DN from a CRL Issuer
certificate, i.e. a certificate which has the cRLSign bit set
(and that has that DN as the subject name).

The question is then simply : how can a RP know that that CRL Issuer
certificate has been issued by the right CA ?

A simple answer to that question is to say that the CA that has
placed the CRL DP extension must be the one that has issued the
CRL Issuer certificate.

This means something very important. The TA used to verify
the CRL Issuer certificate is the same as the one used to verify
the certificate to be validated. All intermediate CAs are
identical.

This rule can easily be interpreted by a relying party since
it needs first to have the certification path.

This is not the case for the algorithm you proposed, where
different TAs are used on one side to validate the certificate to be
validated and on the other side the CRL Issuer certificate.

In this algorithm, two CRL Issuers with the same DN might appear
in different certification paths. So multiple CRL Issuer names
could match the criteria. The algorithm you proposed is flawed.

Denis

>>signed by the CA itself, the CRL shall be signed by a CRL Issuer
> 
> identified 
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 9 Nov 2004 09:30:51 -0500

Denis,

I am sorry if you did not expect me to respond.  I am not aware of any rule
that we are not supposed to respond to the e-mail.

As to circularity, the problem is as follows.

Let us say CA A delegates the CRL issuance to Authority B.  Your proposal
requires that A issue a certificate to B will get in the way of a CA not
issuing CRLs because if the CA does not issue CRL, how would the revocation
status of certificate A --> B be checked?

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Tuesday, November 09, 2004 9:12 AM
To: Santosh Chokhani
Cc: pkix
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

 > True, but thus is vague. Page 43 adds further explanations:  >
identified  > in the CRL distribution point extension of the certificate.  >

 > [SC: I have objection to this on two grounds: One, this is a new
constraints  > and breaks some existing implementations,

 > all CRL issuance, having this requirement will either cause a circular  >
problem (insecure)

With this sentence, you have not demonstrated any circular problem, nor any
insecurity.

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 9 Nov 2004 11:00:19 -0500

Denis,

I missed one of your questions.  Here is the response.

-----Original Message-----
<Snip>

[SC: In a simple case, the cRLIssuer field can be the DN of CRL issuer.
Assuming the CRL is published in directory, no other fields need to be
populated.  If the DP is populated to assist relying parties, the DP could
be an URL to the CRL]

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 9 Nov 2004 14:57:50 -0500

Denis,

None of your comment seem to object to the path matching algorithm.

Please see specific responses below.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Tuesday, November 09, 2004 9:24 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

Slide 5. The statement " A CA is defined by name alone" is wrong. A CA is
not simply defined by a name alone. A name, for X.509, is always relative to
the CA which has issued it. So the "clarification' to say that a CA is
unambiguously defined by name is wrong. Then since the other slides are
based on that wrong assumption, they are wrong as well.

[SC: Here is the quote from X.509 "NOTE 1 - Although the CAs are
unambiguously defined by a distinguished name in the DIT, this does not
imply that there is any relationship between the organization of the CAs and
the DIT."]

Slide 7:  There is no "need to account for multiple CAs with the same name".
This formulation is pretty bad. A CA must provide different names to two
different entities. Since a CA name is relative to another CA name space,
there cannot be two CAs with the same name.

[SC: There is requirement or mechanism that ensures that a relying party
with multiple trust anchors will not encounter two CAs with the same name.
If a relying party has two trust anchors A and B and there are two distinct
companies with the same name C, it is possible that one C is certified via A
and another via B.]

Slide 8: The statement : "There can be more than one CA with the same name"
is wrong. Once again, a (CA) name is always relative to a CA name space.

[SC: There is requirement or mechanism that ensures that a relying party
with multiple trust anchors will not encounter two CAs with the same name.
If a relying party has two trust anchors A and B and there are two distinct
companies with the same name C, it is possible that one C is certified via A
and another via B.]

Slide 8: The statement "starting from a TA, the relying party can match the
CA names in [ ] the CRL certification paths" is wrong as well. There is no
such notion of a "CRL certification path".

[SC: When you get a CRL by the Issuer name of the CA and the signature does
not verify, you will need to develop a certification path for the CRL.  Your
other choices are: do not check revocation information, or take the CRL on
faith even though signature has not been verified.  I do not consider either
of these choices in compliance with 3280.  Feel free to provide other
choices that do not entail building a certification path for the CRL.]

[SC: From the long discourse below, it seems that you are focused only on
indirect CRL issuance problem.  The path matching algorithm tries to solve
that as well as when the CA has used different keys to sign certificates and
CRL (e.g., due to key roll over or in general using two keys to sign the two
objects.]

Page 43 from RFC 3280: "The cRLIssuer identifies the entity
who signs and issues the CRL. If present, the cRLIssuer MUST contain at
least one an X.500 distinguished name (DN).

A CA will thus identify the DN of the CRL Issuer in the cRLIssuer field from
a CRL distribution point extension.

[SC: So far, I agree and the briefing is aligned with this]

That DN needs to be compared with a subject DN from a CRL Issuer
certificate, i.e. a certificate which has the cRLSign bit set (and that has
that DN as the subject name).

[SC: cRLSign bit is out side the scope of path matching.  All 3280 checks
for CRL imply.  As to name matching.  As to the name match check, that is
what bullet 1 on slide 13 does.]

A simple answer to that question is to say that the CA that has placed the
CRL DP extension must be the one that has issued the CRL Issuer certificate.

[SC: This is one model.  There are other model where the CA need not issue a
certificate to the indirect CRL issuer]

This means something very important. The TA used to verify
the CRL Issuer certificate is the same as the one used to verify the
certificate to be validated. All intermediate CAs are identical.

[SC: The path matching algorithm accounts for this.  Since there is no
requirement for the certificate issuing CA to directly issue a certificate
to the indirect CRL issuer, the matching algorithm may terminates
prematurely.]

This is not the case for the algorithm you proposed, where different TAs are
used on one side to validate the certificate to be validated and on the
other side the CRL Issuer certificate.

[SC: The algorithm requires that the DN representing the same TA be used for
both paths. (See bullet 1 on slide 12.  The reason the same key (and hence
TA) is not used is to accommodate the case of the TA having been re-keyed.]

In this algorithm, two CRL Issuers with the same DN might appear in
different certification paths. So multiple CRL Issuer names could match the
criteria. The algorithm you proposed is flawed.

[SC: Can you give a more concrete example of it.  I know that the rules are
liberal for indirect CRL issuer since I do not believe that direct
delegation model is required]

Denis

>>Instead of trying to debug the proposed algorithm, it would be much
>>better to describe first what the trust model is.
>>
>>Leaving aside indirect CRLs, which may be supported by a trillion of
>>all different and unrelated models, there are several questions to 
>>answer:
>>
>>CRL Issuer : an authority that issues and signs CRLs. When the CRL is
>>Second question : How is the CRL Issuer identified in the CRL
>>distribution point extension of the certificate ?
>>

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 10 Nov 2004 10:56:13 +0100

Santosh,

My responses with [DP1:]

===================================================================

Denis,

Santosh,

[DP1:  ... and this tells you exactly what I said]

[DP1: The assumption : "there is requirement or mechanism that ensures
that a relying party with multiple trust anchors will not encounter
two CAs with the same name" is fully wrong ! The same name may be found.]

[DP1: See above]

[DP1: It is quite the reverse. You got a CRL and you need to find out
if it is signed by the right key. You have to go down the tree and
not up the tree to make the right verification. You need to know
if the CA has nominated or not the candidate CRL Issuer, make sure
that the nomination is correct and has not been revoked. None of the
choices you mention are assumptions that I am making]

[DP1: Before geeting into complicated cases like key rollover, we need
to make sure that the simple case where the CA is not signing the CRLs
for a given certificate is correctly addressed. There is no notion of
"CRL certification path"]

[DP1: I am glad you agree with this, but I would not say that your
briefing is aligned with this]

[DP1: path matching is a mandatory feature, other tests need to be done;
in particular whether it is a CRL Issuer certificate. Only a test on
the keyUsage extension may provide you with this guarantee. Name matching
is more complicated that a DN comparison. DN comparison can only be made
if you know that th DNs are assigned by the same CA].

[DP1: This is indeed the simpler model which SHALL be at least supported.
I envisaged another model, and it may be debatable if it should be
supported or not. I do do envisage more than two models, otherwise
we have a trillon cases where CRL Issuer issues revocation status
information for certificates and do not have received any delegation
of authority for that]

[DP1: the problem is that the algorithm allows much more that this !
Then we can debate around the sentence you used above: "since there is
no requirement for the certificate issuing CA to directly issue
a certificate to the indirect CRL issuer". The big question is still
how the RP can know which CA is *allowed to nominate* the CRL Issuer.
As said earlier, the simplest model is precisely that the certificate
issuing CA directly issues a certificate to the indirect CRL issuer]

[DP1: Your statement saying that "the algorithm requires that the DN
representing the same TA be used for both paths" is wrong. For TAs what
is important is both the value of the public key and of the DN, but not
the value of the DN alone. In addition, this is not an assumption made
in your slides]

[DP1: Quite easy.
Let us consider a certification chain: TA -> CA1 -> CA2 -> CA3.
CA1 can nominate a CRL Issuer with the following DN:
C0=US, DN="Gold CRLIssuer".
CA3 can also nominate a CRL Issuer with the following DN:
C0=US, DN="Gold CRLIssuer"].

[DP1: I believe that this long thread is sufficient to convince the chairs
that there is indeed yet not a consensus on that topic, and that instead
of slides we would need to agree on text addition in 3280bis. However,
before this, we need to agree on the concepts. I would have liked to
have corridor discussions with you on that topic before the PKIX meeting,
however I can't make it. I would think that a conference call, with a
moderator, would be useful if you are still not convinced by the above
arguments. Now, maybe someone else, in a face to face meeting before
or after the PKIX meeting could explain you better that I can do why
we have no consensus].

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 10 Nov 2004 13:39:45 +0100

Santosh,

My response with [DP: ]

[DP: I would rephrase the problem in the following way:

Let us say CA A delegates the CRL issuance to CRL Issuer B.
This requires that CA A issues a CRL Issuer certificate to CRL Issuer B.

The question you asked is then:
"How to make sure that this CRL Issuer certificate is not revoked ?"

This depends what kind of information tha CA A places in the CRL DP
extension of the CRL Issuer certificate issued to CRL Issuer B.

There are, at least, two answers:

1) there is no cRLIssuer field in the CRL DP extension:
    this means that the CA is directly taking care of the revocation
    status of its CRL Issuers: it will issue CRLs only for the
    CRL Issuers.

2) there is no CRL DP extension at all:
    this would mean that the CA does not issue CRLs for its CRL Issuers.
    In case one of the CRL issuers would need to be revoked, it will ask
    its "normal" upper CA to revoke its own certificate. By implication,
    the CRL Issuer certificate that was issued would become invalid.]

Both approaches have advantages and disavantages.
Anyway, thank you for raising the question.

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 10 Nov 2004 09:21:35 -0500

Denis,

We are not communicating effectively.  I am sure others are not following us
either.

I will glad to discuss things with you after the PKIX meeting today, if you
are around.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Wednesday, November 10, 2004 7:40 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

My response with [DP: ]

Let us say CA A delegates the CRL issuance to CRL Issuer B. This requires
that CA A issues a CRL Issuer certificate to CRL Issuer B.

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 10 Nov 2004 15:36:02 +0100

To the list,

After a direct (phone) talk with Julien, we came to the conclusion that, for 
the time being (i.e. without changing anything in the definition CRL DP 
extension), there is a *single* method which is secure for any CA (different 
from the TA) in a certification chain.

In the following, there is an attempt to define that single method.

The requirements for the CA would be:

"The CA that places a CRL DP extension in a certificate with a cRLIssuer
field present SHALL issue a CRL Issuer certificate for the DN contained
in that cRLIssuer field".

  ... while the requirements for RPs would be :

"When a CRL is not signed by the CA that has issued the certificate
to be validated, then that CRL SHALL be *verified* by the RP using
the public key of a CRL Issuer contained in a CRL Issuer certificate
that has been issued by the CA that has placed a CRL DP extension
in the certificate to be validated and where the DN contained in
the subject field from that CRL Issuer certificate SHALL match
the DN contained in the cRLIssuer field of the CRL DP extension."

Additional sentences would need to address the means to make sure
that the CRL Issuer certificate is not revoked (see my previous
e-mail on that topic).

Denis

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 11 Nov 2004 14:42:33 +1300

>We are not communicating effectively.  I am sure others are not following us

Well, there had been an off-list suggestion that this thread be used as a
substitute for generic-brand valium...

Peter :-).

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 10 Nov 2004 21:34:21 -0500

Denis,

X.509 states:

NOTE 1 - Although the CAs are
unambiguously defined by a distinguished name in the DIT, this does not
imply that there is any relationship between the organization of the
CAs and
the DIT.

Where in X.509 does it say or even imply that a CA in not defined by
name alone, but that a name is always relative to the CA which has
issued it?  I can't find anything in X.509 to support this.  On the
other hand, there is plenty to support the notion a CA is defined by
name alone.  In addition to the above quote, note that the
cRLDistributionPoints extension identifies an indirect CRL issuer by
name alone as does the certificateIssuer CRL entry extension.  This
makes sense if a CA can be identified by name alone but does not make
sense if a CA name is only relative to the CA which has issued it.
Similarly, in many protocols, a certificate is identified by issuer
name and serial number.  These two pieces of information would not be
sufficient to identify a certificate if your interpretation were
correct.

I also do not understand your scenarios for indirect CRL issuance
(below).  A CA is always allowed to issue CRLs that cover its own
certificates or delegate the issuance of CRLs to another entity.  If
one CA issues a cross-certificate to another CA with cRLSign set to
FALSE, that does not mean that the subject CA is not permitted to issue
CRLs.  It simply means that the subject public key in that
cross-certificate can not be used to verify CRL signatures. It could
simply be that the subject CA uses different keys to sign certificates
and CRLs.  The subject CA could always create a self-issued certificate
with cRLSign set to TRUE in which the subject public key in the
self-issued certificate corresponds to the CRL signing key.  This would
not be contrary to X.509 at all.

Dave

Denis Pinkas wrote:

Slide 5.
The statement " A CA is defined by name alone" is

Denis Pinkas wrote:

The CRL
Issuer is *not* the CA. This CA is called CA 1.

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 10 Nov 2004 21:34:21 -0500

Denis,

X.509 states:

Dave

Denis Pinkas wrote:

Slide 5.

Denis Pinkas wrote:

The CRL

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 10 Nov 2004 09:21:35 -0500

Denis,

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

Santosh,

My response with [DP: ]

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 10 Nov 2004 13:39:45 +0100

Santosh,

My response with [DP: ]

Denis

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 11 Nov 2004 14:42:33 +1300

Peter :-).

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 9 Nov 2004 14:57:50 -0500

Denis,

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Tuesday, November 09, 2004 9:24 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Santosh,

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 10 Nov 2004 15:36:02 +0100

To the list,

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 10 Nov 2004 10:56:13 +0100

Santosh,

My responses with [DP1:]

Denis,

Santosh,

[DP1: See above]

[DP1: Quite easy.

Denis