Subject: Re: SV: Briefing on CRL Path for IETF PKIX WG Meeting

From: Peter Sylvester <[email-masked]>
Date: Fri, 29 Oct 2004 18:06:13 +0200 (MEST)

> 
> Peter,
>  
> I disagree. I think it is very important to cover for the case where 2 CAs may have the same name.
>  

I am not against having someone to provide a specification how to construct
a local database and a way to detect such a situation inside the potato
of cross certificates connected CA suppended by trust hooks. 

> In troducing indirect CRLs means that we introduce possible attack vectors and it is our responsibility to create rules that makes vulnerabilities as unlikely as possible, even in bad implementations (80%+ of all vulnerabilities are miconfiguration problems).
>  
> If you include trust in public roots, then It is virtually impossible to guarantee and check that there are not any CAs with name collisions anywhere. 

If the PKI "database" is just a set of otherwise isolated parts each
of them hanging on one trusted root without cross certs amongs the parts, then
the situation is rather simple, i.e. you have different PKIs, if not, what
do you propose?  

The problem to me seems what you should assume when you find two keys attributes to the same CA name?
probably whene you have a crosscert pair each key certifying the other? 

> As writer of validation code, we must close every possible weaknes for an error, miconfiguration or attack.

When you write a piece of software, It may be hard to predict in what context that software will be running. You can't say that this code is only for use in aninfrastructure with CAs without name collisions, unless the code have some means of detecting such environment and refuse to operate in it. This is not the case however.

Are you saying that in the presence of two CA certs with same name having a different key, one general should
first assume that they belong to different entities, and only if one finds a cross certificate pair of
one signing the other key and vice versa, you may conclude that you have the same entity so you look for
CRLs signed by *the same* CA but the other key. 

> The other aspect is complexity. Use of indirect CRLs without any limitations may lead to infinitely complex path validation where every new path introduce more CRL paths and where each new CRL path introduce new CRL paths which introduce new CRL paths etc.......  Denial of service attacks through complex paths isn't faar away.

I don't understand why you say this here. What make this more difficult, a requirement that CAs are unique or
the contrary? Welcome in the real world. :-)

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 30 Oct 2004 08:12:08 -0400

Peter,

I do not understand what you wrote very well.

The basic point is that if you have two CA certificates with different keys
in the directory and as a relying party you obtain those two certificates,
both may be valid for a certificate or CRL certification path.  If one is
used for the certificate certification path and the other one is used for
the CRL certification path, you determine if they are the same CA, by
checking all the ancestors.  That is a simple  way to describe the path
matching algorithm.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Peter Sylvester
Sent: Friday, October 29, 2004 12:06 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: SV: Briefing on CRL Path for IETF PKIX WG Meeting

I am not against having someone to provide a specification how to construct
a local database and a way to detect such a situation inside the potato of
cross certificates connected CA suppended by trust hooks. 

> In troducing indirect CRLs means that we introduce possible attack 
> vectors and it is our responsibility to create rules that makes
vulnerabilities as unlikely as possible, even in bad implementations (80%+
of all vulnerabilities are miconfiguration problems).
>  
> If you include trust in public roots, then It is virtually impossible 
> to guarantee and check that there are not any CAs with name collisions 
> anywhere.

If the PKI "database" is just a set of otherwise isolated parts each of them
hanging on one trusted root without cross certs amongs the parts, then the
situation is rather simple, i.e. you have different PKIs, if not, what do
you propose?  

The problem to me seems what you should assume when you find two keys
attributes to the same CA name? probably whene you have a crosscert pair
each key certifying the other? 

> an error, miconfiguration or attack.

When you write a piece of software, It may be hard to predict in what
context that software will be running. You can't say that this code is only
for use in aninfrastructure with CAs without name collisions, unless the
code have some means of detecting such environment and refuse to operate in
it. This is not the case however.

Are you saying that in the presence of two CA certs with same name having a
different key, one general should first assume that they belong to different
entities, and only if one finds a cross certificate pair of one signing the
other key and vice versa, you may conclude that you have the same entity so
you look for CRLs signed by *the same* CA but the other key. 

> The other aspect is complexity. Use of indirect CRLs without any 
> limitations may lead to infinitely complex path validation where every 
> new path introduce more CRL paths and where each new CRL path 
> introduce new CRL paths which introduce new CRL paths etc.......  
> Denial of service attacks through complex paths isn't faar away.

I don't understand why you say this here. What make this more difficult, a
requirement that CAs are unique or the contrary? Welcome in the real world.
:-)