Subject: R: On cross-certificates and pathLenConstraint

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

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: Fri, 27 Aug 2004 18:52:05 -0400

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. 

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

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

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.