Subject: On cross-certificates and pathLenConstraint

From: "Santoni Adriano" <[email-masked]>
Date: Fri, 27 Aug 2004 11:37:13 +0200

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.

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 27 Aug 2004 12:42:12 +0100

No,

A CA, when represented by a CA certificate with pathLengthConstraints =
0, can't issue a valid cross cert to another CA.

To be really accurate: The cross cert would actually be valid as the
last cert in a path but nothing under that cross cert would be valid.

Stefan Santesson

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Santoni Adriano
> Sent: den 27 augusti 2004 11:37
> To: [email-masked]
> Subject: On cross-certificates and pathLenConstraint
> 
> 
> Dear list,
> 
> 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.
> 
>

---

From: Sharon Boeyen <[email-masked]>
Date: Fri, 27 Aug 2004 08:33:49 -0400

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,

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?

TIA,
  Adriano

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.

---

From: Sharon Boeyen <[email-masked]>
Date: Mon, 30 Aug 2004 10:49:53 -0400

Getting back to Adriano's question:

Neither X.509 nor RFC 3280 use certificate extensions to control what
certificates can be issued by other CAs, but rather they both use the
extensions to control what certificates RPs trust. 

Dealing with path validation, if basicConstraints extension is included in a
self-signed certificate with a path length of 0, RPs will ignore that path
length constraint when the do path validation. 

However, dealing with certificate issuance, there would be nothing wrong
with using that path length constraint as a tool to help enforce the
domain's security policy, which in your example would mean that other CA's
shouldn't be issuing certificates to other CAs, but only to users. However,
beware that this is definitely not required by standards so relying on it in
any particular environment could be risky (different vendors may possibly
use different techniques to control the privileges CAs have when issuing
certificates). X.509 includes no such requirements, but focuses instead on
ensuring that only certificates that are intended to be trusted will
actually be trusted. 

Hope that helps rather than further confuses the issue :-)

Cheers,
Sharon
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Saturday, August 28, 2004 8:27 AM
To: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

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)

> 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.
> 
> 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.
> 
> 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)
> 
> 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
> 
> 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.
> 
> different values of pethLenConstraint down the chain); has anybody 
> done any testing to specifically investigate this area?
> 
> 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 
> e non possono essere considerate come
> 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 
> e non possono essere considerate come
> 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: "Stefan Santesson" <[email-masked]>
Date: Tue, 31 Aug 2004 17:35:34 +0100

Santosh,

RFC 3280 allows you to augment the path validation algorithm in any way you want as long as it is further limiting trust.

Adjusting the max_path_length variable in accordance with a root is fully compliant with this.

Stefan Santesson

> From: [email-masked] [mailto:[email-masked]]
> Sent: den 31 augusti 2004 17:17
> To: [email-masked]
> Sharon:
> I agree that one is at liberty to take material from a trust anchor and
> use
> to initialize the values for which X.509 and 3280 permit initialization.
> 
> However, part of this thread relates to basic constraints and path length.
> For basic constraints, there is nothing to initialize.  X.509 and 3280
> deal
> with path length slightly differently (but in equivalent terms).  Thus,
> 3280
> requires the value to be initialized from the length of the certification
> path and X.509 initializes path depth to 1.  Thus, based on today's
> standards, in neither case, you will take path length from the trust
> anchor
> and initialize it.
> 
> 
> 
> From: Sharon Boeyen [mailto:[email-masked]]
> Sent: Tuesday, August 31, 2004 10:45 AM
> To: 'Santosh Chokhani'; [email-masked]
> I'm always afraid to just say yes, because of nuances in phrasing :-)
> 
> On the first statement I can just say yes I agree.
> 
> On the second statement, I need to be a little bit more precise. I would
> agree with the following "When you enforce constraints on the trust anchor
> certificate as part of certificate processing in path validation, that is
> not in compliance with the standard." However, if someone uses the
> relevant
> constraints in the trust anchor certificate to initialize the path
> validation variables or process constraints, then I would not say they
> were
> non-compliant because the standard doesn't impose any particular source
> for
> those variables values. That certificate is one possible source, but there
> are others as well.
> 
> Cheers,
> Sharon
> 
> Sent: Tuesday, August 31, 2004 10:07 AM
> To: [email-masked]
> Sharon:
> So, you agree with the following statements.  Right?
> 
> "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."
> 
> From: Sharon Boeyen [mailto:[email-masked]]
> Sent: Tuesday, August 31, 2004 9:57 AM
> To: 'Santosh Chokhani'; [email-masked]
> I just want to clarify that I absolutely agree that any extensions
> contained
> in a self-signed cert are NOT processed as part of path validation. The
> self
> signed cert is NOT part of the path that gets processed. It is a mechanism
> that MAY be used to convey the public key that is used to verify the
> signature on the first cert processed in the path.
> 
> What I was trying to explain earlier is that if a self-signed certificate
> is
> used to convey the public key of the CA that is the trust anchor to
> relying
> parties there may be some extensions in that self signed certificate.
> Because the self signed certificate is not part of the certification path,
> it does not get processed in path validation. However the standards say
> nothing about what other uses an implementor may decide to make of such
> extensions. The example I gave was where an implementor may decide to use
> those to ensure that a subordinate CA does not even issue certificates to
> other CAs. Another possible use would be, as Santosh describes, to use
> those
> values to configure the input variables to the path validation process
> (what
> I was referring to as process constraints). However, those are separate
> from
> path validation processing of certificates.
> 
> I also agree with Santosh that X.509 is moving in a direction that enables
> more variables to be inititalized (e.g. name constraints). However I don't
> expect any standards defining what implementors use to intitalize those
> values. In some cases it might be reasonable to use the extensions in a
> self
> signed certificate. In other cases there could be other sources
> (especially
> if there is a need to configure those input variables on a per user group,
> per user, per application or even per transaction basis).
> 
> Cheers,
> Sharon
> Sent: Tuesday, August 31, 2004 7:47 AM
> To: [email-masked]
> 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.
> 
> Behalf Of Stefan Santesson
> Sent: Tuesday, August 31, 2004 6:26 AM
> To: Santoni Adriano; Peter Hesse; David P. Kemp
> Cc: [email-masked]
> 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
> > Sent: den 31 augusti 2004 09:26
> > To: Peter Hesse; David P. Kemp
> > Cc: [email-masked]
> > 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
> >
> >
> > Da: [email-masked] [mailto:[email-masked]]
> > Per conto di Peter Hesse
> > Inviato: lunedì 30 agosto 2004 18.43
> > A: 'David P. Kemp'; [email-masked]
> > 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
> >
> >
> > > [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.
> > > >
> > > >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 ?
> > > >>
> > > >>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 itself, to facilitate the CA key rollover, RFC 3280 seems to
> > > >>to allow the cross-certificate issuance regardless of 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
> > > >>suoi allegati e vietato e potrebbe costituire reato. Se ha
> > > >>ricevuto per errore il presente messaggio, Le saremmo grati se ci
> > > inviasse, via
> > > >>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..
> > > >>or amendment, if any, or the consequences thereof.
> > > >>
> > > >>
> > > >>suoi allegati è vietato e potrebbe costituire reato. Se ha
> > > >>ricevuto per errore il presente messaggio, Le saremmo grati se ci
> > > inviasse, via
> > > >>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..
> > > >>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. ACTALIS S.p.A. non si
> > assume alcuna responsabilita' per eventuali intercettazioni, modifiche
> > o danneggiamenti del presente messaggio e-mail.
> >
> >
> >
> > 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: Sharon Boeyen <[email-masked]>
Date: Tue, 31 Aug 2004 13:06:26 -0400

Agreed

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Tuesday, August 31, 2004 11:17 AM
To: [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

Sharon:

I agree that one is at liberty to take material from a trust anchor and use
to initialize the values for which X.509 and 3280 permit initialization.

However, part of this thread relates to basic constraints and path length.
For basic constraints, there is nothing to initialize.  X.509 and 3280 deal
with path length slightly differently (but in equivalent terms).  Thus, 3280
requires the value to be initialized from the length of the certification
path and X.509 initializes path depth to 1.  Thus, based on today's
standards, in neither case, you will take path length from the trust anchor
and initialize it.

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]] 
Sent: Tuesday, August 31, 2004 10:45 AM
To: 'Santosh Chokhani'; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

On the second statement, I need to be a little bit more precise. I would
agree with the following "When you enforce constraints on the trust anchor
certificate as part of certificate processing in path validation, that is
not in compliance with the standard." However, if someone uses the relevant
constraints in the trust anchor certificate to initialize the path
validation variables or process constraints, then I would not say they were
non-compliant because the standard doesn't impose any particular source for
those variables values. That certificate is one possible source, but there
are others as well. 

Cheers,
Sharon 

-----Original Message-----

Sharon:

Also, when you enforce constraints on the trust anchor certificate, that is
not in compliance with the standard."

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]] 
Sent: Tuesday, August 31, 2004 9:57 AM
To: 'Santosh Chokhani'; [email-masked]
Subject: RE: On cross-certificates and pathLenConstraint

I just want to clarify that I absolutely agree that any extensions contained
in a self-signed cert are NOT processed as part of path validation. The self
signed cert is NOT part of the path that gets processed. It is a mechanism
that MAY be used to convey the public key that is used to verify the
signature on the first cert processed in the path. 

What I was trying to explain earlier is that if a self-signed certificate is
used to convey the public key of the CA that is the trust anchor to relying
parties there may be some extensions in that self signed certificate.
Because the self signed certificate is not part of the certification path,
it does not get processed in path validation. However the standards say
nothing about what other uses an implementor may decide to make of such
extensions. The example I gave was where an implementor may decide to use
those to ensure that a subordinate CA does not even issue certificates to
other CAs. Another possible use would be, as Santosh describes, to use those
values to configure the input variables to the path validation process (what
I was referring to as process constraints). However, those are separate from
path validation processing of certificates. 

I also agree with Santosh that X.509 is moving in a direction that enables
more variables to be inititalized (e.g. name constraints). However I don't
expect any standards defining what implementors use to intitalize those
values. In some cases it might be reasonable to use the extensions in a self
signed certificate. In other cases there could be other sources (especially
if there is a need to configure those input variables on a per user group,
per user, per application or even per transaction basis).

Cheers,
Sharon
-----Original Message-----

Stefan:

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

Santoni,

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

> 	"...This extension MUST appear as a critical extension in all CA
> certificates

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 31 Aug 2004 19:21:23 +0200 (MEST)

> Microsoft Security Center of Excellence (SCOE)

You don't necessarily need to augment the algorithm in any way to get this effect. Just take 'yourself' as trust anchor
and issue 'cross-certs' with whatever restrictions. 

Or, the other way around, anything that you would have created at intermediate steps
down in the validation algorithm should be usable as initial values.