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

From: "Julien Stern" <[email-masked]>
Date: Tue, 2 Nov 2004 10:29:50 +0100

Greetings,

the more posting about this issue and the more confused I am :)
I understood that

1) Ideally, a DN should uniquely identify a entity.

2) If two Trust Anchors with the same DN are different entities, there
is a major (configuration) problem.

3) If two certificates have the same DN but represent different entitities
that is a mistake (or an attack). That must be detected.

4) The way to detect it is to check for the ancestors according to the
algorithm proposed by Santosh.

Is that correct ?
Is there a consensus on this ?
Shouldn't OCSP have a special treatment on that respect ?

Sincerely,

--
Julien Stern

On Sat, Oct 30, 2004 at 03:59:23PM +0100, Stefan Santesson wrote:
> 
> 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
> Microsoft Security Center of Excellence (SCOE)
>  
> > -----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. :-)
> > 
> 
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 2 Nov 2004 06:14:16 -0500

Julien,

See responses in-line.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Tuesday, November 02, 2004 4:30 AM
To: [email-masked]
Subject: Re: SV: Briefing on CRL Path for IETF PKIX WG Meeting

Greetings,

the more posting about this issue and the more confused I am :) I understood
that

2) If two Trust Anchors with the same DN are different entities, there is a
major (configuration) problem.

[RP should never do this]

[This is not necessarily a mistake or attack.  This can be due to
distributed nature of cross certified CAs and PKIs]

[Right]

Is that correct ?
[Yes]
Is there a consensus on this ?
[Postings I have seen support this]
Shouldn't OCSP have a special treatment on that respect ?
[Certification path for any check is subject to this be it, end entity, CRL
signer, OCSP response signer)

Sincerely,

--
Julien Stern

On Sat, Oct 30, 2004 at 03:59:23PM +0100, Stefan Santesson wrote:
> I don't see how building a local database is neither generally 
> feasible nor a valid alternative.
> 
> Stefan Santesson
> > construct a local database and a way to detect such a situation 
> > inside the
> potato
> > 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?
> > 
> > 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
> > CRL paths which introduce new CRL paths etc.......  Denial of 
> > service attacks through complex paths isn't faar away.
> >

---

From: "Julien Stern" <[email-masked]>
Date: Tue, 2 Nov 2004 14:14:22 +0100

Santosh,

thanks for your replies,

see one more question regarding OCSP in-line.

On Tue, Nov 02, 2004 at 06:14:16AM -0500, Santosh Chokhani wrote:
> (snip)

This is where I'm confused.

OCSP defines three way to access the validity of a responder
certificate.

If the OCSP certificate is the CA itself I do not see any problem.
I understand OCSP insists on the certificate to be the same as the CA
anyway, so there is no DN related problem.

If the OCSP certificate is a delegated one, it has to be signed by the
CA certificate itself. So again, no ambiguity, but I though a special
case would still be needed as the path will be one "step" too long
otherwise. Or maybe the same rules as indirect CRLs can be applied ?

(And if the OCSP certificate is "directly" trusted, I guess that X509
validation rules no do apply anyway...)

Sincerely,

--
Julien Stern

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 2 Nov 2004 18:33:24 -0500

Julien,

The scope of this thread and the proposed algorithm is limited to when you
have certification path for a certificate and a CRL which is signed using a
different key, how you find and match the certification path for the CRL.

This applies regardless of the end certificate you are validating: be it a
normal user whose signature is being validated on an e-mail, a time stamp
authority or an OCSP Responder.

The only special case for OCSP Responder when it does not apply is when the
Responder certificate has no-check, obviating the need for CRL.  Same goes
when the Responder is a trust anchor.

Note: Also, in all cases, when the revocation status is checked using an
OCSP Responder and not the CRL, this is not applicable.

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

Santosh,

thanks for your replies,

On Tue, Nov 02, 2004 at 06:14:16AM -0500, Santosh Chokhani wrote:
> [mailto:[email-masked]] On Behalf Of Julien Stern
> [Certification path for any check is subject to this be it, end 
> entity, CRL signer, OCSP response signer)

OCSP defines three way to access the validity of a responder certificate.

If the OCSP certificate is the CA itself I do not see any problem. I
understand OCSP insists on the certificate to be the same as the CA anyway,
so there is no DN related problem.

If the OCSP certificate is a delegated one, it has to be signed by the CA
certificate itself. So again, no ambiguity, but I though a special case
would still be needed as the path will be one "step" too long otherwise. Or
maybe the same rules as indirect CRLs can be applied ?

Sincerely,

--
Julien Stern

---

From: "Julien Stern" <[email-masked]>
Date: Wed, 3 Nov 2004 16:08:58 +0100

Denis,

see responses in-line.

On Wed, Nov 03, 2004 at 03:44:40PM +0100, Denis Pinkas wrote:
> Nothing is "ideal".

I cannot agree more ;)

> So this statement is not valid.
> 
> A trust anchor always includes a public key value. It is not possible to 
> have two TAs with the same public key value unless the corresponding 
> private key has been compromised.

I have never talked about two TAs with the same public key.
I can easily configure my local software to add a trust anchor whose
DN is, say, "C=US,O=Verisign" and whose corresponding private key is mine.
I was just trying to say that I'm assuming this is NOT the case, else
there is not much one can do.

> This is not a mistake. A DN is only local to the CA that has nominated the 
> subject.

Well, I understood ISO wanted DN to be unique, but ok, let us say it
may happen even if it is not a mistake.

> I don't know the "algorithm proposed by Santosh", but using all the 
> elements of the certification path, it is easy to make the difference 
> between two different entities from two different CAs that would have the 
> same DN.

I though it was the algorithm that was under discussions during this thread.
I also though that (one of) the main goal of this algorithm was to make
the difference between two different entities with the same DN.
I finally do not think that "it is easy" to make this difference, but if
you indeed have a trivial way to do so, I'd be more than interested.

Sincerely,

--
Julien

---

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

Julien,

> 1) Ideally, a DN should uniquely identify a entity.

Nothing is "ideal". So this statement is not valid.

A trust anchor always includes a public key value. It is not possible to 
have two TAs with the same public key value unless the corresponding private 
key has been compromised.

> algorithm proposed by Santosh.

I don't know the "algorithm proposed by Santosh", but using all the elements 
of the certification path, it is easy to make the difference between two 
different entities from two different CAs that would have the same DN.

Denis