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

From: "Liaquat Khan" <[email-masked]>
Date: Wed, 1 Sep 2004 11:48:13 +0100

> 
> 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.   The
user might not even know who is CA1, and therefore not care what
constraints were put on CA2 by this unrecogised CA1.

From CA1's perspective if it wants to ensure that its constraints are
enforced, it has to ensure it acts as the TA for its end-users and not
CA2.  It can do this through policy, technical and legal means.  This is
why for example in PKIs like Identrus, the certifcate must be checked up
to the Identrus Root CA.  

Regards
LK

>                
> Adriano
> 
> 
> -----Messaggio originale-----
> Da: [email-masked] 
> [mailto:[email-masked]] Per conto di Steve Hanna
> Inviato: martedì 31 agosto 2004 22.05
> A: Santosh Chokhani
> Cc: [email-masked]
> Oggetto: Re: R: On cross-certificates and pathLenConstraint
> 
> 
> 
> RFC 3280 says in section 6.1:
> 
>     A particular certification path may not, however, be 
> appropriate for
>     all applications.  Therefore, an application MAY augment this
>     algorithm to further limit the set of valid paths.
> 
> and in section 6.2:
> 
>     An implementation that supports multiple trust anchors
>     MAY augment the algorithm presented in section 6.1 to 
> further limit
>     the set of valid certification paths which begin with a particular
>     trust anchor.  For example, an implementation MAY modify the
>     algorithm to apply name constraints to a specific trust 
> anchor during
>     the initialization phase, or the application MAY require 
> the presence
>     of a particular alternative name form in the end entity 
> certificate,
>     or the application MAY impose requirements on application-specific
>     extensions.  Thus, the path validation algorithm 
> presented in section
>     6.1 defines the minimum conditions for a path to be 
> considered valid.
> 
> Therefore, I believe that path validation implementations
> can go beyond the usual path validation algorithm to impose
> any additional requirements on paths that it likes (unless 
> specifically prohibited by RFC 3280). This would include 
> processing name constraints in trust anchors, 
> pathLenConstraints in trust anchors, etc.
> 
> However, CAs who expect to act as trust anchors and issue 
> self-signed certificates for that purpose should not assume 
> that all path validation implementations will do this. If 
> they REALLY want to ensure that path lengths are limited, 
> they should certify a subsidiary CA and include a pathLen 
> constraint in that certificate.
> 
> Now, there's a separate question about whether processing 
> constraints in trust anchors is a good idea. I would argue 
> that it's not. But that's a topic for another email.
> 
> Thanks,
> 
> Steve
> 
> Santosh Chokhani wrote:
> 
> > Steve Kent:
> > 
> > We could take extensions in the TA and use them to initialize a
> > certification path values permitted by 3280, but for values such as 
> > path length that 3280 does not permit initialization of to an 
> > arbitrary value, it will require a change in the standard.
> > 
> > From security viewpoint, I do not object to it, but it is a 
> change to
> > the standard.
> > 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Stephen Kent
> > Sent: Tuesday, August 31, 2004 9:51 AM
> > To: Santoni Adriano
> > Cc: [email-masked]
> > Subject: Re: R: On cross-certificates and pathLenConstraint
> > 
> > 
> > 
> > At 9:25 AM +0200 8/31/04, Santoni Adriano wrote:
> > 
> >>If I am getting you right, you are saying that the exensions in the
> >>self-signed certificate of a trust anchor (root CA) should 
> be ignored. 
> >>This is quite suprising to me!
> > 
> > 
> > Unfortunately that is what X.509 has said for some time, 
> and 3280 has 
> > not deviated in this regard. I too was surprised by this initially.
> > 
> > I discussed this issue with Sharon some time ago, noting that, for 
> > example, one would like to impose name constraints through 
> > configuration of trust anchors and the TA exception to the general 
> > processing rules prohibits that.  So I agree completely 
> that I would 
> > like to see at least SOME of the constraints in a trust 
> anchor cert be 
> > applied to cert path processing, although one needs to carefully 
> > examine the implications of doing this.
> > 
> > BTW, Santosh is correct in noting that TAs are not literally certs, 
> > even though self-signed certs are often used as a means of 
> > representing TAs. However, since we admit that a TA can contain 
> > parameters other than the TA name and key info, I think it is 
> > reasonable to allow for the full range of extensions that 
> might appear 
> > in a CA cert, and to then use them (most of them?) to control path 
> > processing.
> > 
> > Steve
> > 
> 
> *******************Internet Email Confidentiality 
> Footer*******************
> 
> 
> Qualsiasi utilizzo non autorizzato del presente messaggio 
> nonché dei suoi allegati è vietato e potrebbe costituire 
> reato. Se ha ricevuto per errore il presente messaggio, Le 
> saremmo grati se ci inviasse, via e-mail, una comunicazione 
> al riguardo e provvedesse nel contempo alla distruzione del 
> messaggio stesso e dei suoi eventuali allegati. Le 
> dichiarazioni contenute nel presente messaggio nonche' nei 
> suoi eventuali allegati devono essere attribuite 
> esclusivamente al mittente e non possono essere considerate 
> come trasmesse o autorizzate da ACTALIS S.p.A.; le medesime 
> dichiarazioni non impegnano ACTALIS S.p.A. nei confronti del 
> destinatario o di terzi. 
> ACTALIS S.p.A. non si assume alcuna responsabilita' per 
> eventuali intercettazioni, modifiche o danneggiamenti del 
> presente messaggio e-mail. 
> 
> 
> 
> Any unauthorized use of this e-mail or any of its attachments 
> is prohibited and could constitute an offence. If you are not 
> the intended addressee please advise immediately the sender 
> by using the reply facility in your e-mail software and 
> destroy the message and its attachments. The statements and 
> opinions expressed in this e-mail message are those of the 
> author of the message and do not necessarily represent those 
> of ACTALIS S.p.A. Besides, The contents of this message shall 
> be understood as neither given nor endorsed by ACTALIS S.p.A.. 
> ACTALIS S.p.A. does not accept liability for corruption, 
> interception or amendment, if any, or the consequences thereof.
> 
> 
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 1 Sep 2004 09:24:24 -0400

At 11:48 AM +0100 9/1/04, Liaquat Khan wrote:
>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.

---

From: "Liaquat Khan" <[email-masked]>
Date: Wed, 1 Sep 2004 15:09:00 +0100

I am not sure who actually imposed the model!  Although I agree being
able to associate such name constraints with TAs could be a useful
feature.  

However, in my opinion this is a decision which is likely to be made by
the RP application, not the CA as such.  For example, some RPs may wish
to accept the CompuDigi TA without any name constraints (i.e. any
certificate issued under this TA is acceptable to these RPs), whilst
other RPs may only use the TA to validate only CompuDigi corporate
certs.  

It may therefore be better to associate such name constraints with a TA
independently of the actual TA certificate (i.e. assuming the TA is in
form of a certificate).  This should also mean the current specs are
sufficient.  

Regards,
LK

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 1 Sep 2004 07:09:31 -0400

I agree with Liaquat.

I will respond to Steve Hanna later.

-----Original Message-----
From: Liaquat Khan [mailto:[email-masked]] 
Sent: Wednesday, September 01, 2004 6:48 AM
To: 'Santoni Adriano'; 'Steve Hanna'; 'Santosh Chokhani'
Cc: [email-masked]
Subject: RE: R: On cross-certificates and pathLenConstraint

Regards
LK

---

From: "Santoni Adriano" <[email-masked]>
Date: Wed, 1 Sep 2004 09:22:35 +0200

<<However, CAs who expect to act as trust anchors and issue self-signed certificates for that purpose should not assume that all path validation implementations will do this. If they REALLY want to ensure that path lengths are limited, they should certify a subsidiary CA and include a pathLen constraint in that certificate.>>

From the various contributes to this thread, it turns out that processing extensions in a TA certificate is allowed and may be useful but - in general - is not recommendable (sic) because it is not mandated by RFC 3280 and therefore the average application may not honour extensions in TAs. 

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!
               
Adriano

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Steve Hanna
Inviato: martedì 31 agosto 2004 22.05
A: Santosh Chokhani
Cc: [email-masked]
Oggetto: Re: R: On cross-certificates and pathLenConstraint

    A particular certification path may not, however, be appropriate for
    all applications.  Therefore, an application MAY augment this
    algorithm to further limit the set of valid paths.

and in section 6.2:

    An implementation that supports multiple trust anchors
    MAY augment the algorithm presented in section 6.1 to further limit
    the set of valid certification paths which begin with a particular
    trust anchor.  For example, an implementation MAY modify the
    algorithm to apply name constraints to a specific trust anchor during
    the initialization phase, or the application MAY require the presence
    of a particular alternative name form in the end entity certificate,
    or the application MAY impose requirements on application-specific
    extensions.  Thus, the path validation algorithm presented in section
    6.1 defines the minimum conditions for a path to be considered valid.

Therefore, I believe that path validation implementations
can go beyond the usual path validation algorithm to impose
any additional requirements on paths that it likes (unless specifically prohibited by RFC 3280). This would include processing name constraints in trust anchors, pathLenConstraints in trust anchors, etc.

However, CAs who expect to act as trust anchors and issue self-signed certificates for that purpose should not assume that all path validation implementations will do this. If they REALLY want to ensure that path lengths are limited, they should certify a subsidiary CA and include a pathLen constraint in that certificate.

Now, there's a separate question about whether processing constraints in trust anchors is a good idea. I would argue that it's not. But that's a topic for another email.

Thanks,

Steve

Santosh Chokhani wrote:

> From security viewpoint, I do not object to it, but it is a change to 
> the standard.
> 
>>self-signed certificate of a trust anchor (root CA) should be ignored. 
> Unfortunately that is what X.509 has said for some time, and 3280 has
> processing rules prohibits that.  So I agree completely that I would 
> like to see at least SOME of the constraints in a trust anchor cert 
> be applied to cert path processing, although one needs to carefully 
> reasonable to allow for the full range of extensions that might 
> appear in a CA cert, and to then use them (most of them?) to control 
> path processing.
> 
> Steve
> 

*******************Internet Email Confidentiality Footer*******************

Qualsiasi utilizzo non autorizzato del presente messaggio nonché dei suoi allegati è vietato e potrebbe costituire reato. Se ha ricevuto per errore il presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una comunicazione al riguardo e provvedesse nel contempo alla distruzione del messaggio stesso e dei suoi eventuali allegati.
Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite esclusivamente al mittente e non possono essere considerate come trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi. 
ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited and could constitute an offence. If you are not the intended addressee please advise immediately the sender by using the reply facility in your e-mail software and destroy the message and its attachments. The statements and opinions expressed in this e-mail message are those of the author of the message and do not necessarily represent those of ACTALIS S.p.A. Besides, The contents of this message shall be understood as neither given nor endorsed by ACTALIS S.p.A.. 
ACTALIS S.p.A. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 1 Sep 2004 10:25:56 -0400

At 3:09 PM +0100 9/1/04, Liaquat Khan wrote:
>I am not sure who actually imposed the model!

Netscape developed it, as part of SSl, then Microsoft copied it to 
maintain compatibility with Netscape.

>   Although I agree being
>the RP application, not the CA as such.

absolutely right. the RP should manage the TAs, but in the browser 
case users are given only very crude management tools to do so.

>   For example, some RPs may wish

right.

>form of a certificate).  This should also mean the current specs are

We should remember that there is no such thing as a TA certificate! A 
TA is a named entity, public key info, and associated parameters used 
for path validation, usually introduced into an RP in an out of band 
fashion. It is a convention that self-signed certs are used to 
represent TAs in many implementations, but this is not a requirement 
imposed by standards and, as you note, it leads to confusion because 
it suggests that the CA is creating the TA parameters which should be 
under control of the RP.

Steve

---

From: "Liaquat Khan" <[email-masked]>
Date: Wed, 1 Sep 2004 17:33:52 +0100

OK I think we are in agreement on this point.  I just got a bit confused
by your previous statement: 

"Unfortunately, the current specs do not allow us to do this, and that
is a problem that needs to be fixed."

I am not sure what you are referring to here exactly, which specs do you
think are not adequate and need to be fixed?

Regards,
LK  

> From: Stephen Kent [mailto:[email-masked]] 
> Sent: 01 September 2004 15:26
> To: [email-masked]
> Cc: [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Wed, 1 Sep 2004 16:50:26 -0400

>think are not adequate and need to be fixed?

X.509 and RFC 3280 make no provision for associating name constraints 
with a TA, for use in controlling path validation. In fact, the 
wording makes clear that if one uses a self-signed cert as the 
representation for a TA, extensions such as name constraints will be 
ignored in path validation.

That's what I was referring to in my prior message.

Steve