RE: R: On cross-certificates and pathLenConstraint

Thanks Steve for jumping in on this.

We completely agree on the facts of RFC 3280 path processing and I think
you showed this very well with support from the standard text.

We happen to disagree on the good or bad with processing root extensions
but I think we should save that to later 

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org
[mailto:owner-ietf-pkix <at> mail.imc.org]
> On Behalf Of Steve Hanna
> Sent: den 31 augusti 2004 22:05
> To: Santosh Chokhani
> Cc: ietf-pkix <at> imc.org
> Subject: 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:

R: R: On cross-certificates and pathLenConstraint

<<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: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org] Per conto di Steve Hanna
Inviato: martedì 31 agosto 2004 22.05
A: Santosh Chokhani
Cc: ietf-pkix <at> imc.org
Oggetto: Re: R: On cross-certificates and pathLenConstraint

RFC 3280 says in section 6.1:

Question - certificate status in past

RE: R: On cross-certificates and pathLenConstraint

> 
> 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: owner-ietf-pkix <at> mail.imc.org 
> [mailto:owner-ietf-pkix <at> mail.imc.org] Per conto di Steve Hanna
> Inviato: martedì 31 agosto 2004 22.05
> A: Santosh Chokhani
> Cc: ietf-pkix <at> imc.org
> 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: owner-ietf-pkix <at> mail.imc.org
> > [mailto:owner-ietf-pkix <at> mail.imc.org] On Behalf Of Stephen Kent
> > Sent: Tuesday, August 31, 2004 9:51 AM
> > To: Santoni Adriano
> > Cc: ietf-pkix <at> imc.org
> > 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.
> 
> 
> 

RE: R: On cross-certificates and pathLenConstraint

I agree with Liaquat.

I will respond to Steve Hanna later.

-----Original Message-----
From: Liaquat Khan [mailto:liaquat.khan <at> ascertia.com] 
Sent: Wednesday, September 01, 2004 6:48 AM
To: 'Santoni Adriano'; 'Steve Hanna'; 'Santosh Chokhani'
Cc: ietf-pkix <at> imc.org
Subject: RE: R: On cross-certificates and pathLenConstraint

> 
> 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: owner-ietf-pkix <at> mail.imc.org 
> [mailto:owner-ietf-pkix <at> mail.imc.org] Per conto di Steve Hanna
> Inviato: martedì 31 agosto 2004 22.05
> A: Santosh Chokhani
> Cc: ietf-pkix <at> imc.org
> 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: owner-ietf-pkix <at> mail.imc.org
> > [mailto:owner-ietf-pkix <at> mail.imc.org] On Behalf Of Stephen Kent
> > Sent: Tuesday, August 31, 2004 9:51 AM
> > To: Santoni Adriano
> > Cc: ietf-pkix <at> imc.org
> > 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.
> 
> 
> 

RE: On cross-certificates and pathLenConstraint

        Santosh:

        This has come up before, as I indicated in my last posting.  I ask 
for consensus to the effect that setting permitted_subtrees, 
excluded_subtrees, and max_path_length from configuration entries 
specifiable on a per-trust-anchor basis is a permissible "augmentation" of 
the RFC 3280 algorithm of the sort contemplated in the third and fourth 
sentences of RFC 3280 6.2.  In fact, the fourth sentence of that section 
explicitly suggests using name constraints in this way even though RFC 
3280 6.1.2 gives specific initial values for the "subtrees" parameters 
just as it does for max_path_length.  The initialization of 
max_path_length to "n" has no particular effect that would not be obtained 
by setting it to a large positive value instead.
        Obviously, packaging such a configuration entry within a v3 
certificate has no effect relevant to RFC 3280.  If the configuration 
entry is allowed, it may be derived from a certificate or may come from a 
file, at the RP's option.
        Although the argument above is based on the text of RFC 3280, I am 
not making it solely for that reason.  I believe that it is technically 
appropriate to implement such a feature as well.  In particular, an RP may 
have legitimate reasons to trust a departmental CA directly, and set 
max_path_length to 0; to trust a CA's EE certificates without trusting his 
cross certificates, also by setting max_path_length to 0; or to impose a 
naming space restriction on a directly trusted CA by setting 
permitted_subtrees.  I do not claim that I can compose plausible use cases 
for the entire breadth of these parameters.

                Tom Gindin

"Santosh Chokhani" <chokhani <at> orionsec.com>
Sent by: owner-ietf-pkix <at> mail.imc.org
08/31/2004 12:19 PM

        To:     <ietf-pkix <at> imc.org>
        cc: 
        Subject:        RE: On cross-certificates and pathLenConstraint

Stefan:

I think a trust anchor is not necessarily a certificate, let alone a CA
certificate.  Thus, 4.2.1.10 does not apply.  Also, as I have noted to
Sharon, you can not enforce the cA flag or initialize path length from the
root.  Thus, the use of this extension in the root is meaningless.

As to accepting constraints from the root, those that 3280 permits to be
initialized, is fine.  Path length is not one of them.

-----Original Message-----
From: Stefan Santesson [mailto:stefans <at> microsoft.com] 
Sent: Tuesday, August 31, 2004 11:32 AM
To: Santosh Chokhani; ietf-pkix <at> imc.org
Subject: RE: On cross-certificates and pathLenConstraint

Santosh,

You are right that you may provide trust information by means other than a
certificate, but if you form a root certificate according to RFC 3280, 
then
basic constraints MUST be present or the certificate is NOT RFC 3280
compliant.

RFC 3280 4.2.1.10
   This extension MUST appear as a critical extension in all CA
   certificates that contain public keys used to validate digital
   signatures on certificates.

Which is perfectly true also for roots.

Secondly, section 6.1 of RFC 3280 states:
   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.

Accepting constraints configured in the applied root as input variables 
into
the path processing is therefore completely allowed by RFC 3280 path
processing as a way to augment the mandatory algorithm to further 
constrain
trust.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org
> [mailto:owner-ietf-pkix <at> mail.imc.org]
> On Behalf Of Santosh Chokhani
> Sent: den 31 augusti 2004 13:47
> To: ietf-pkix <at> imc.org
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> Stefan:
> 
> The standard does NOT require basic constraints to be in the root.
> 
> Also, when you enforce constraints on the trust anchor certificate,
> that is not in compliance with the standard.
> 
> I agree that a more flexible standard would be one that honors
> extensions in the root and also permits most of the values to be 
> initialized.  I know both
> X.509 and 3280 are moving towards the second one.  The first one can
> become
> a backward compatibility issue.
> 
> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org
> [mailto:owner-ietf-pkix <at> mail.imc.org]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, August 31, 2004 6:26 AM
> To: Santoni Adriano; Peter Hesse; David P. Kemp
> Cc: ietf-pkix <at> imc.org
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> 
> Santoni,
> 
> I just want to add/clarify that I agree that discarding all extensions
> of root certificates in path processing is a bad design.
> 
> The result is as you conclude that Basic Constraints MUST be present
> in roots but any present path length constraints, policy constraints, 
> explicit policies, name constraints etc, MAY be ignored.
> 
> However, as Sharon pointed out, it is not a violation of RFC 3280 to
> honour any constraints set in the root certificate so MS CAPIs 
> decision to enforce
> ROOT extensions in this manner is not in conflict with RFC 3280, but you
> can't rely on that other RFC 3280 compliant implementations will do 
this.
> They may legitimately ignore this data.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: owner-ietf-pkix <at> mail.imc.org
> > [mailto:owner-ietf-pkix <at> mail.imc.org]
> > On Behalf Of Santoni Adriano
> > Sent: den 31 augusti 2004 09:26
> > To: Peter Hesse; David P. Kemp
> > Cc: ietf-pkix <at> imc.org
> > Subject: R: On cross-certificates and pathLenConstraint
> >
> >
> > 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!
> >
> > I thought it perfectly made sense to insert in a root CA certificate
> > a basicConstraints with cA=TRUE and pathLenConstraint=0 (for 
> > example) to signify that that CA only issues certificates to 
> > end-users and not to subordinates. I am talking about the 
> > self-signed certificate used by an autonomous CA to distribute its 
> > own public key in a way that allows easy import into virtually all 
> > applications. [On the other hand, what CAs distribute their own 
> > public keys as a bare public keys? Virtually none.]
> >
> > It suddenly comes to my mind that perhaps the extensions in the root
> > CA certificates contained in the Windows store were inserted for the 
> > sole purposes of accommodating MS CAPI idiosyncrasies (like 
> > mentioned by
> > Santesson) ...
> >
> > However, RFC 3280 says (§ 4.2.1.10  Basic Constraints):
> >              "...This extension MUST appear as a critical extension in 
all
> CA
> > certificates
> >              that contain public keys used to validate digital 
signatures on
> > certificates" ?
> >
> > (and the same hold for other extensions as well)
> >
> > It does not say "all CA certificates that are not trust anchors"; it
> > says "all CA certificates".
> >
> > Is this statement not conflicting with your one?
> >
> > Adriano
> >
> >
> > -----Messaggio originale-----
> > Da: owner-ietf-pkix <at> mail.imc.org
> > [mailto:owner-ietf-pkix <at> mail.imc.org]
> > Per conto di Peter Hesse
> > Inviato: lunedì 30 agosto 2004 18.43
> > A: 'David P. Kemp'; ietf-pkix <at> imc.org
> > Oggetto: RE: On cross-certificates and pathLenConstraint
> >
> >
> >
> > Section 6.1 of RFC 3280 states:
> >
> >    When the trust anchor is provided in the form of a self-signed
> >    certificate, this self-signed certificate is not included as part 
of
> >    the prospective certification path.  Information about trust 
anchors
> >    are provided as inputs to the certification path validation 
algorithm
> >    (section 6.1.1).
> >
> > Thus I agree with Santosh that in no case should the extensions in a
> > trust anchor's self-signed certificate affect the certification path 
> > validation.
> >
> > --Peter
> >
> > +---------------------------------------------------------------+
> > | Peter Hesse                    pmhesse <at> geminisecurity.com     |
> > | Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
> > | ICQ: 1942828                     www.geminisecurity.com       |
> > +---------------------------------------------------------------+
> > "Pay no attention to what the critics say; there has never been a
> > statue set up in honor of a critic." --Jean Sibelius
> >
> >
> > > -----Original Message-----
> > > From: owner-ietf-pkix <at> mail.imc.org
> > > [mailto:owner-ietf-pkix <at> mail.imc.org] On Behalf Of David P. Kemp
> > > Sent: Monday, August 30, 2004 11:51 AM
> > > To: ietf-pkix <at> imc.org
> > > Subject: Re: On cross-certificates and pathLenConstraint
> > >
> > >
> > > Santosh,
> > >
> > > Is there ambiguity in the term trust anchor?  It seems possible to
> > > regard the trust anchor as a bare public key or as a certificate.
> > >
> > > Because a self-signed certificate should appear only once at the
> > > head of a path (and never elsewhere) the rule of "no extensions in 
> > > trust anchors" should apply only if "trust anchor" is defined to 
> > > be a public key that can be used to verify a certificate 
> > > (self-signed or otherwise).  It should not apply if the 
> > > self-signed certificate itself is defined to be the trust anchor.
> > >
> > > Perhaps X.509 and RFC 3280 should be clarified to state that there
> > > is no such thing as a "self signed root".  There are roots (trust
> > > anchors) that are public keys only, and there are self signed 
> > > certificates that may be validated by a root and whose extensions 
> > > are to be honored.
> > >
> > > Dave
> > >
> > >
> > > Santosh Chokhani wrote:
> > >
> > > >Stefan:
> > > >
> > > >I think extensions should be ignored in the trust anchor
> > > regardless of
> > > >their criticality
> > > >
> > > >For reasons such as MS CAPI, it is best to keep the trust anchors
> > > >to bear minimum required.
> > > >
> > > >-----Original Message-----
> > > >From: Stefan Santesson [mailto:stefans <at> microsoft.com]
> > > >Sent: Saturday, August 28, 2004 5:10 AM
> > > >To: Santosh Chokhani; ietf-pkix <at> imc.org
> > > >Subject: RE: On cross-certificates and pathLenConstraint
> > > >
> > > >
> > > >The case when CA A is a self-signed root is different.
> > > >
> > > >If the Path Length constraint is present in the self signed root,
> > > >it will be ignored by a X.509 and RFC 3280 compliant path
> > > validation implementation.
> > > >
> > > >However, there are implementations that honour Root
> > > extensions despite
> > > >this and would thus honour Path length constraints present in
> > > >roots. E.g. I know that MS CAPI will.
> > > >
> > > >Despite that, I would say that it is wrong to rely on critical
> > > >extensions in root certificates since they are ignored in
> > > RFC 3280 path validation.
> > > >
> > > >Stefan Santesson
> > > >Microsoft Security Center of Excellence (SCOE)
> > > >
> > > >
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: owner-ietf-pkix <at> mail.imc.org
> > > >>[mailto:owner-ietf-pkix <at> mail.imc.org]
> > > >>On Behalf Of Santosh Chokhani
> > > >>Sent: den 28 augusti 2004 00:52
> > > >>To: ietf-pkix <at> imc.org
> > > >>Subject: RE: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>Stefan has the right idea.
> > > >>
> > > >>If CA A is simply another CA, CA B certificate can be
> > > validated as an
> > > >>end (not intermediate certificate).
> > > >>
> > > >>If CA A is trust anchor, I think it can issue CA
> > > certificates.  I read
> > > >>both X.509 and 3280 to not enforce constraints in the trust
> > > >>anchor.
> > > >>
> > > >>To complicate matters further, if the trust anchor issues itself
> > > >>a self-issued certificate, I would think the pathLength in that 
> > > >>certificate should be honored.
> > > >>
> > > >>BTW, all this discussion of hierarchies and cross
> > > certificates should
> > > >>not be relevant.  Both X.509 and 3280 are (rightfully) trust
> > > >>model agnostic.
> > > >>
> > > >>-----Original Message-----
> > > >>From: owner-ietf-pkix <at> mail.imc.org
> > > >>[mailto:owner-ietf-pkix <at> mail.imc.org]
> > > >>On
> > > >>Behalf Of Santoni Adriano
> > > >>Sent: Friday, August 27, 2004 9:28 AM
> > > >>To: Sharon Boeyen
> > > >>Cc: ietf-pkix <at> imc.org
> > > >>Subject: R: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>
> > > >>Sharon,
> > > >>
> > > >>you explained what happens when a cross-certificates contains a
> > > >>pathLenConstraint=0, but I was referring to the
> > > pathLenConstraint in
> > > >>the trust-point certificate. Virtually all CA public keys are
> > > >>distributed to end-users in the form of a self-signed 
> > > >>certificate which may (should) contain the BasicConstrains 
> > > >>extension. Some EU profiles actually mandate the BasicConstrains 
> > > >>to be present and critical.
> > > >>
> > > >>Using your example entities, my question can be re-phrased like
> > > >>follows: can CA A (my trust point) issue a cross-cert to CA
> > > B (e.g. a
> > > >>foreign one) if the self-issued certificate of CA A contains
> > > >>pathLenConstraint=0 ?
> > > >>
> > > >>>From another viewpoint: setting pathLenConstraint=0 to prevent
> > > >>
> > > >>
> > > >>>hierarchical SubCAs does also hinder cross-certificates?
> > > >>>
> > > >>>
> > > >>Adriano
> > > >>
> > > >>-----Messaggio originale-----
> > > >>Da: Sharon Boeyen [mailto:sharon.boeyen <at> entrust.com]
> > > >>Inviato: venerdì 27 agosto 2004 14.34
> > > >>A: Santoni Adriano; ietf-pkix <at> imc.org
> > > >>Oggetto: RE: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>If you are talking about a non-hierarchical trust model, then
> > > >>absolutely yes any CA can issue any cross-certificates they 
> > > >>wish. However, those cross-certificates will only be trusted if 
> > > >>paths are built to them that exclude the certificate that 
> > > >>contains the path length constraint.
> > > >>
> > > >>For example, take CA A, CA B, CA C and CA D
> > > >>
> > > >>CA A issues a cross certificate to CA B with a path length
> > > constraint
> > > >>of 0 CA B issues a cross certificate to CA C CA D issues a cross
> > > >>certificate to CA B (no path length constraint)
> > > >>
> > > >>Assume that there are no other cross certs in the environment
> > > >>
> > > >>Users of CA A have no way to trust certificates issued by CA C
> > > >>(because of the path length constraint)
> > > >>
> > > >>However, users of CA D are able to trust certificates
> > > issued by CA C
> > > >>because the cross-certificate from D to B contains no such
> > > constraint.
> > > >>
> > > >>As for your second question, yes there are implementations that
> > > >>process paths including all the business controls. As for
> > > testing, I'd
> > > >>suggest you have a look at the PKITS test suite which tests
> > > all these
> > > >>features. http://csrc.nist.gov/pki/testing/x509paths.html
> > > >>
> > > >>Cheers,
> > > >>Sharon
> > > >>
> > > >>-----Original Message-----
> > > >>From: owner-ietf-pkix <at> mail.imc.org
> > > >>[mailto:owner-ietf-pkix <at> mail.imc.org]
> > > >>On
> > > >>Behalf Of Santoni Adriano
> > > >>Sent: Friday, August 27, 2004 5:37 AM
> > > >>To: ietf-pkix <at> imc.org
> > > >>Subject: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>
> > > >>Dear list,
> > > >>
> > > >>I have the following doubts regarding cross-certificates:
> > > >>
> > > >>can a CA with BasicConstraints.pathLenConstraint=0 issue a
> > > >>cross- certificate to another CA in a different domain?
> > > >>
> > > >>In case of a "cross-certificate" (so to speak) issued by
> > > the same CA
> > > >>for itself, to facilitate the CA key rollover, RFC 3280 seems to
> > > >>to allow the cross-certificate issuance regardless of the 
> > > >>pathLenConstraint value, on the ground that in this case the 
> > > >>cross-certificate is "self-issued" and therefore, in a way, "out 
> > > >>of scope" as far as the pathLenConstraint is concerned.
> > > >>
> > > >>However, in the case of a "real" cross-certificate, to be issued
> > > >>to another CA with a different name, it is not very clear to me 
> > > >>if the pathLenConstraint in CA1 affects the possibility of 
> > > >>issuing a cross-certificate to CA2.
> > > >>
> > > >>By the way, I wonder how are the most widespread
> > > applications handling
> > > >>certificate chains containing cross-certs, in the various
> > > cases (e.g.
> > > >>different values of pethLenConstraint down the chain); has
> > > >>anybody done any testing to specifically investigate this area?
> > > >>
> > > >>Is anybody willing to shed some light and/or share informations?
> > > >>
> > > >>TIA,
> > > >>  Adriano
> > > >>
> > > >>
> > > >>*******************Internet Email Confidentiality
> > > >>Footer*******************
> > > >>
> > > >>
> > > >>Qualsiasi utilizzo non autorizzato del presente messaggio
> > > nonche dei
> > > >>suoi allegati e 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.
> > > >>
> > > >>
> > > >>*******************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.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> > *******************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.
> >
> >
> 
> 

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

RE: R: On cross-certificates and pathLenConstraint

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

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

RE: R: On cross-certificates and pathLenConstraint

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: owner-ietf-pkix <at> mail.imc.org
[mailto:owner-ietf-pkix <at> mail.imc.org]
> On Behalf Of Stephen Kent
> Sent: den 1 september 2004 15:24
> To: liaquat.khan <at> ascertia.com
> Cc: ietf-pkix <at> imc.org
> 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

RE: On cross-certificates and pathLenConstraint

Specifically on name constraints, I believe the reason this text please note
that the current X.509 work is adding the ability to configure those exact
variables in its path validation module. This is part of the ongoing
enhancement work that is now underway. I think (but my memory is not very
good) that the 3280 text was added around the same time we initiated the 509
work. 

While I do agree that enabling more of those path validation variables to be
configurable is a good thing, how a particular implementation actually
chooses to populate those variables needs to be left flexible. In some cases
populating them from corresponding values in a self signed cert makes sense,
but not in other cases. 

Cheers,
Sharon

-----Original Message-----
From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org] On
Behalf Of Tom Gindin
Sent: Wednesday, September 01, 2004 7:20 AM
To: Santosh Chokhani
Cc: ietf-pkix <at> imc.org
Subject: RE: On cross-certificates and pathLenConstraint

        Santosh:

        This has come up before, as I indicated in my last posting.  I ask 
for consensus to the effect that setting permitted_subtrees, 
excluded_subtrees, and max_path_length from configuration entries 
specifiable on a per-trust-anchor basis is a permissible "augmentation" of 
the RFC 3280 algorithm of the sort contemplated in the third and fourth 
sentences of RFC 3280 6.2.  In fact, the fourth sentence of that section 
explicitly suggests using name constraints in this way even though RFC 
3280 6.1.2 gives specific initial values for the "subtrees" parameters 
just as it does for max_path_length.  The initialization of 
max_path_length to "n" has no particular effect that would not be obtained 
by setting it to a large positive value instead.
        Obviously, packaging such a configuration entry within a v3 
certificate has no effect relevant to RFC 3280.  If the configuration 
entry is allowed, it may be derived from a certificate or may come from a 
file, at the RP's option.
        Although the argument above is based on the text of RFC 3280, I am 
not making it solely for that reason.  I believe that it is technically 
appropriate to implement such a feature as well.  In particular, an RP may 
have legitimate reasons to trust a departmental CA directly, and set 
max_path_length to 0; to trust a CA's EE certificates without trusting his 
cross certificates, also by setting max_path_length to 0; or to impose a 
naming space restriction on a directly trusted CA by setting 
permitted_subtrees.  I do not claim that I can compose plausible use cases 
for the entire breadth of these parameters.

                Tom Gindin

"Santosh Chokhani" <chokhani <at> orionsec.com>
Sent by: owner-ietf-pkix <at> mail.imc.org
08/31/2004 12:19 PM

        To:     <ietf-pkix <at> imc.org>
        cc: 
        Subject:        RE: On cross-certificates and pathLenConstraint

Stefan:

I think a trust anchor is not necessarily a certificate, let alone a CA
certificate.  Thus, 4.2.1.10 does not apply.  Also, as I have noted to
Sharon, you can not enforce the cA flag or initialize path length from the
root.  Thus, the use of this extension in the root is meaningless.

As to accepting constraints from the root, those that 3280 permits to be
initialized, is fine.  Path length is not one of them.

-----Original Message-----
From: Stefan Santesson [mailto:stefans <at> microsoft.com] 
Sent: Tuesday, August 31, 2004 11:32 AM
To: Santosh Chokhani; ietf-pkix <at> imc.org
Subject: RE: On cross-certificates and pathLenConstraint

Santosh,

You are right that you may provide trust information by means other than a
certificate, but if you form a root certificate according to RFC 3280, 
then
basic constraints MUST be present or the certificate is NOT RFC 3280
compliant.

RFC 3280 4.2.1.10
   This extension MUST appear as a critical extension in all CA
   certificates that contain public keys used to validate digital
   signatures on certificates.

Which is perfectly true also for roots.

Secondly, section 6.1 of RFC 3280 states:
   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.

Accepting constraints configured in the applied root as input variables 
into
the path processing is therefore completely allowed by RFC 3280 path
processing as a way to augment the mandatory algorithm to further 
constrain
trust.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org 
> [mailto:owner-ietf-pkix <at> mail.imc.org]
> On Behalf Of Santosh Chokhani
> Sent: den 31 augusti 2004 13:47
> To: ietf-pkix <at> imc.org
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> Stefan:
> 
> The standard does NOT require basic constraints to be in the root.
> 
> Also, when you enforce constraints on the trust anchor certificate, 
> that is not in compliance with the standard.
> 
> I agree that a more flexible standard would be one that honors 
> extensions in the root and also permits most of the values to be 
> initialized.  I know both X.509 and 3280 are moving towards the second 
> one.  The first one can become
> a backward compatibility issue.
> 
> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org 
> [mailto:owner-ietf-pkix <at> mail.imc.org]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, August 31, 2004 6:26 AM
> To: Santoni Adriano; Peter Hesse; David P. Kemp
> Cc: ietf-pkix <at> imc.org
> Subject: RE: On cross-certificates and pathLenConstraint
> 
> 
> 
> Santoni,
> 
> I just want to add/clarify that I agree that discarding all extensions 
> of root certificates in path processing is a bad design.
> 
> The result is as you conclude that Basic Constraints MUST be present 
> in roots but any present path length constraints, policy constraints, 
> explicit policies, name constraints etc, MAY be ignored.
> 
> However, as Sharon pointed out, it is not a violation of RFC 3280 to 
> honour any constraints set in the root certificate so MS CAPIs 
> decision to enforce ROOT extensions in this manner is not in conflict 
> with RFC 3280, but you can't rely on that other RFC 3280 compliant 
> implementations will do
this.
> They may legitimately ignore this data.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: owner-ietf-pkix <at> mail.imc.org 
> > [mailto:owner-ietf-pkix <at> mail.imc.org]
> > On Behalf Of Santoni Adriano
> > Sent: den 31 augusti 2004 09:26
> > To: Peter Hesse; David P. Kemp
> > Cc: ietf-pkix <at> imc.org
> > Subject: R: On cross-certificates and pathLenConstraint
> >
> >
> > 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!
> >
> > I thought it perfectly made sense to insert in a root CA certificate 
> > a basicConstraints with cA=TRUE and pathLenConstraint=0 (for
> > example) to signify that that CA only issues certificates to
> > end-users and not to subordinates. I am talking about the 
> > self-signed certificate used by an autonomous CA to distribute its 
> > own public key in a way that allows easy import into virtually all 
> > applications. [On the other hand, what CAs distribute their own 
> > public keys as a bare public keys? Virtually none.]
> >
> > It suddenly comes to my mind that perhaps the extensions in the root 
> > CA certificates contained in the Windows store were inserted for the 
> > sole purposes of accommodating MS CAPI idiosyncrasies (like 
> > mentioned by
> > Santesson) ...
> >
> > However, RFC 3280 says (§ 4.2.1.10  Basic Constraints):
> >              "...This extension MUST appear as a critical extension 
> > in
all
> CA
> > certificates
> >              that contain public keys used to validate digital
signatures on
> > certificates" ?
> >
> > (and the same hold for other extensions as well)
> >
> > It does not say "all CA certificates that are not trust anchors"; it 
> > says "all CA certificates".
> >
> > Is this statement not conflicting with your one?
> >
> > Adriano
> >
> >
> > -----Messaggio originale-----
> > Da: owner-ietf-pkix <at> mail.imc.org 
> > [mailto:owner-ietf-pkix <at> mail.imc.org]
> > Per conto di Peter Hesse
> > Inviato: lunedì 30 agosto 2004 18.43
> > A: 'David P. Kemp'; ietf-pkix <at> imc.org
> > Oggetto: RE: On cross-certificates and pathLenConstraint
> >
> >
> >
> > Section 6.1 of RFC 3280 states:
> >
> >    When the trust anchor is provided in the form of a self-signed
> >    certificate, this self-signed certificate is not included as part
of
> >    the prospective certification path.  Information about trust
anchors
> >    are provided as inputs to the certification path validation
algorithm
> >    (section 6.1.1).
> >
> > Thus I agree with Santosh that in no case should the extensions in a 
> > trust anchor's self-signed certificate affect the certification path 
> > validation.
> >
> > --Peter
> >
> > +---------------------------------------------------------------+
> > | Peter Hesse                    pmhesse <at> geminisecurity.com     |
> > | Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
> > | ICQ: 1942828                     www.geminisecurity.com       |
> > +---------------------------------------------------------------+
> > "Pay no attention to what the critics say; there has never been a 
> > statue set up in honor of a critic." --Jean Sibelius
> >
> >
> > > -----Original Message-----
> > > From: owner-ietf-pkix <at> mail.imc.org 
> > > [mailto:owner-ietf-pkix <at> mail.imc.org] On Behalf Of David P. Kemp
> > > Sent: Monday, August 30, 2004 11:51 AM
> > > To: ietf-pkix <at> imc.org
> > > Subject: Re: On cross-certificates and pathLenConstraint
> > >
> > >
> > > Santosh,
> > >
> > > Is there ambiguity in the term trust anchor?  It seems possible to 
> > > regard the trust anchor as a bare public key or as a certificate.
> > >
> > > Because a self-signed certificate should appear only once at the 
> > > head of a path (and never elsewhere) the rule of "no extensions in 
> > > trust anchors" should apply only if "trust anchor" is defined to 
> > > be a public key that can be used to verify a certificate 
> > > (self-signed or otherwise).  It should not apply if the 
> > > self-signed certificate itself is defined to be the trust anchor.
> > >
> > > Perhaps X.509 and RFC 3280 should be clarified to state that there 
> > > is no such thing as a "self signed root".  There are roots (trust
> > > anchors) that are public keys only, and there are self signed
> > > certificates that may be validated by a root and whose extensions 
> > > are to be honored.
> > >
> > > Dave
> > >
> > >
> > > Santosh Chokhani wrote:
> > >
> > > >Stefan:
> > > >
> > > >I think extensions should be ignored in the trust anchor
> > > regardless of
> > > >their criticality
> > > >
> > > >For reasons such as MS CAPI, it is best to keep the trust anchors 
> > > >to bear minimum required.
> > > >
> > > >-----Original Message-----
> > > >From: Stefan Santesson [mailto:stefans <at> microsoft.com]
> > > >Sent: Saturday, August 28, 2004 5:10 AM
> > > >To: Santosh Chokhani; ietf-pkix <at> imc.org
> > > >Subject: RE: On cross-certificates and pathLenConstraint
> > > >
> > > >
> > > >The case when CA A is a self-signed root is different.
> > > >
> > > >If the Path Length constraint is present in the self signed root, 
> > > >it will be ignored by a X.509 and RFC 3280 compliant path
> > > validation implementation.
> > > >
> > > >However, there are implementations that honour Root
> > > extensions despite
> > > >this and would thus honour Path length constraints present in 
> > > >roots. E.g. I know that MS CAPI will.
> > > >
> > > >Despite that, I would say that it is wrong to rely on critical 
> > > >extensions in root certificates since they are ignored in
> > > RFC 3280 path validation.
> > > >
> > > >Stefan Santesson
> > > >Microsoft Security Center of Excellence (SCOE)
> > > >
> > > >
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: owner-ietf-pkix <at> mail.imc.org 
> > > >>[mailto:owner-ietf-pkix <at> mail.imc.org]
> > > >>On Behalf Of Santosh Chokhani
> > > >>Sent: den 28 augusti 2004 00:52
> > > >>To: ietf-pkix <at> imc.org
> > > >>Subject: RE: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>Stefan has the right idea.
> > > >>
> > > >>If CA A is simply another CA, CA B certificate can be
> > > validated as an
> > > >>end (not intermediate certificate).
> > > >>
> > > >>If CA A is trust anchor, I think it can issue CA
> > > certificates.  I read
> > > >>both X.509 and 3280 to not enforce constraints in the trust 
> > > >>anchor.
> > > >>
> > > >>To complicate matters further, if the trust anchor issues itself 
> > > >>a self-issued certificate, I would think the pathLength in that 
> > > >>certificate should be honored.
> > > >>
> > > >>BTW, all this discussion of hierarchies and cross
> > > certificates should
> > > >>not be relevant.  Both X.509 and 3280 are (rightfully) trust 
> > > >>model agnostic.
> > > >>
> > > >>-----Original Message-----
> > > >>From: owner-ietf-pkix <at> mail.imc.org 
> > > >>[mailto:owner-ietf-pkix <at> mail.imc.org]
> > > >>On
> > > >>Behalf Of Santoni Adriano
> > > >>Sent: Friday, August 27, 2004 9:28 AM
> > > >>To: Sharon Boeyen
> > > >>Cc: ietf-pkix <at> imc.org
> > > >>Subject: R: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>
> > > >>Sharon,
> > > >>
> > > >>you explained what happens when a cross-certificates contains a 
> > > >>pathLenConstraint=0, but I was referring to the
> > > pathLenConstraint in
> > > >>the trust-point certificate. Virtually all CA public keys are 
> > > >>distributed to end-users in the form of a self-signed 
> > > >>certificate which may (should) contain the BasicConstrains 
> > > >>extension. Some EU profiles actually mandate the BasicConstrains 
> > > >>to be present and critical.
> > > >>
> > > >>Using your example entities, my question can be re-phrased like
> > > >>follows: can CA A (my trust point) issue a cross-cert to CA
> > > B (e.g. a
> > > >>foreign one) if the self-issued certificate of CA A contains 
> > > >>pathLenConstraint=0 ?
> > > >>
> > > >>>From another viewpoint: setting pathLenConstraint=0 to prevent
> > > >>
> > > >>
> > > >>>hierarchical SubCAs does also hinder cross-certificates?
> > > >>>
> > > >>>
> > > >>Adriano
> > > >>
> > > >>-----Messaggio originale-----
> > > >>Da: Sharon Boeyen [mailto:sharon.boeyen <at> entrust.com]
> > > >>Inviato: venerdì 27 agosto 2004 14.34
> > > >>A: Santoni Adriano; ietf-pkix <at> imc.org
> > > >>Oggetto: RE: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>If you are talking about a non-hierarchical trust model, then 
> > > >>absolutely yes any CA can issue any cross-certificates they 
> > > >>wish. However, those cross-certificates will only be trusted if 
> > > >>paths are built to them that exclude the certificate that 
> > > >>contains the path length constraint.
> > > >>
> > > >>For example, take CA A, CA B, CA C and CA D
> > > >>
> > > >>CA A issues a cross certificate to CA B with a path length
> > > constraint
> > > >>of 0 CA B issues a cross certificate to CA C CA D issues a cross 
> > > >>certificate to CA B (no path length constraint)
> > > >>
> > > >>Assume that there are no other cross certs in the environment
> > > >>
> > > >>Users of CA A have no way to trust certificates issued by CA C 
> > > >>(because of the path length constraint)
> > > >>
> > > >>However, users of CA D are able to trust certificates
> > > issued by CA C
> > > >>because the cross-certificate from D to B contains no such
> > > constraint.
> > > >>
> > > >>As for your second question, yes there are implementations that 
> > > >>process paths including all the business controls. As for
> > > testing, I'd
> > > >>suggest you have a look at the PKITS test suite which tests
> > > all these
> > > >>features. http://csrc.nist.gov/pki/testing/x509paths.html
> > > >>
> > > >>Cheers,
> > > >>Sharon
> > > >>
> > > >>-----Original Message-----
> > > >>From: owner-ietf-pkix <at> mail.imc.org 
> > > >>[mailto:owner-ietf-pkix <at> mail.imc.org]
> > > >>On
> > > >>Behalf Of Santoni Adriano
> > > >>Sent: Friday, August 27, 2004 5:37 AM
> > > >>To: ietf-pkix <at> imc.org
> > > >>Subject: On cross-certificates and pathLenConstraint
> > > >>
> > > >>
> > > >>
> > > >>Dear list,
> > > >>
> > > >>I have the following doubts regarding cross-certificates:
> > > >>
> > > >>can a CA with BasicConstraints.pathLenConstraint=0 issue a
> > > >>cross- certificate to another CA in a different domain?
> > > >>
> > > >>In case of a "cross-certificate" (so to speak) issued by
> > > the same CA
> > > >>for itself, to facilitate the CA key rollover, RFC 3280 seems to 
> > > >>to allow the cross-certificate issuance regardless of the 
> > > >>pathLenConstraint value, on the ground that in this case the 
> > > >>cross-certificate is "self-issued" and therefore, in a way, "out 
> > > >>of scope" as far as the pathLenConstraint is concerned.
> > > >>
> > > >>However, in the case of a "real" cross-certificate, to be issued 
> > > >>to another CA with a different name, it is not very clear to me 
> > > >>if the pathLenConstraint in CA1 affects the possibility of 
> > > >>issuing a cross-certificate to CA2.
> > > >>
> > > >>By the way, I wonder how are the most widespread
> > > applications handling
> > > >>certificate chains containing cross-certs, in the various
> > > cases (e.g.
> > > >>different values of pethLenConstraint down the chain); has 
> > > >>anybody done any testing to specifically investigate this area?
> > > >>
> > > >>Is anybody willing to shed some light and/or share informations?
> > > >>
> > > >>TIA,
> > > >>  Adriano
> > > >>
> > > >>
> > > >>*******************Internet Email Confidentiality
> > > >>Footer*******************
> > > >>
> > > >>
> > > >>Qualsiasi utilizzo non autorizzato del presente messaggio
> > > nonche dei
> > > >>suoi allegati e 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.
> > > >>
> > > >>
> > > >>*******************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.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> > *******************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.
> >
> >
> 
>