Subject: RE: R: On cross-certificates and pathLenConstraint

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 1 Sep 2004 15:44:47 +0100

Steve,

I agree to the legitimate need you express. 

To further expand on that you may also want to limit a TA to a certain
usage, e.g. only to be used to validate code signing signatures.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Stephen Kent
> Sent: den 1 september 2004 15:24
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: R: On cross-certificates and pathLenConstraint
> 
> 
> At 11:48 AM +0100 9/1/04, Liaquat Khan wrote:
> >  >
> >>  Does not this lead to a paradox? Being a TA is a subjective
> >>  attribute of a CA certificate, i.e. the same CA certificate
> >>  can be or not be a TA depending on the entity that is using
> >>  that certificate in a path validation process. Now, suppose a
> >>  root CA1 issues a certificate for a subordinate CA2, putting
> >>  pathLenConstraint=0 in the CA2 certificate. Then, enforcing
> >>  that constraint would depend on CA2 being considered a TA or
> >>  not. This can make sense from the point of view of the end
> >>  user, but certainly not from the point of view of the root
> >>  CA1, that most probably put that constraint in the CA2 for
> >>  policy reasons. Even if the user regards CA2 as a TA, rather
> >>  than CA1, from the point of view of CA1 that does not mean
> >>  that he (the user) can ignore the (critical) extensions in
> >>  the CA2 certificate!
> >
> >
> >I am not sure this is a problem, as I am of the view that if the user
> >has made CA2 its Trust Anchor, then he trusts this implicitly.
> 
> This is not a good model in general, although it is the model imposed
> by browsers. If one had the ability to associate more path validation
> constraints with TAs, then there would not be a need to implicitly
> trust them. For example, if I installed a TA for CompuDigi Corp, I
> might want to impose a name constraint with that TA, to ensure that
> the TA was used to validate certs only for CompuDigi Corp employees,
> servers, etc.  Unfortunately, the current specs do not allow us to do
> this, and that is a problem that needs to be fixed.
> 
> 
> >Steve

---

From: Stephen Henson <[email-masked]>
Date: Wed, 01 Sep 2004 16:55:25 +0100

> usage, e.g. only to be used to validate code signing signatures.

I'd also agree. In the past policies was also mentioned as something
which should be included.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.