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

From: Peter Sylvester <[email-masked]>
Date: Fri, 29 Oct 2004 12:30:26 +0200 (MEST)

> 
> Peter.Sylvester> At least you would probably agree that a CA cannot
> Peter.Sylvester> sign another CA having the same DN (because this
> Peter.Sylvester> would be considered as a self signed cert).

> 
> I agree in a way, but the parenthesis makes me wonder if you're not
> mixing things up.  There is a difference between self-issued CA
> certificates (where two CA certificates have the same subject) and a
> self-signed CA certificate (where the public key in one certificate
> can be used to verify the signature in that same certificate).  The
> former is typically present as soon as you do a CA certificate roll-
> over.

I was indeed not correctly using the term  'self signed'. The
common point is something where the subject and isseur DN are the same
and a path determination logic concludes that it is the same
entity. 

> But I agree that two different CAs (two different organizations, in
> other words) "cannot" have the same DN.  I write "cannot", because
> it's still technically possible, and whenever that happens, one can
> only expect a small appocalypse.

The message was that I don't think that it is worth
to provide PKI path determination technology that can work
with two CA entities having the same name. 

If two PKIs join and have such a situation, then there may
also be a incompatibility in the certification policies. Or,
if not, maybe an inconsistency in 'joint' policy since the joint
naming schemme allows for that. 

Peter

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 29 Oct 2004 14:05:09 +0100

Peter,
 
I disagree. I think it is very important to cover for the case where 2 CAs may have the same name.
 
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. 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.
 
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.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

________________________________

Från: [email-masked] genom Peter Sylvester
Skickat: fr 10/29/2004 12:30
Till: [email-masked]; [email-masked]
Kopia: [email-masked]
Ämne: Re: Briefing on CRL Path for IETF PKIX WG Meeting

Peter

---

From: "Stefan Santesson" <[email-masked]>
Date: Sat, 30 Oct 2004 15:59:23 +0100

Peter,

I assume that this encapsulates the issue:
<snip>
> 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.

Yes and no.

Validation software should start with the assumption that two
certificates (CA or CRLissuer type), carrying the same subject name,
represent different entities until it can determine that they are
offspring of the same ancestors according to the algorithm proposed by
Santosh.

This approach is much more attack resilient and reduce complexity in
path validation. 

I don't see how building a local database is neither generally feasible
nor a valid alternative.

Stefan Santesson
 
> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Peter Sylvester
> Sent: den 29 oktober 2004 18:06
> To: [email-masked]; Stefan Santesson
> Cc: [email-masked]
> Subject: Re: SV: Briefing on CRL Path for IETF PKIX WG Meeting
> 
> 
> >
> > 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. :-)
>