Subject: RE: On cross-certificates and pathLenConstraint

From: "Stefan Santesson" <[email-masked]>
Date: Sat, 28 Aug 2004 10:10:04 +0100

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: [email-masked] [mailto:[email-masked]]
> On Behalf Of Santosh Chokhani
> Sent: den 28 augusti 2004 00:52
> To: [email-masked]
> 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: [email-masked] [mailto:[email-masked]]
> On
> Behalf Of Santoni Adriano
> Sent: Friday, August 27, 2004 9:28 AM
> To: Sharon Boeyen
> Cc: [email-masked]
> 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:[email-masked]]
> Inviato: venerdì 27 agosto 2004 14.34
> A: Santoni Adriano; [email-masked]
> 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: [email-masked] [mailto:[email-masked]]
> On
> Behalf Of Santoni Adriano
> Sent: Friday, August 27, 2004 5:37 AM
> To: [email-masked]
> 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.
> 
> 
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 28 Aug 2004 08:27:25 -0400

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:[email-masked]] 
Sent: Saturday, August 28, 2004 5:10 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

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

> If CA A is simply another CA, CA B certificate can be validated as an 
> end (not intermediate certificate).
> 
> both X.509 and 3280 to not enforce constraints in the trust anchor.
> 
> 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.
> 
> 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
> 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.
> 
> 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)
> 
> Users of CA A have no way to trust certificates issued by CA C 
> (because of the path length constraint)
> 
> 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
> 
> 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.
> 
> another CA with a different name, it is not very clear to me if the
> different values of pethLenConstraint down the chain); has anybody 
> done any testing to specifically investigate this area?
> 
> 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
> 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
> 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
> 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

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 30 Aug 2004 11:50:36 -0400

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

---

From: "Peter Hesse" <[email-masked]>
Date: Mon, 30 Aug 2004 12:42:39 -0400

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                    [email-masked]     |
| 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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David P. Kemp
> Sent: Monday, August 30, 2004 11:51 AM
> To: [email-masked]
> 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.
> 
> 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.
> >
> >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
> >>foreign one) if the self-issued certificate of CA A contains 
> >>pathLenConstraint=0 ?
> >>
> >>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.
> >>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.
> >>
> >>
> >>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.
> >>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: "Santosh Chokhani" <[email-masked]>
Date: Mon, 30 Aug 2004 16:17:34 -0400

David Kemp:

I assume you are in agreement with me based on clarification by Peter Hesse?
If not, I will be glad to respond.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David P. Kemp
Sent: Monday, August 30, 2004 11:51 AM
To: [email-masked]
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
>
>will be ignored by a X.509 and RFC 3280 compliant path validation 
>implementation.
>
>However, there are implementations that honour Root extensions despite 
>extensions in root certificates since they are ignored in RFC 3280 path 
>validation.
>
>Stefan Santesson
>>[mailto:[email-masked]]
>>[mailto:[email-masked]]
>>On
>>[mailto:[email-masked]]
>>On

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 30 Aug 2004 17:37:30 -0400

Santosh,

Yes, I agree.  I overlooked the paragraph that Peter pointed out; sorry 
for the confusion.

Dave

---

From: Tom Gindin <[email-masked]>
Date: Tue, 31 Aug 2004 10:30:18 -0400

David:

        IMHO your suggestion is how path validation should work, as I 
stated in a discussion with Santosh a few months ago (
http://www.imc.org/ietf-pkix/mail-archive/msg02707.html).  Unfortunately, 
it is not how RFC 3280 6.1.2 k works - that initializes the maximum 
allowable length to the length of the path being tested.  Steve Hanna, in 
that same thread (http://www.imc.org/ietf-pkix/mail-archive/msg02717.html
), suggested that the first paragraph of 6.2 gave sufficient warrant to 
set the fields in the way I suggested in my posting if you want to, while 
still considering the validation algorithm 3280-compliant.  If you do that 
in your validation algorithm, it then becomes natural to honor 
NameConstraints and BasicConstraints from any v3 certificate which is 
being used to represent a trust anchor.  Of course, you can set the 
variables corresponding to those extensions from separate fields in your 
configuration database if you want to, or if you are using a v1 
certificate or bare public key to represent a trust anchor.
        Conditions on a trust anchor analogous to certificate extensions 
are natural.  What is IMO obscure is the meaning of the signature on a 
certificate being used to represent a trust anchor - the RP does not 
decide to trust or not trust the anchor based on that signature, but on 
its own independent judgment.

                Tom Gindin

"David P. Kemp" <[email-masked]>
Sent by: [email-masked]
08/30/2004 11:50 AM
 
        To:     [email-masked]
        cc: 

Santosh,

Dave

>I think extensions should be ignored in the trust anchor regardless of 
their
>However, there are implementations that honour Root extensions despite 
this