Subject: R: On cross-certificates and pathLenConstraint

From: "Santoni Adriano" <[email-masked]>
Date: Tue, 31 Aug 2004 09:25:51 +0200

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: [email-masked] [mailto:[email-masked]] Per conto di Peter Hesse
Inviato: lunedì 30 agosto 2004 18.43
A: 'David P. Kemp'; [email-masked]
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                    [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

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

*******************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: Tue, 31 Aug 2004 07:42:55 -0400

A trust anchor is not considered a certificate per X.509 and RFC 3280
regardless of what form it is promulgated in.  It could be a data structure
consisting of name, algorithm identifier, public key parameters, and public
key; it could be a self-signed certificate; or it could be a certificate. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santoni Adriano
Sent: Tuesday, August 31, 2004 3:26 AM
To: Peter Hesse; David P. Kemp
Cc: [email-masked]
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" ?

It does not say "all CA certificates that are not trust anchors"; it says
"all CA certificates".

Adriano

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per
conto di Peter Hesse
Inviato: lunedì 30 agosto 2004 18.43
A: 'David P. Kemp'; [email-masked]
Oggetto: RE: On cross-certificates and pathLenConstraint

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

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

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

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 31 Aug 2004 09:50:48 -0400

At 9:25 AM +0200 8/31/04, Santoni Adriano wrote:
>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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 31 Aug 2004 11:43:16 -0400

Steve Kent:

We could take extensions in the TA and use them to initialize a
certification path values permitted by 3280, but for values such as path
length that 3280 does not permit initialization of to an arbitrary value, it
will require a change in the standard.

From security viewpoint, I do not object to it, but it is a change to the
standard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Tuesday, August 31, 2004 9:51 AM
To: Santoni Adriano
Cc: [email-masked]
Subject: Re: R: On cross-certificates and pathLenConstraint

Steve

---

From: Steve Hanna <[email-masked]>
Date: Tue, 31 Aug 2004 16:05:10 -0400

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