Subject: RFC 5280 Question

From: "Bob Bell (rtbell)" <[email-masked]>
Date: Mon, 9 Jun 2008 09:29:22 -0700

Folks-
 
I am hoping someone can give me the answer to this. Does RFC 5280 adress the
case where an end-entity certificate (not a CA cert) is installed in the
trust anchor list by the user accepting the presented cert as authoritative
and then the cert is subsequently presented (in a later access to the site).
There should be no path search, since the presented cert is in the trust
anchor list. So, where is it defined to accept the end-entity cert?
 
Thanks ---- Bob
 
Bob Bell
Cisco Systems, Inc.
576 S. Brentwood Ln.
Bountiful, UT 84010
801-294-3034 (v)
801-294-3023 (f)
801-971-4200 (c)
[email-masked]

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 9 Jun 2008 13:42:19 -0400

Bob,

Neither X.509 nor 5280 explicitly address this.

But, one can safely assume that the standards imply that if a trusted
certificate public key is required, there is no need for path
development and validation.

That said, trusting an end certificate could invite security trouble
depending on how this trusted certificate is handled.

As mentioned below "trust anchor list" could be problematic.  X.509 and
5280 do not require any checks on trust anchors and hence this end
certificate could spawn a bogus hierarchy and the PK enabled
applications could legitimately accept that hierarchy.

  _____  

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bob Bell (rtbell)
Sent: Monday, June 09, 2008 12:29 PM
To: [email-masked]
Subject: RFC 5280 Question

Folks-

I am hoping someone can give me the answer to this. Does RFC 5280 adress
the case where an end-entity certificate (not a CA cert) is installed in
the trust anchor list by the user accepting the presented cert as
authoritative and then the cert is subsequently presented (in a later
access to the site). There should be no path search, since the presented
cert is in the trust anchor list. So, where is it defined to accept the
end-entity cert?

Thanks ---- Bob

Bob Bell

Cisco Systems, Inc.

576 S. Brentwood Ln.

Bountiful, UT 84010

801-294-3034 (v)

801-294-3023 (f)

801-971-4200 (c)

[email-masked]

---

From: "Bob Bell (rtbell)" <[email-masked]>
Date: Mon, 9 Jun 2008 12:32:08 -0700

Santosh, et al -
 
I appreciate your response. I agree that there is a potential to have a
problem if the acceptance/provisioning of trusted certs is not done
securely. However, in this case, we are being very careful with that issue.
 
As to the "spawning a bogus hierarchy", if the cert in the trust list does
not have the CA bit set in the usage, then it cannot be used to sign other
certs, and thus cannot create this false hierarchy. Is that correct?
 
Bob

  _____  

From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Monday, 09 June, 2008 11:42
To: Bob Bell (rtbell); [email-masked]
Subject: RE: RFC 5280 Question

Bob,

But, one can safely assume that the standards imply that if a trusted
certificate public key is required, there is no need for path development
and validation.

As mentioned below "trust anchor list" could be problematic.  X.509 and 5280
do not require any checks on trust anchors and hence this end certificate
could spawn a bogus hierarchy and the PK enabled applications could
legitimately accept that hierarchy.

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bob Bell (rtbell)
Sent: Monday, June 09, 2008 12:29 PM
To: [email-masked]
Subject: RFC 5280 Question

Folks-

Thanks ---- Bob

Bob Bell

Cisco Systems, Inc.

576 S. Brentwood Ln.

Bountiful, UT 84010

801-294-3034 (v)

801-294-3023 (f)

801-971-4200 (c)

[email-masked]

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 9 Jun 2008 16:38:20 -0400

Bob,

My primary concern in terms of being very careful is that subscriber
keys are not as well protected as CA and undetected compromise becomes a
problem.  So, it is not a matter of trusting the subscriber; subscriber
could be very trustworthy, but the environment is not likely to be as
protected as the CA.

On the issue of basic constraints (a.k.a. cA bit), while many of the
client may make that check, there is no requirement in X.509 and 5280 to
make that check on a trust anchor.

  _____  

From: Bob Bell (rtbell) [mailto:[email-masked]] 
Sent: Monday, June 09, 2008 3:32 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: RFC 5280 Question

Santosh, et al -

I appreciate your response. I agree that there is a potential to have a
problem if the acceptance/provisioning of trusted certs is not done
securely. However, in this case, we are being very careful with that
issue.

As to the "spawning a bogus hierarchy", if the cert in the trust list
does not have the CA bit set in the usage, then it cannot be used to
sign other certs, and thus cannot create this false hierarchy. Is that
correct?

Bob

  _____  

Bob,

  _____  

Folks-

Thanks ---- Bob

Bob Bell

Cisco Systems, Inc.

576 S. Brentwood Ln.

Bountiful, UT 84010

801-294-3034 (v)

801-294-3023 (f)

801-971-4200 (c)

[email-masked]

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 9 Jun 2008 16:52:06 -0400

Bob,

Let me add, that in situations where all the applications on the client
platform that installs the user certificate as a trusted certificate, if
the basic constraints check is made, most of my concerns are
neutralized.

The only concern is that any revocation or compromise of that user
certificate requires some out of band means to delete the trust anchor.

________________________________

From: Santosh Chokhani 
Sent: Monday, June 09, 2008 4:38 PM
To: 'Bob Bell (rtbell)'; [email-masked]
Subject: RE: RFC 5280 Question

Bob,

________________________________

Santosh, et al -

Bob

________________________________

	Bob,

	But, one can safely assume that the standards imply that if a
trusted certificate public key is required, there is no need for path
development and validation.

	That said, trusting an end certificate could invite security
trouble depending on how this trusted certificate is handled.

	As mentioned below "trust anchor list" could be problematic.
X.509 and 5280 do not require any checks on trust anchors and hence this
end certificate could spawn a bogus hierarchy and the PK enabled
applications could legitimately accept that hierarchy.

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bob Bell (rtbell)
	Sent: Monday, June 09, 2008 12:29 PM
	To: [email-masked]
	Subject: RFC 5280 Question

	Folks-

	I am hoping someone can give me the answer to this. Does RFC
5280 adress the case where an end-entity certificate (not a CA cert) is
installed in the trust anchor list by the user accepting the presented
cert as authoritative and then the cert is subsequently presented (in a
later access to the site). There should be no path search, since the
presented cert is in the trust anchor list. So, where is it defined to
accept the end-entity cert?

	Thanks ---- Bob

	Bob Bell

	Cisco Systems, Inc.

	576 S. Brentwood Ln.

	Bountiful, UT 84010

	801-294-3034 (v)

	801-294-3023 (f)

	801-971-4200 (c)

	[email-masked]

---

From: "Bob Bell (rtbell)" <[email-masked]>
Date: Mon, 9 Jun 2008 15:07:47 -0700

Santosh -
 
Thanks for your replys. First comment, we do enforce the checking of the CA
bit in our application. That application is the only one that would use this
cert as it is specific to the application and would have no meaning
elsewhere. Also it requires a Systems Administrator approval to install the
cert, and end user cannot do it. Secondly, revocation is simply having the
SysAdmin remove it from the trust store. Since they are the sole arbiters of
whether a cert is valid for this purpose, and because the certs in question
are typically self-signed anyway, this is the mechanism we evolved to handle
deapproval of a device. These are device certs rather than user certs also.
 
Bob

  _____  

From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Monday, 09 June, 2008 14:52
To: Bob Bell (rtbell); [email-masked]
Subject: RE: RFC 5280 Question

Bob,

Let me add, that in situations where all the applications on the client
platform that installs the user certificate as a trusted certificate, if the
basic constraints check is made, most of my concerns are neutralized.

  _____  

From: Santosh Chokhani 

Bob,

My primary concern in terms of being very careful is that subscriber keys
are not as well protected as CA and undetected compromise becomes a problem.
So, it is not a matter of trusting the subscriber; subscriber could be very
trustworthy, but the environment is not likely to be as protected as the CA.

On the issue of basic constraints (a.k.a. cA bit), while many of the client
may make that check, there is no requirement in X.509 and 5280 to make that
check on a trust anchor.

  _____  

Santosh, et al -

Bob

  _____  

Bob,

  _____  

Folks-

Thanks ---- Bob

Bob Bell

Cisco Systems, Inc.

576 S. Brentwood Ln.

Bountiful, UT 84010

801-294-3034 (v)

801-294-3023 (f)

801-971-4200 (c)

[email-masked]

---

From: Tom Gindin <[email-masked]>
Date: Mon, 9 Jun 2008 19:02:56 -0400

Bob:

        It looks to me as if RFC 5280 section 6 presumes that a trust 
anchor represents an issuer, rather than permitting EE's.  If you consider 
the fields in 6.1.1, they include an issuer name but no subject name.  One 
of the conditions which basic path validation is expected to verify is 
"certificate 1 is issued by the trust anchor".  When the EE certificate is 
directly trusted, this condition will never be true, since no certificate 
exists which was issued by the trust anchor.
        While no certificate which contains keyUsage with keyCertSign not 
set can be used as an intermediate CA certificate (see 6.1.4-n), section 
6.1.4 doesn't execute against the trust anchor so verification isn't 
expected to reject the use of a directly trusted certificate as a CA 
certificate.            Section 6 isn't designed to handle a directly 
trusted EE certificate.  I think that you could tweak this by defining a 
trust anchor using the CA's certificate, with a name constraint which 
permits your EE's DN and no other using initial-permitted-subtrees, 
although you'd be trusting the CA to reserve that DN for the entity you 
want.  That way you'd get revocation check as well.  Alternatively, you 
could write your own algorithm for directly trusting EE certificates.

        Tom Gindin

"Bob Bell (rtbell)" <[email-masked]> 
Sent by: [email-masked]
06/09/2008 03:32 PM

To
"Santosh Chokhani" <[email-masked]>, <[email-masked]>
cc

Subject
RE: RFC 5280 Question

Santosh, et al -

 
Bob

Bob,

 
 
As mentioned below ?trust anchor list? could be problematic.  X.509 and 
5280 do not require any checks on trust anchors and hence this end 
certificate could spawn a bogus hierarchy and the PK enabled applications 
could legitimately accept that hierarchy.

Folks-

Thanks ---- Bob
 
Bob Bell
Cisco Systems, Inc.
576 S. Brentwood Ln.
Bountiful, UT 84010
801-294-3034 (v)
801-294-3023 (f)
801-971-4200 (c)
[email-masked]

---

From: "Bob Bell (rtbell)" <[email-masked]>
Date: Mon, 9 Jun 2008 16:24:10 -0700

Tom - 

Actually, in our case, the cert is self-signed so the issuer and the subject
are the same.

Bob 

> -----Original Message-----
> From: Tom Gindin [mailto:[email-masked]] 
> Sent: Monday, 09 June, 2008 17:03
> To: Bob Bell (rtbell)
> Cc: [email-masked]; Santosh Chokhani
>         It looks to me as if RFC 5280 section 6 presumes that 
> a trust anchor represents an issuer, rather than permitting 
> EE's.  If you consider the fields in 6.1.1, they include an 
> issuer name but no subject name.  One of the conditions which 
> basic path validation is expected to verify is "certificate 1 
> is issued by the trust anchor".  When the EE certificate is 
> directly trusted, this condition will never be true, since no 
> certificate exists which was issued by the trust anchor.
>         While no certificate which contains keyUsage with 
> keyCertSign not set can be used as an intermediate CA 
> certificate (see 6.1.4-n), section
> 6.1.4 doesn't execute against the trust anchor so 
> verification isn't expected to reject the use of a directly 
> trusted certificate as a CA 
> trusted EE certificate.  I think that you could tweak this by 
> defining a trust anchor using the CA's certificate, with a 
> name constraint which permits your EE's DN and no other using 
> initial-permitted-subtrees, although you'd be trusting the CA 
> to reserve that DN for the entity you want.  That way you'd 
> get revocation check as well.  Alternatively, you could write 
> your own algorithm for directly trusting EE certificates.
> 
>         Tom Gindin
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[email-masked]>, <[email-masked]> cc
> 
> Subject
> RE: RFC 5280 Question
> 
> 
> 
> 
> 
> 
> Santosh, et al -
>  
> I appreciate your response. I agree that there is a potential 
> to have a problem if the acceptance/provisioning of trusted 
> certs is not done securely. However, in this case, we are 
> being very careful with that issue.
>  
> As to the "spawning a bogus hierarchy", if the cert in the 
> trust list does not have the CA bit set in the usage, then it 
> cannot be used to sign other certs, and thus cannot create 
> this false hierarchy. Is that correct?
>  
> Bob
> 
> trusted certificate public key is required, there is no need 
> for path development and validation.
>  
> As mentioned below ?trust anchor list? could be problematic.  
> X.509 and 5280 do not require any checks on trust anchors and 
> hence this end certificate could spawn a bogus hierarchy and 
> the PK enabled applications could legitimately accept that hierarchy.
> 
> 5280 adress the case where an end-entity certificate (not a 
> CA cert) is installed in the trust anchor list by the user 
> accepting the presented cert as authoritative and then the 
> cert is subsequently presented (in a later access to the 
> site). There should be no path search, since the presented 
> cert is in the trust anchor list. So, where is it defined to

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 9 Jun 2008 19:57:10 -0400

Issuer name topic is a digression.

You can probably find some e-mail exchange on PKIX on it.

A Trust Anchor always has a subject name, otherwise name chaining will
not work.  I recall editor of 5280 (Dave Cooper) agreeing to that fact
on this mail thread.

-----Original Message-----
From: Bob Bell (rtbell) [mailto:[email-masked]] 
Sent: Monday, June 09, 2008 7:24 PM
To: Tom Gindin
Cc: [email-masked]; Santosh Chokhani
Subject: RE: RFC 5280 Question

Tom - 

Actually, in our case, the cert is self-signed so the issuer and the
subject
are the same.

Bob

---

From: Stephen Kent <[email-masked]>
Date: Mon, 9 Jun 2008 20:02:19 -0400

Bob,

An EE is not an issuer, so there seems to be a contradiction between 
what you describe and 5280, 3280, ...

Steve

---

From: "Bob Bell (rtbell)" <[email-masked]>
Date: Mon, 9 Jun 2008 17:11:05 -0700

Steve -

Ok, but a selfsigned certificate (such as that from IIS) is a end-entity
cert in that it does not have the CA bit set in basic constraints, but still
has both the issuer and the subject the same. I guess I am at a loss to
figure out what to call it.

Bob 

> From: Stephen Kent [mailto:[email-masked]] 
> Sent: Monday, 09 June, 2008 18:02
> To: Bob Bell (rtbell)
> Cc: Tom Gindin; [email-masked]; Santosh Chokhani
> >subject are the same.
> An EE is not an issuer, so there seems to be a contradiction 
> between what you describe and 5280, 3280, ...
> 
> 
> Steve
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 9 Jun 2008 20:57:17 -0400

In any certificate whose public key is used, the subject DN represents
the holder of the companion private.  This is true for self-signed
certificates and other trust anchor formats also.

-----Original Message-----
From: Bob Bell (rtbell) [mailto:[email-masked]] 
Sent: Monday, June 09, 2008 8:11 PM
To: Stephen Kent
Cc: Tom Gindin; [email-masked]; Santosh Chokhani
Subject: RE: RFC 5280 Question

Steve -

Ok, but a selfsigned certificate (such as that from IIS) is a end-entity
cert in that it does not have the CA bit set in basic constraints, but
still
has both the issuer and the subject the same. I guess I am at a loss to
figure out what to call it.

Bob

---

From: "Bob Bell (rtbell)" <[email-masked]>
Date: Mon, 9 Jun 2008 18:00:23 -0700

Santosh - 

That is my understanding as well. If the issuer name and the subject name
are the same, then the only real thing that it indicates is that there is no
higher authority vouching for the association between the name and private
key. Hence, if you do not trust the cert as it stands, there is no where
else to go to get any other confirmation.

Bob 

> Sent: Monday, 09 June, 2008 18:57
> To: Bob Bell (rtbell); Stephen Kent
> Cc: Tom Gindin; [email-masked]
> In any certificate whose public key is used, the subject DN 
> represents the holder of the companion private.  This is true 
> for self-signed certificates and other trust anchor formats also.
> 
> Ok, but a selfsigned certificate (such as that from IIS) is a 
> end-entity cert in that it does not have the CA bit set in 
> basic constraints, but still has both the issuer and the 
> subject the same. I guess I am at a loss to figure out what 
> to call it.
> 
> Bob 
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 9 Jun 2008 22:27:55 -0400

Bob,

I hate to drag precision into this.

Having the issuer and subject name the same does not mean that there is
no higher authority.  This can be a self-issued certificate and need not
be self-signed.

When a self-issued certificate is not self-signed, there can and should
and needs to be a trust anchor or chain of certificates emanating from a
trust anchor that verifies the self-issued certificate.

Security or lack thereof for self-issued certificate is another matter
outside the scope of this thread.

-----Original Message-----
From: Bob Bell (rtbell) [mailto:[email-masked]] 
Sent: Monday, June 09, 2008 9:00 PM
To: Santosh Chokhani; Stephen Kent
Cc: Tom Gindin; [email-masked]
Subject: RE: RFC 5280 Question

Santosh - 

That is my understanding as well. If the issuer name and the subject
name
are the same, then the only real thing that it indicates is that there
is no
higher authority vouching for the association between the name and
private
key. Hence, if you do not trust the cert as it stands, there is no where
else to go to get any other confirmation.

Bob

---

From: "Bob Bell (rtbell)" <[email-masked]>
Date: Mon, 9 Jun 2008 19:44:07 -0700

Santosh -

Ok. I guess I have never heard of a difference between self-signed and
self-issued. In the case of self-signed, the issuer and subject is the same
and there is no chain to go up to verify a higher authority (unless you
speak of some form of the CRL list source or the OCSP source, in which case,
unless you have a pre-existent trust anchor for that, there is no way to
verify the signature of the CRL/OCSP response). Since I had not heard of a
self-issued cert, I went to google and looked. I came across this url for a
message thread discussing the various types of self-issued certificates.

http://www.imc.org/ietf-pkix/old-archive-04/msg01644.html

As I read the various definitions and discussion points, it seems to me that
my End-Entity certificate is a type D self-issued certificate as opposed to
a self-signed certificate as I understood it. Does this email thread
represent a correct opinion???

Bob

> Sent: Monday, 09 June, 2008 20:28
> Having the issuer and subject name the same does not mean 
> that there is no higher authority.  This can be a self-issued 
> certificate and need not be self-signed.
> 
> When a self-issued certificate is not self-signed, there can 
> and should and needs to be a trust anchor or chain of 
> certificates emanating from a trust anchor that verifies the 
> self-issued certificate.
> 
> Security or lack thereof for self-issued certificate is 
> another matter outside the scope of this thread.
> 
> That is my understanding as well. If the issuer name and the 
> subject name are the same, then the only real thing that it 
> indicates is that there is no higher authority vouching for 
> the association between the name and private key. Hence, if 
> you do not trust the cert as it stands, there is no where 
> represents 
> > end-entity cert in that it does not have the CA bit set in basic 
> > constraints, but still has both the issuer and the subject 
> the same. I 
> > guess I am at a loss to figure out what to call it.
> > 
> > Bob
> >

---

From: "Bob Bell (rtbell)" <[email-masked]>
Date: Mon, 9 Jun 2008 20:03:40 -0700

Santosh - 

So, my cert is in fact a self-signed cert (self-issued type A). Is that
correct?

Bob 

> Sent: Monday, 09 June, 2008 21:01
> A self-signed certificate is a self-issued certificate whose 
> signature can be verified by using the subject public key in 
> the certificate itself.
> 
> From what you described before, it was an end entity 
> certificate which you explicitly trusted.  Thus, it need not 
> be a self-issued certificate.
> 
> If the CA issued itself an end entity certificate, it would 
> be Type D as you noted.
> 
> Sent: Monday, June 09, 2008 10:44 PM
> Ok. I guess I have never heard of a difference between 
> self-signed and self-issued. In the case of self-signed, the 
> issuer and subject is the same and there is no chain to go up 
> to verify a higher authority (unless you speak of some form 
> of the CRL list source or the OCSP source, in which case, 
> unless you have a pre-existent trust anchor for that, there 
> is no way to verify the signature of the CRL/OCSP response). 
> Since I had not heard of a self-issued cert, I went to google 
> and looked. I came across this url for a message thread 
> discussing the various types of self-issued certificates.
> 
> As I read the various definitions and discussion points, it 
> seems to me that my End-Entity certificate is a type D 
> self-issued certificate as opposed to a self-signed 
> certificate as I understood it. Does this email thread 
> that there 
> > is no higher authority.  This can be a self-issued certificate and 
> > need not be self-signed.
> > 
> > When a self-issued certificate is not self-signed, there can and 
> > should and needs to be a trust anchor or chain of certificates 
> > emanating from a trust anchor that verifies the self-issued 
> > certificate.
> > 
> > name are the same, then the only real thing that it 
> indicates is that 
> > there is no higher authority vouching for the association 
> between the 
> > name and private key. Hence, if you do not trust the cert as it 
> > stands, there is no where else to go to get any other confirmation.
> > 
> > Bob
> >

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 9 Jun 2008 23:00:50 -0400

Bob,

A self-signed certificate is a self-issued certificate whose signature
can be verified by using the subject public key in the certificate
itself.

>From what you described before, it was an end entity certificate which
you explicitly trusted.  Thus, it need not be a self-issued certificate.

If the CA issued itself an end entity certificate, it would be Type D as
you noted.

-----Original Message-----
From: Bob Bell (rtbell) [mailto:[email-masked]] 
Sent: Monday, June 09, 2008 10:44 PM
To: Santosh Chokhani; Stephen Kent
Cc: Tom Gindin; [email-masked]
Subject: RE: RFC 5280 Question

Santosh -

Ok. I guess I have never heard of a difference between self-signed and
self-issued. In the case of self-signed, the issuer and subject is the
same
and there is no chain to go up to verify a higher authority (unless you
speak of some form of the CRL list source or the OCSP source, in which
case,
unless you have a pre-existent trust anchor for that, there is no way to
verify the signature of the CRL/OCSP response). Since I had not heard of
a
self-issued cert, I went to google and looked. I came across this url
for a
message thread discussing the various types of self-issued certificates.

As I read the various definitions and discussion points, it seems to me
that
my End-Entity certificate is a type D self-issued certificate as opposed
to
a self-signed certificate as I understood it. Does this email thread
represent a correct opinion???

Bob

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Tue, 10 Jun 2008 18:35:53 +0800

Bob,

Since it is a certificate which you decide to directly trust, it does not matter
whether it is self-signed, self-issued, or issued by any other entity. It even does
not matter whether it is an EE certificate or a CA certificate.
You do not even need to check the signature of the certificate. This directly
trusted certificate can be viewed simply as a container to convey the public key
and subject DN (as well as other useful information of the subject) to your
applications. Since you directly trust the binding between the public key
and certificate subject (which I guess it will be a device in your case), you
can use the certificate as if it has passed a full certificate path validation.

However, if you directly trust a certificate in that fashion, the validation of the
certificate is outside of the scope of the validation algorithm of RFC 5280 (or RFC 3280).
That means you have to have an out-of-band mechanism to verify and track the
trustworthiness of the certificate, otherwise your applications will be fragile under
man-in-the-middle attacks.

Another issue you have to take into consideration is that it will be hard for
the sys admin to correctly verify and track the trustworthiness of certificates
if their amount becomes large.

Wen-Cheng Wang

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 10 Jun 2008 09:26:12 -0400

Bob,

Why do not you send me the cert as a zip file (do not post it to the
list) and I will tell you.

-----Original Message-----
From: Bob Bell (rtbell) [mailto:[email-masked]] 
Sent: Monday, June 09, 2008 11:04 PM
To: Santosh Chokhani; Stephen Kent
Cc: Tom Gindin; [email-masked]
Subject: RE: RFC 5280 Question

Santosh - 

Bob

---

From: Tim Polk <[email-masked]>
Date: Tue, 10 Jun 2008 13:27:44 -0400

Bob,

[I realize I am late to the party, and that Santosh, Steve, and Wen- 
Chen Wang have already provided a lot of good feedback.  I decided to  
respond to the original message because I would like to go back to  
the perceived requirement.]

It sounds like you want to construct a list of directly trusted EE  
certificates, but are trying to satisfy this requirement using the  
application's trust anchor store.  There is nothing inherently wrong  
with direct trust (and RFC 5280 does not preclude directly trusting  
an EE certificate), but you really need a different - and far simpler  
- mechanism.  The trust anchor store is implicitly linked to path  
discovery and validation, which are not relevant here since a  
directly trusted certificate cannot be validated.  With a directly  
trusted certificate, there is also no mechanism to validate status  
information.

To further complicate matters, storing the certificate you wish to  
directly trust in the trust anchor store implies that it is trusted  
to issue certificates as well.  The path validation inputs specified  
in 6.1.1 (d) consider only four aspects of a trust anchor (name,  
public key algorithm, public key, and parameters if needed).  The  
assumption is that the trust anchor's authority to issue certificates  
was verified based on an out-of-band trust mechanism (which is out of  
scope for 5280).  This makes sense since a trust anchor might have  
distributed a v1 certificate (which does not include extensions).

As others have noted, direct trust also implies an out-of-band trust  
mechanism.  I received the EE certificate from a trusted source so I  
can trust the binding between the subject name and the key; issuer  
name and the signature are irrelevant.   If the certificate status  
matters, I am also depending on an out-of-band mechanism to inform  
me!  The out-of-band mechanism(s) in combination with protected local  
storage provide the basis for security in this system...

Trying to combine these two mechanisms using a single certificate  
store probably requires an additional flag on every entry to  
differentiate between directly trusted certificates and trust  
anchors.  Two separate stores might be cleaner in the long run.

Thanks,

Tim Polk

On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote:

> Folks-
>
> I am hoping someone can give me the answer to this. Does RFC 5280  
> adress the case where an end-entity certificate (not a CA cert) is  
> installed in the trust anchor list by the user accepting the  
> presented cert as authoritative and then the cert is subsequently  
> presented (in a later access to the site). There should be no path  
> search, since the presented cert is in the trust anchor list. So,  
> where is it defined to accept the end-entity cert?
>
> Thanks ---- Bob
>
> Bob Bell
> Cisco Systems, Inc.
> 576 S. Brentwood Ln.
> Bountiful, UT 84010
> 801-294-3034 (v)
> 801-294-3023 (f)
> 801-971-4200 (c)
> [email-masked]
>

---

From: "Bob Bell (rtbell)" <[email-masked]>
Date: Tue, 10 Jun 2008 10:37:44 -0700

Tim -

I agree with your comments. The way we are using these certs is that if they
do not have the CA bit set in basic constraints, then they cannot be used as
a CA (i.e. they cannot vouch for additional certificates). According to
everything I have read, if the CA bit is false, then it is an EE cert by
definition.

Two cert stores would be conceptually easier, but the constraints of openSSL
make that a lot harder.

I know that I am probably boring the world to death with these issues, I am
simply trying to validate what is going one.

Bob

> From: Tim Polk [mailto:[email-masked]] 
> Sent: Tuesday, 10 June, 2008 11:28
> To: Bob Bell (rtbell)
> Cc: [email-masked]
> Subject: Re: RFC 5280 Question
> 
> Bob,
> 
> [I realize I am late to the party, and that Santosh, Steve, 
> and Wen- Chen Wang have already provided a lot of good 
> feedback.  I decided to respond to the original message 
> because I would like to go back to the perceived requirement.]
> 
> It sounds like you want to construct a list of directly 
> trusted EE certificates, but are trying to satisfy this 
> requirement using the application's trust anchor store.  
> There is nothing inherently wrong with direct trust (and RFC 
> 5280 does not preclude directly trusting an EE certificate), 
> but you really need a different - and far simpler
> - mechanism.  The trust anchor store is implicitly linked to 
> path discovery and validation, which are not relevant here 
> since a directly trusted certificate cannot be validated.  
> With a directly trusted certificate, there is also no 
> mechanism to validate status information.
> 
> To further complicate matters, storing the certificate you 
> wish to directly trust in the trust anchor store implies that 
> it is trusted to issue certificates as well.  The path 
> validation inputs specified in 6.1.1 (d) consider only four 
> aspects of a trust anchor (name, public key algorithm, public 
> key, and parameters if needed).  The assumption is that the 
> trust anchor's authority to issue certificates was verified 
> based on an out-of-band trust mechanism (which is out of 
> scope for 5280).  This makes sense since a trust anchor might 
> have distributed a v1 certificate (which does not include extensions).
> 
> As others have noted, direct trust also implies an 
> out-of-band trust mechanism.  I received the EE certificate 
> from a trusted source so I can trust the binding between the 
> subject name and the key; issuer  
> matters, I am also depending on an out-of-band mechanism to 
> inform me!  The out-of-band mechanism(s) in combination with 
> protected local storage provide the basis for security in 
> this system...
> 
> Trying to combine these two mechanisms using a single 
> certificate store probably requires an additional flag on 
> every entry to differentiate between directly trusted 
> certificates and trust anchors.  Two separate stores might be 
> cleaner in the long run.
> 
> Thanks,
> 
> Tim Polk
> 
> > cert as authoritative and then the cert is subsequently 
> presented (in 
> > a later access to the site). There should be no path 
> search, since the

---

From: max pritikin <[email-masked]>
Date: Tue, 10 Jun 2008 13:35:10 -0500

A few comments on this thread:

1) Any entry in the trust anchor store would seem to be "directly  
trusted". If so an additional flag isn't needed so much as a statement  
about how path validation proceeds if, during path discovery, it turns  
out the certificate being validated is already directly trusted.

2)  Inclusion into the trust anchor store doesn't imply that a cert is  
trusted to issue certificates -- that is directly controlled by the  
values within the certificate (chain).

3) The out-of-band mechanism is out of scope for 5280/3280 but has  
been the subject of recent BoF work (and more?). It would nice if that  
work also addressed this question.

Issues related to this come up on a regular basis. Look at the various  
ways browser deal with caching EE certificates to "trust this site  
always" etc. I think Bob has raised a good point.

- max

On Jun 10, 2008, at 12:27 PM, Tim Polk wrote:

> Chen Wang have already provided a lot of good feedback.  I decided  
> to respond to the original message because I would like to go back  
> to the perceived requirement.]
>
> an EE certificate), but you really need a different - and far  
> simpler - mechanism.  The trust anchor store is implicitly linked to  
> path discovery and validation, which are not relevant here since a  
> assumption is that the trust anchor's authority to issue  
> certificates was verified based on an out-of-band trust mechanism  
> (which is out of scope for 5280).  This makes sense since a trust  
> anchor might have distributed a v1 certificate (which does not  
> include extensions).
>
> me!  The out-of-band mechanism(s) in combination with protected  
> local storage provide the basis for security in this system...
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 10 Jun 2008 15:07:12 -0400

Max,

I do not agree with your point on item 2.  Once a certificate is a trust
anchor, neither X.509 not 5280 have any constraints on it from being a
issuer.

Furthermore, path length constraint if present in the self-signed
certificate can be ignored by relying parties.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of max pritikin
Sent: Tuesday, June 10, 2008 2:35 PM
To: Tim Polk
Cc: Bob Bell (rtbell); [email-masked]
Subject: Re: RFC 5280 Question

- max

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Tue, 10 Jun 2008 22:48:18 +0300 (EEST)

Bob, can you please cc me a copy? Thanks.
M.D.
cell: +370-699-26662

---

From: max pritikin <[email-masked]>
Date: Tue, 10 Jun 2008 15:46:38 -0500

Santosh,

RFC5280 section 4.2.1.9 (Basic Constraints) says:
>    The cA boolean indicates whether the certified public key may be  
> used
>    to verify certificate signatures.  If the cA boolean is not  
> asserted,
>    then the keyCertSign bit in the key usage extension MUST NOT be
>    asserted.  If the basic constraints extension is not present in a
>    version 3 certificate, or the extension is present but the cA  
> boolean
>    is not asserted, then the certified public key MUST NOT be used to
>    verify certificate signatures.

An EE certificate being in the trust store would not cause confusion  
about this.

- max

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 10 Jun 2008 17:36:33 -0400

Max,

The text you cite does not apply to trust anchor.  Please see X.509 and
RFC 5280 path validation text.  Nothing needs to be verified from a
trust anchor.

-----Original Message-----
From: max pritikin [mailto:[email-masked]] 
Sent: Tuesday, June 10, 2008 4:47 PM
To: Santosh Chokhani
Cc: Tim Polk; Bob Bell (rtbell); [email-masked]
Subject: Re: RFC 5280 Question

Santosh,

- max

> From: [email-masked]
[mailto:[email-masked] 
> ]

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 10 Jun 2008 18:20:54 -0400

Max,

I do not have any problem with successfully verifying signature made by
a trust anchor.

As I said a day or two back in this chain, if the relying party who
installs the certificate as a trust anchor and does not make additional
checks of basic constraints, is susceptible to undetected compromise of
this end entity certificate spawning an entire PKI hierarchy.

-----Original Message-----
From: max pritikin [mailto:[email-masked]] 
Sent: Tuesday, June 10, 2008 6:17 PM
To: Santosh Chokhani
Cc: Tim Polk; Bob Bell (rtbell); [email-masked]
Subject: Re: RFC 5280 Question

We're into the realm of discussing _how_ one would modify Certificate  
Path Validation to support EE certificates as a trust anchor where my  
intention was only to support the concept as a discussion point.

Santosh, it isn't that the constraints/extensions are ever applied to  
the trust anchor credential itself. It is that they are applied when  
validating the chain. Take for example Name Constraints or Policy  
Constraints or other Basic Constraints fields such as  
pathLenConstraint  which are all in the trust anchor certificate and  
then taken into account when validating a certificate chain. If the  
trust anchor certificate does not have keyCertSign set then logically  
no 'chained' certificates would be valid; just like if the  
pathLenConstraint was '1' but the chain being verified has a path  
length of something greater.

I think this question of EE cert vs CA cert as a trust anchor is about  
what should happen if the chain being validated consists of only the  
trust anchor. Independent of any questions concerning key usage,  
constraints or anything else.

- max

---

From: max pritikin <[email-masked]>
Date: Tue, 10 Jun 2008 17:51:06 -0500

Santosh, you've moved the conversation back to a discussion of item  
(3) in my comments below: out-of-scope population of the trust  
anchors. I think this is orthogonal to a discussion of dealing with  
trust-anchors that exactly match a single certificate being validated.

- max

---

From: max pritikin <[email-masked]>
Date: Tue, 10 Jun 2008 17:16:48 -0500

- max

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 10 Jun 2008 22:35:08 -0400

Max,

I am just responding to inaccuracies in what you are saying.

Can you and Bob tell me why you started this thread and what you are
seeking from the PKIX community?

I for sure am clueless except for pointing out inaccuracies in your
assertions and/or conclusions.

-----Original Message-----
From: max pritikin [mailto:[email-masked]] 
Sent: Tuesday, June 10, 2008 6:51 PM
To: Santosh Chokhani
Cc: Tim Polk; Bob Bell (rtbell); [email-masked]
Subject: Re: RFC 5280 Question

- max

---

From: max pritikin <[email-masked]>
Date: Tue, 10 Jun 2008 22:10:47 -0500

I'm not sure what Bob's goals are, perhaps just to ask the question.  
We don't work very closely together.

This just struck a note with me because I've seen it raised as a  
problem in other cases as well.

- max

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 11 Jun 2008 10:28:47 -0400

Max,

I do not understand from your posting what the specific concern or issue
you want to bring to the attention of PKIX.

We have had lot of digressions on this topic.

Please restate what your concerns are.

-----Original Message-----
From: max pritikin [mailto:[email-masked]] 
Sent: Tuesday, June 10, 2008 11:11 PM
To: Santosh Chokhani
Cc: Tim Polk; Bob Bell (rtbell); [email-masked]
Subject: Re: RFC 5280 Question

- max

---

From: "Bob Bell (rtbell)" <[email-masked]>
Date: Wed, 11 Jun 2008 08:04:52 -0700

Santosh -

I was requesting clarification on the meaning of some of the concepts in
RFC5280. I had no other reasons. What I was trying to establish was if there
were issues with the way some of my compatriates had interpreted the rfc.

Bob 

> [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> Sent: Tuesday, 10 June, 2008 20:35
> To: Max Pritikin (pritikin)
> Can you and Bob tell me why you started this thread and what 
> you are seeking from the PKIX community?
> 
> I for sure am clueless except for pointing out inaccuracies 
> in your assertions and/or conclusions.
> 
> > I do not have any problem with successfully verifying 
> signature made  
> > by
> > a trust anchor.
> >
> > checks of basic constraints, is susceptible to undetected 
> compromise  
> > of
> >>> 2)  Inclusion into the trust anchor store doesn't imply 
> that a cert
> >>> is
> trusted EE
> >>>> simpler - mechanism.  The trust anchor store is 
> implicitly linked  
> >>>> to

---

From: "Bob Bell (rtbell)" <[email-masked]>
Date: Thu, 12 Jun 2008 11:01:44 -0700

Timothy - 

However, these were implementation issues and not theory issues. It also
avoided several vulnerabilities wherein the device is presented with a cert
that is signed by a "trusted" CA, but that the cert was infact invalid. Case
in point was the issuance to an outside of the Microsoft signing
certificate.

Bob

> From: Timothy J Miller [mailto:[email-masked]] 
> Sent: Thursday, 12 June, 2008 11:53
> To: Santosh Chokhani
> Cc: Max Pritikin (pritikin); Tim Polk; Bob Bell (rtbell); 
> [email-masked]
> Cisco's CallManager does interesting things re: certificates 
> provisioning and trust lists (google Certificate Authority Proxy  
> Function [CAPF] and Certificate Trust List Provider [CTL 
> Provider]).   
> Coincidentally, both these services had fairly significant 
> vulnerabilities recently.
> 
> Shall I speculate that the question arises from this?  :)
> 
> -- Tim
> 
> 
> >> by a trust anchor.
> >> installs the certificate as a trust anchor and does not make 
> >> additional checks of basic constraints, is susceptible to 
> undetected 
> >> compromise of this end entity certificate spawning an entire PKI 
> >> hierarchy.
> >>
> >> I think this question of EE cert vs CA cert as a trust anchor is 
> >> about what should happen if the chain being validated consists of 
> >> only the trust anchor. Independent of any questions concerning key 
> >> usage, constraints or anything else.
> >>
> >> - max
> >>
> >>> The text you cite does not apply to trust anchor.  Please 
> see X.509 
> >>> and RFC 5280 path validation text.  Nothing needs to be verified 
> >>> from a trust anchor.
> >>>
> >>>> used to verify certificate signatures.  If the cA boolean is not 
> >>>> asserted, then the keyCertSign bit in the key usage 
> extension MUST 
> >>>> NOT be asserted.  If the basic constraints extension is 
> not present 
> >>>> in a version 3 certificate, or the extension is present 
> but the cA 
> >>>> boolean is not asserted, then the certified public key 
> MUST NOT be 
> >>>> used to verify certificate signatures.
> >>>
> >>>> I do not agree with your point on item 2.  Once a 
> certificate is a 
> >>>> trust anchor, neither X.509 not 5280 have any constraints on it 
> >>>> from being a issuer.
> >>>>
> >>>> trusted". If so an additional flag isn't needed so much as a 
> >>>> statement about how path validation proceeds if, during path 
> >>>> discovery, it turns out the certificate being validated 
> is already 
> >>>> directly trusted.
> >>>>
> >>>> is trusted to issue certificates -- that is directly 
> controlled by 
> >>>> the values within the certificate (chain).
> >>>>
> >>>> been the subject of recent BoF work (and more?). It 
> would nice if 
> >>>> that work also addressed this question.
> >>>>
> >>>> Issues related to this come up on a regular basis. Look at the 
> >>>> various ways browser deal with caching EE certificates to "trust 
> >>>> this site always" etc. I think Bob has raised a good point.
> >>>>
> >>>> - max
> >>>>
> >>>>> application's trust anchor store.  There is nothing inherently 
> >>>>> wrong with direct trust (and RFC 5280 does not preclude 
> directly 
> >>>>> trusting an EE certificate), but you really need a 
> different - and 
> >>>>> far simpler - mechanism.  The trust anchor store is implicitly 
> >>>>> linked to path discovery and validation, which are not relevant 
> >>>>> here since a directly trusted certificate cannot be validated.  
> >>>>> directly trust in the trust anchor store implies that it is 
> >>>>> trusted to issue certificates as well.  The path 
> validation inputs 
> >>>>> specified in 6.1.1 (d) consider only four aspects of a trust 
> >>>>> anchor (name, public key algorithm, public key, and 
> parameters if 
> >>>>> needed).  The assumption is that the trust anchor's 
> authority to 
> >>>>> issue certificates was verified based on an out-of-band trust 
> >>>>> mechanism (which is out of scope for 5280).  This makes sense 
> >>>>> since a trust anchor might have distributed a v1 certificate 
> >>>>> (which does not include extensions).
> >>>>>
> >>>>> As others have noted, direct trust also implies an out-of-band 
> >>>>> trust mechanism.  I received the EE certificate from a trusted 
> >>>>> source so I can trust the binding between the subject 
> name and the 
> >>>>> key; issuer
> certificate 
> >>>>>> adress the case where an end-entity certificate (not a 
> CA cert) 
> >>>>>> is installed in the trust anchor list by the user 
> accepting the 
> >>>>>> presented (in a later access to the site). There should be no 
> >>>>>> path search, since the presented cert is in the trust anchor 
> >>>>>> list. So, where is it defined to accept the end-entity cert?
> >>>>>>
> >>>>>> Thanks ---- Bob
> >>>>>>
> >>>>>> Bob Bell
> >>>>>> Cisco Systems, Inc.
> >>>>>> 576 S. Brentwood Ln.
> >>>>>> Bountiful, UT 84010
> >>>>>> 801-294-3034 (v)
> >>>>>> 801-294-3023 (f)
> >>>>>> 801-971-4200 (c)
> >>>>>> [email-masked]
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> 
>

---

From: Timothy J Miller <[email-masked]>
Date: Thu, 12 Jun 2008 12:53:18 -0500

Function [CAPF] and Certificate Trust List Provider [CTL Provider]).   

-- Tim

On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote:

>> additional
>> about
>>>> statement
>>>> various
>>>>> wrong
>>>>> trusted
>>>>> trust
>>>>>> path

---

From: max pritikin <[email-masked]>
Date: Thu, 12 Jun 2008 18:07:28 -0500

I think Bob's question touched on an important issue. The inclusion of  
self-signed or EE certificates into the certificate store.

For an example one should experiment with how the various major web  
browsers handle "trust this certificate" (sometimes called "trust this  
web page" etc). They all do it differently.

- max

On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote:

>>>>> 2)  Inclusion into the trust anchor store doesn't imply that a  
>>>>> cert
>>>>> is
>>>>>> since a
>>>>>> inform
>>>>>>> 5280

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 12 Jun 2008 20:21:04 -0400

Max,

So, are you saying that you wanted to explore the implication of a
self-signed certificate that does not have basic constraints extension
in it and does not set keyCertSign bit in the key usage?  I ask because
that is the certificate Bob sent me.

Please provide a clear, concise and complete description of your issues
so that we have the same point of reference for discussions.

-----Original Message-----
From: max pritikin [mailto:[email-masked]] 
Sent: Thursday, June 12, 2008 7:07 PM
To: Santosh Chokhani
Cc: Tim Polk; Bob Bell (rtbell); [email-masked]
Subject: Re: RFC 5280 Question

- max

---

From: "Bob Bell (rtbell)" <[email-masked]>
Date: Thu, 12 Jun 2008 19:20:51 -0700

Santosh -

I would recommend that the definition be broadened slightly to indicate that
regardless of whether basic constraints are present (as long as the CA bit
is false or non-existent), and that the keyCertSign bit is false. This, at
least as I read the definitions, defines the cert as an end-entity cert.
That kind of a cert in the trust store is what is causing problems for me.

Bob

> Sent: Thursday, 12 June, 2008 18:21
> So, are you saying that you wanted to explore the implication 
> of a self-signed certificate that does not have basic 
> constraints extension in it and does not set keyCertSign bit 
> in the key usage?  I ask because that is the certificate Bob sent me.
> 
> Please provide a clear, concise and complete description of 
> your issues so that we have the same point of reference for 
> discussions.
> 
> >>> Path Validation to support EE certificates as a trust 
> anchor where  
> >>> my
> >>> Santosh, it isn't that the constraints/extensions are 
> ever applied  
> >>> to
> >>>> The text you cite does not apply to trust anchor.  
> Please see X.509
> >>>> and
> >>>>> trusted to issue certificates -- that is directly 
> controlled by  
> >>>>> the
> >>>>>> It sounds like you want to construct a list of 
> directly trusted  
> >>>>>> EE
> >>>>>> certificates, but are trying to satisfy this 
> requirement using  
> >>>>>> the
> >>>>>> To further complicate matters, storing the certificate 
> you wish  
> >>>>>> to
> >>>>>>> adress the case where an end-entity certificate (not 
> a CA cert)
> >>>>>>> is
> >>>>>>> search, since the presented cert is in the trust 
> anchor list.  
> >>>>>>> So,

---

From: Julien Stern <[email-masked]>
Date: Fri, 13 Jun 2008 10:13:51 +0200

If I may (briefly) jump into the discussion.
There seem to be a misunderstanding regarding "trusted certificates" and 
"trust store".

Neither X.509 nor 5280 define the notion of trust store or trusted 
certificate. This does not exist and there is no such thing as trusted 
EE certificates or trusted CA certificates.

You can have a "Trust Anchor" that is a DN and a public Key (see X.509 
p.6 for the definition) which can be used to verify other certificates. 
In practice, the DN and the public key, are commonly distributed as an 
X.509 certificate, but that's to make things simple. 
Extensions/constraints, etc are not supposed to apply (See validation 
algorithm in X.509, p.50)

Then, you have the notion of "Direct Trust", which is not clearly 
expressed in X.509 or 5280, but which is natural in a PKI.
Direct Trust means that you have verified the binding between a DN and a 
public key by out of band means. In other words, it means you know the 
owner of the key.

It this owner happens to be a CA, you are essentially in the "Trust 
Anchor" case. Otherwise, you are also supposed to know (by out of band 
means) what the public key can be used for.

In your specific case, my reading of the standard is the following:

1) you insert a "certificate" in a "trust store" => This means that you 
insert only the public key and the DN as trusted and as a CA (the rest 
of the certificate is irrelevant).

2) You want to try to use standard validation mechanisms (and not direct 
trust). You take your EE cert, and since it is self signed and 
self-issued, it will validate up to the trust anchor that you have entered.

3) Be warned, however, that the owner of this public key will now be 
able to issue as many certificates for other DNs that he wishes.

Alternative option: you use "direct trust".

1) You insert your certificate in a "direct trust store".
2) When encountering the certificate, you do not perform the X.509 
validation if is it "directly trusted"
3) Be warned that you can only revoke by hand.

Now, I believe (experts, please correct me if I'm wrong), that you are 
free to modify the X.509 or the 5280 validation algorithm as long as you 
are more restrictive. So, I assume you could define a "trust store with 
constraints" that would be populated with "trust anchors with 
constraints" in any way you see fit.

Hope this helps.

Regards,

--
Julien

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 13 Jun 2008 06:36:55 -0400

Bob,

If basic constraints is absent or false, a certificate is not a CA
certificate.

The problem comes in with trust anchors.  Any requirements to process trust
anchors is a change in the standard and raises backward compatibility
issues.

-----Original Message-----
From: Bob Bell (rtbell) [mailto:[email-masked]] 
Sent: Thursday, June 12, 2008 10:21 PM
To: Santosh Chokhani; Max Pritikin (pritikin)
Cc: Tim Polk; [email-masked]
Subject: RE: RFC 5280 Question

Santosh -

Bob

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 13 Jun 2008 06:55:08 -0400

So you agree that standard does not require it and changing it is a
change in standard.

And assuming that clients check it, is risky albeit many may check.

-----Original Message-----
From: pgut001 [mailto:[email-masked]] 
Sent: Friday, June 13, 2008 6:52 AM
To: [email-masked]; Santosh Chokhani
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: RFC 5280 Question

>The text you cite does not apply to trust anchor.  Please see X.509 and
RFC
>5280 path validation text.  Nothing needs to be verified from a trust
anchor.

Right, but when I checked about two years ago a significant number of
PKI 
implementors weren't even aware that this crazy requirement exists, let
alone 
implemented it in their code (when alerted to the requirement, several
said 
they would explicitly not implement it because it constituted broken
behaviour 
and they didn't want to deal with the customer support issues).  The
only 
reason I know it exists was because someone on the X.509 standards
committee 
told me about it.  I asked for a reference, because I couldn't believe
that 
explicitly ignoring everything in a root cert was required by the
standard, 
and they said they'd get back to me.  Two weeks later they'd managed to
find 
it in the spec, and this was one of the people responsible for writing
it!

So in general proceeding under the assumption that many (most?) 
implementations aren't going to do ignore checking of root certs/trust
anchors 
is safe.  Or if you want to be strict about it, proceeding under the 
assumption that whether an implementation checks or not is pretty much a

coin-toss is safe.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 13 Jun 2008 22:52:01 +1200

"Santosh Chokhani" <[email-masked]> writes:

>The text you cite does not apply to trust anchor.  Please see X.509 and RFC
>5280 path validation text.  Nothing needs to be verified from a trust anchor.

Right, but when I checked about two years ago a significant number of PKI 
implementors weren't even aware that this crazy requirement exists, let alone 
implemented it in their code (when alerted to the requirement, several said 
they would explicitly not implement it because it constituted broken behaviour 
and they didn't want to deal with the customer support issues).  The only 
reason I know it exists was because someone on the X.509 standards committee 
told me about it.  I asked for a reference, because I couldn't believe that 
explicitly ignoring everything in a root cert was required by the standard, 
and they said they'd get back to me.  Two weeks later they'd managed to find 
it in the spec, and this was one of the people responsible for writing it!

So in general proceeding under the assumption that many (most?) 
implementations aren't going to do ignore checking of root certs/trust anchors 
is safe.  Or if you want to be strict about it, proceeding under the 
assumption that whether an implementation checks or not is pretty much a 
coin-toss is safe.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 13 Jun 2008 23:36:08 +1200

"Santosh Chokhani" <[email-masked]> writes:

>So you agree that standard does not require it and changing it is a change in
>standard.

I was told by the X.509 person that the standard does require it, and from the 
text they forwarded me I would agree that it does.  OTOH it doesn't make any 
sense for the standard to require it, and it seems to (from my informal 
survey) do the complete opposite of what customers expect.  In other words it 
violates the principle of least surprise.

>And assuming that clients check it, is risky albeit many may check.

Again, from an informal survey I'd say that the majority don't check, and that
the developers of the apps don't even know of this requirement.  In my case I
do know of it but since the response from users about whether they wanted (or
would ever expect) this behaviour was 100% negative, I explicitly don't
implement it.

Peter.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 13 Jun 2008 07:39:45 -0400

Are you saying that the standard requires you to check and enforce
constraints in a trust anchor which is a self-signed X.509 certificate?

-----Original Message-----
From: pgut001 [mailto:[email-masked]] 
Sent: Friday, June 13, 2008 7:36 AM
To: [email-masked]; [email-masked]; Santosh Chokhani
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: RFC 5280 Question

>So you agree that standard does not require it and changing it is a
change in
>standard.

I was told by the X.509 person that the standard does require it, and
from the 
text they forwarded me I would agree that it does.  OTOH it doesn't make
any 
sense for the standard to require it, and it seems to (from my informal 
survey) do the complete opposite of what customers expect.  In other
words it 
violates the principle of least surprise.

>And assuming that clients check it, is risky albeit many may check.

Again, from an informal survey I'd say that the majority don't check,
and that
the developers of the apps don't even know of this requirement.  In my
case I
do know of it but since the response from users about whether they
wanted (or
would ever expect) this behaviour was 100% negative, I explicitly don't
implement it.

Peter.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 13 Jun 2008 09:28:48 -0400

We agree on the standard's required behavior, which has been the focus
of my posts in this thread.

-----Original Message-----
From: pgut001 [mailto:[email-masked]] 
Sent: Friday, June 13, 2008 8:39 AM
To: [email-masked]; [email-masked]; Santosh Chokhani
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: RFC 5280 Question

>constraints in a trust anchor which is a self-signed X.509 certificate?

No, the standard requires that you not check trust anchors.  This is
completely contrary to what users (and implementors) seem to expect.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 14 Jun 2008 00:39:02 +1200

Peter.

---

From: "Bob Bell (rtbell)" <[email-masked]>
Date: Fri, 13 Jun 2008 07:02:39 -0700

Santosh -

The only thing I was referring to in verifying the basic constraints was to
limit the use of the certificate if the basic constraint CA bit was false
and/or the keyCertSign bit was false. In these cases, you cannot use the
certificate to validate another certificate. It does not prevent you from
validating itself. 

On the other hand, it was never my intent to cause this much controversy. My
original intent was to try to determine which of the interpretations that I
and another engineer had concerning 5280 was correct or if they both were
flawed. I think I got my answer to that question. I appreciate all of the
comments that others have made.

Bob

> Sent: Friday, 13 June, 2008 04:37
> To: Bob Bell (rtbell); Max Pritikin (pritikin)
> If basic constraints is absent or false, a certificate is not 
> a CA certificate.
> 
> The problem comes in with trust anchors.  Any requirements to 
> process trust anchors is a change in the standard and raises 
> backward compatibility issues.
> 
> I would recommend that the definition be broadened slightly 
> to indicate that regardless of whether basic constraints are 
> present (as long as the CA bit is false or non-existent), and 
> that the keyCertSign bit is false. This, at least as I read 
> the definitions, defines the cert as an end-entity cert.
> > in it and does not set keyCertSign bit in the key usage?  I ask 
> > because that is the certificate Bob sent me.
> > 
> > Please provide a clear, concise and complete description of your 
> > issues so that we have the same point of reference for discussions.
> > 
> > > I do not understand from your posting what the specific 
> concern or 
> > > issue you want to bring to the attention of PKIX.
> > >
> > >>> We're into the realm of discussing _how_ one would modify 
> > >>> Certificate Path Validation to support EE certificates 
> as a trust
> > anchor where
> > >>> my
> > >>> trust anchor certificate does not have keyCertSign set then 
> > >>> logically no 'chained' certificates would be valid; 
> just like if 
> > >>> the pathLenConstraint was '1' but the chain being 
> verified has a 
> > >>> path length of something greater.
> > >>>
> > >>> about what should happen if the chain being validated consists
> > of only the
> > >>>>> asserted, then the keyCertSign bit in the key usage extension 
> > >>>>> MUST NOT be asserted.  If the basic constraints 
> extension is not
> > present in a
> > >>>>> boolean is not asserted, then the certified public 
> key MUST NOT
> > be used to
> > >>>> An EE certificate being in the trust store would not cause 
> > >>>> confusion about this.
> > >>>>
> > >>>> - max
> > >>>>
> > >>>>> anchor, neither X.509 not 5280 have any constraints 
> on it from 
> > >>>>> being a issuer.
> > >>>>>
> > >>>>> discovery, it turns out the certificate being validated is 
> > >>>>> already directly trusted.
> > >>>>>
> > >>>>> cert is trusted to issue certificates -- that is directly
> > controlled by
> > >>>>> the
> > >>>>> various ways browser deal with caching EE certificates to
> > "trust this site
> > >>>>>> [I realize I am late to the party, and that Santosh, 
> Steve, and
> > >>>>>> Wen-
> > >>>>>> Chen Wang have already provided a lot of good feedback.  I 
> > >>>>>> decided to respond to the original message because I 
> would like 
> > >>>>>> to go back to the perceived requirement.]
> > >>>>>>
> > >>>>>> directly trusting an EE certificate), but you really need a 
> > >>>>>> different - and far simpler - mechanism.  The trust anchor 
> > >>>>>> store is
> > implicitly linked
> > >>>>>> to
> > >>>>>> since a directly trusted certificate cannot be 
> validated.  With 
> > >>>>>> a directly trusted certificate, there is also no 
> mechanism to 
> > >>>>>> trusted to issue certificates as well.  The path validation 
> > >>>>>> inputs specified in 6.1.1 (d) consider only four 
> aspects of a 
> > >>>>>> trust
> > anchor (name,
> out-of-band 
> > >>>>>> source so I can trust the binding between the 
> subject name and 
> > >>>>>> the key; issuer
> > >>>>>> protected local storage provide the basis for 
> security in this 
> > >>>>>> system...
> > >>>>>>
> > >>>>>>> 5280 adress the case where an end-entity certificate (not
> > a CA cert)
> > >>>>>>> is
> > >>>>>>> presented cert as authoritative and then the cert is 
> > >>>>>>> subsequently presented (in a later access to the 
> site). There 
> > >>>>>>> should be no path search, since the presented cert 
> is in the 
> > >>>>>>> trust
> > anchor list.  
> > >>>>>>> So,

---

From: Mike <[email-masked]>
Date: Fri, 13 Jun 2008 08:12:03 -0700

Fortunately RFC 5280 says in a couple places:

   Some communities will need to supplement, or possibly replace, this
   profile in order to meet the requirements of specialized application
   domains or environments with additional authorization, assurance, or
   operational requirements.

So if you want to check your trust anchors, it seems that you can -- just
claim that you are part of a community.  If a trust anchor certificate has
extensions, what justification is there for just ignoring them?  Somebody
put them there, and not just for grins.

Mike

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 13 Jun 2008 12:27:18 -0400

The standard defines a trust anchor to be the four items of information
needed to validate the first certificate in a chain.  The fact that
those items can be extracted from a certificate, and for convenience are
often transmitted in the form of a self-signed certificate, confuses
users into believing that a self-signed certificate is itself a trust
anchor.

PKIX could have (and should have) eliminated that confusion by defining
an unsigned trust anchor data structure, but it's a bit late for that
now.  Confusion is the natural and expected result of using the same
data structure to represent two semantically different objects.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Friday, June 13, 2008 9:29 AM
To: pgut001; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: RFC 5280 Question

-----Original Message-----
From: pgut001 [mailto:[email-masked]] 
Sent: Friday, June 13, 2008 8:39 AM
To: [email-masked]; [email-masked]; Santosh Chokhani
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: RFC 5280 Question

Peter.

---

From: Thomas Pornin <[email-masked]>
Date: Fri, 13 Jun 2008 20:19:10 +0200

On Fri, Jun 13, 2008 at 12:27:18PM -0400, Kemp, David P. wrote:
> needed to validate the first certificate in a chain.

Actually, RFC 5280 does not really define what a trust anchor is. It
defines the "trust anchor information", which is the set of four items
which is input into the path validation algorithm. The wording of RFC
5280 seems to imply that these items are obtained from some entity
called a "trust anchor", which is more alluded to than actually
explained. At the end of 6.2, one may find the following two paragraphs:

<< An implementation MAY augment the algorithm presented in Section 6.1
   to further limit the set of valid certification paths that begin with
   a particular trust anchor.  For example, an implementation MAY modify
   the algorithm to apply a path length constraint to a specific trust
   anchor during the initialization phase, or the application MAY
   require the presence of a particular alternative name form in the
   target 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.

   Where a CA distributes self-signed certificates to specify trust
   anchor information, certificate extensions can be used to specify
   recommended inputs to path validation.  For example, a policy
   constraints extension could be included in the self-signed
   certificate to indicate that paths beginning with this trust anchor
   should be trusted only for the specified policies.  Similarly, a name
   constraints extension could be included to indicate that paths
   beginning with this trust anchor should be trusted only for the
   specified name spaces.  The path validation algorithm presented in
   Section 6.1 does not assume that trust anchor information is provided
   in self-signed certificates and does not specify processing rules for
   additional information included in such certificates.
   Implementations that use self-signed certificates to specify trust
   anchor information are free to process or ignore such information. >>

This somehow settles it. The trust anchor information _may_ be
transfered under the guise of self-signed certificates but this is
mostly out of scope of RFC 5280. However, RFC 5280 does not _mandate_
that extra information provided along the trust anchor is to be ignored.
It explicitely states that implementations are free to enforce
additional restrictions on certificate paths. RFC 5280 even explains
that nothing prevents such information to be serialized with the trust
anchor information as what usually happens to be certificate extensions.

Therefore, if an application wishes to use an "augmented trust anchor"
which is a set of trust anchor information together with some additional
usage restrictions (e.g. maximum path length, explicit policies or name
constraints) to be applied when the said trust anchor is used in path
validation, then it is free to do so. Moreover, if the said application
wishes to receive and/or store this augmented trust anchor as a
"self-signed certificate" with the additional restrictions using the
format of certificate extensions, then by all means it can, and RFC 5280
even explicitely states that it does not mind. In other words, such an
implementation can still claim to be conforming to RFC 5280.

Hence there is little problem here.

There is a problem, however, in _other_ standard documents (not RFC
5280), such as those presenting signature validation policies. Such
policies may include trust anchors, encoded as self-signed certificates.
And there is no document anywhere which really defines how you should
transform a self-signed certificate into a proper set of inputs for the
validation algorithm. It is _customary_ to use the "subjectDN" as trust
anchor name, and the "subjectPublicKeyInfo" as public key information
(with key type and key parameters, when applicable). Beyond conforming
to the Tradition, it is also a quite natural choice. But there is
nothing which explicitely defines such usage. And when it comes to how
certificate extensions present in that "self-signed certificate" must be
interpreted and used, then Tradition is somewhat at a loss, and
differing interpretations exist.

Theoretically, CA should distribute their public keys along with a
"Certificate Policy Statement" which defines (in human language) what
they do and thus, indrectly, how paths originating from them as trust
anchors should be validated. Human languages are fine for humans but
computers are known to be quite thick and literal and often require a
more easily and unambiguously decodeable representation of such
information. And there is no standard on that. Even worse, there is a
widespread practice of using self-signed certificates which implementors
often erroneously assume to be sanctioned by RFC 5280 -- and they do not
all do so in the same way, of course. Various disasters ensue.

Hence the problem with self-signed certificates at trust anchors is NOT
that RFC 5280 forbids implementations to use information from the
self-signed certificate. To the contrary, RFC 5280 explicitely allows
it. The problem is that there is a need for a standard definition of how
this extended information may be used; and RFC 5280 explicitely denies
having anything to say on that matter. Note that I do NOT claim that RFC
5280 should include such a definition; I merely point out that
applications which use path validation often have a need which is often
assumed to be fulfilled by RFC 5280, whereas in fact it is not.

	--Thomas Pornin

---

From: Tom Gindin <[email-masked]>
Date: Fri, 13 Jun 2008 16:29:25 -0400

Julien, Santosh:

        Actually, I think I have an idea why Max and Bob are using terms 
in a way that is at odds with many of the rest of us.  The term "Trust 
Anchor" has meant, in RFC's 3280 and 5280 and X.509v4 and later (it wasn't 
used in 2459 or X.509v3), a certificate issuer at the beginning of a chain 
of trusted certificates.  However, in 
draft-ietf-pkix-ta-mgmt-problem-statement-01, a trust anchor may be such a 
certificate issuer or it may instead be "a public key and associated data 
used by a relying party to validate a signature on a signed object" where 
that object is not a public key certificate and cannot be validated using 
a certification path.  Max and Bob are clearly using a definition 
consistent with that one, rather than with RFC 3280 or 5280.
        We should do something to clear up this confused usage.  Either 
"trust anchors" must be issuers and the "TA Management" draft needs to 
reduce its scope or have its name changed (perhaps to "directly trusted 
keys"), or else "trust anchors" can include EE certificates and the use in 
3280 and 5280 should be called "anchor CA's" or something like that.

                Tom Gindin

Julien Stern <[email-masked]> 
Sent by: [email-masked]
06/13/2008 04:13 AM

To
"Bob Bell (rtbell)" <[email-masked]>
cc
Santosh Chokhani <[email-masked]>, "Max Pritikin (pritikin)" 
<[email-masked]>, Tim Polk <[email-masked]>, [email-masked]
Subject
Re: RFC 5280 Question

2) You want to try to use standard validation mechanisms (and not direct 
trust). You take your EE cert, and since it is self signed and 
self-issued, it will validate up to the trust anchor that you have 
entered.

Hope this helps.

Regards,

--
Julien

Bob Bell (rtbell) wrote:
>>>>> Certificate
>>>>> logically
>>>>>> confusion
>>>>>>>> decided
>>>>>>>>> subsequently

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 13 Jun 2008 19:29:31 -0400

Tom,

I am all for moving forward with
draft-ietf-pkix-ta-mgmt-problem-statement-01.

I am all for clarifying 5280.

I even do not mind change as some would like if the implementers
(relying party client developers) do not object.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Friday, June 13, 2008 4:29 PM
To: Julien Stern; Santosh Chokhani
Cc: [email-masked]; Max Pritikin (pritikin); Bob Bell (rtbell); Tim
Polk

        Julien, Santosh:

in a way that is at odds with many of the rest of us.  The term "Trust 
Anchor" has meant, in RFC's 3280 and 5280 and X.509v4 and later (it
wasn't 
used in 2459 or X.509v3), a certificate issuer at the beginning of a
chain 
of trusted certificates.  However, in 
draft-ietf-pkix-ta-mgmt-problem-statement-01, a trust anchor may be such
a 
certificate issuer or it may instead be "a public key and associated
data 
used by a relying party to validate a signature on a signed object"
where 
that object is not a public key certificate and cannot be validated
using 
a certification path.  Max and Bob are clearly using a definition 
consistent with that one, rather than with RFC 3280 or 5280.
        We should do something to clear up this confused usage.  Either 
"trust anchors" must be issuers and the "TA Management" draft needs to 
reduce its scope or have its name changed (perhaps to "directly trusted 
keys"), or else "trust anchors" can include EE certificates and the use
in 
3280 and 5280 should be called "anchor CA's" or something like that.

                Tom Gindin

To

"trust store".

Hope this helps.

Regards,

--
Julien

Bob Bell (rtbell) wrote:
> Santosh -
> 
> I would recommend that the definition be broadened slightly to
indicate 
that
> regardless of whether basic constraints are present (as long as the CA

bit
> is false or non-existent), and that the keyCertSign bit is false.
This, 
at
> That kind of a cert in the trust store is what is causing problems for

me.

---

From: Julien Stern <[email-masked]>
Date: Mon, 16 Jun 2008 10:54:23 +0200

Tom,

I agree with you there is a confusion, but I would not place it at 
exactly the same place.

IMHO, TrustAnchor is clearly defined by X.509 (but never by 5280, by the 
way).

Taken from X.509 v5:

"trust anchor: A trust anchor is a set of the following information in 
addition to the public key: algorithm identifier, public key parameters 
(if applicable), distinguished name of the holder of the associated 
private key (i.e., the subject CA) and optionally a validity period."

Now, I believe the problem is that to validate a certificate you need:
- a Trust Anchor
- the target certificate
- a validation algorithm
- input parameters for this validation algorithm

The first two are clear, but, my reading is that 5280 explicitly allows 
anyone to use its own validation algorithm and its own input parameters 
(as long as they are more restrictive than the base algorithm described).

So, to take a ridiculous example, I could do the following:
say that I have a Trust Anchor distributed as a certificate, my 
algorithm could check whether there exists an ExtendedKeyUsage 
specifying OCSP and timestamping at the same time and in that case (and 
only in that case) restrict the maximum path length of the chain to 4.

Well, I'm pretty sure that would be valid with respect to 5280. After 
all, I'm only restricting the algorithm.

Seriously though, we cannot expect to have any consistency among 
different applications if we allow different algorithms to be used.

Either we standardize on one validation algorithm (together with input 
parameters) or every TA should specify which validation algorithm 
together with which input parameters should be used to validate its certs.

All this being said, and just like Santosh, I'm all for clarifying all 
that can be clarified :) And I believe that there is no issue with X.509 
or 5280 except a _lot_ of flexibility !

Regards,

--
Julien

---

From: "Bodo Moeller" <[email-masked]>
Date: Wed, 18 Jun 2008 14:39:21 +0200

> and they didn't want to deal with the customer support issues).

I don't think that there is a *requirement* not to verify anything for
the trust anchor.  It's just that a self-signed certificate contains
various fields beyond what constitutes the actual trust anchor.  If
you decide to interpret these fields in some context, this would be
part of the out-of-bands handling of trust anchors.

Alternatively, use the self-signed certificate twice: First, extract
just the trust anchor information from it; second, include the
complete certificate into the certification path that you are going to
validate.  Then you'll verify the self-signed certificate using the
trust anchor information obtained from itself, in a way uniform with
how any other certificate would be handled.  Is there anything in the
specifications that would disallow this behavior?  I think it's just
not mandated -- despite this:

> The only

which is somewhat unspecific and doesn't necessarily sound like you
got definitive information.

> assumption that whether an implementation checks or not is pretty much a

If, as a CA, you want to make sure that every bit of information in
your CA certificate gets checked just like a certificate in the
certification path without having to rely on out-of-band information,
do put it (the information) into the certification path by using an
intermediate CA certificate with appropriate settings.  Otherwise
anyone could reasonably strip down the self-signed certificate to just
the trust anchor information and use just that for validiation.

Bodo

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 18 Jun 2008 08:18:39 -0500

Bodo Moeller wrote:

> specifications that would disallow this behavior?

See X.509 (I checked the 08/2005 edition), section 10.5.1 "Basic 
Certificate Checks": "Self-signed certificates, if encountered in the 
path, are ignored"

-- 

- Thierry Moreau

---

From: Julien Stern <[email-masked]>
Date: Wed, 18 Jun 2008 16:11:03 +0200

Peter Gutmann wrote:
> "Bodo Moeller" <[email-masked]> writes:
> 
>> I don't think that there is a *requirement* not to verify anything for the
>> trust anchor.
> 
> Nor did I, until the X.509 person told me there was.  See section 3.3.60 of
> the spec:
> 
>   3.3.60 trust anchor: A trust anchor is a set of the following information in
>   addition to the public key: algorithm identifier, public key parameters (if
>   applicable), distinguished name of the holder of the associated private key
>   (i.e., the subject CA) and optionally a validity period. The trust anchor
>   may be provided in the form of a self-signed certificate. A trust anchor is
>   trusted by a certificate using system and used for validating certificates
>   in certification paths.
> 
> Since trust anchors are typically provided in the form of self-signed CA roots 
> (as the text points out), what the text in effect says is "Ignore everything 
> in the CA root cert except the key and DN (and optionally validity)".
> 
> This requirement has come as a considerable surprise to pretty much everyone
> I've pointed it out to.

Peter,

Sorry to say it this way, but they have probably then never read X.509, 
nor RFC 3280, nor RFC 5280 :)

 From RFC 3280:

Among the 7 inputs to the validation algorithms:
------
       (d)  trust anchor information, describing a CA that serves as a
       trust anchor for the certification path.  The trust anchor
       information includes:

          (1)  the trusted issuer name,

          (2)  the trusted public key algorithm,

          (3)  the trusted public key, and

          (4)  optionally, the trusted public key parameters associated
          with the public key.

       The trust anchor information may be provided to the path
       processing procedure in the form of a self-signed certificate.
       The trusted anchor information is trusted because it was delivered
       to the path processing procedure by some trustworthy out-of-band
       procedure.  If the trusted public key algorithm requires
       parameters, then the parameters are provided along with the
       trusted public key.
------

However, I believe their considerable surprise may come from two sources:

1) RFC 2459 was not exactly crystal clear on trust anchors
2) In RFC 5280, page 90, it says:

    An implementation MAY augment the algorithm presented in Section 6.1
    to further limit the set of valid certification paths that begin with
    a particular trust anchor... Thus, the path validation algorithm
    presented in Section 6.1 defines the minimum conditions for a path to
    be considered valid.

So, my reading is that in RFC 5280 nothing PREVENTS you from using all 
the information contained in a certificate used as an envelope for a 
Trust Anchor.

Note that this actually differs from X.509 as far as my understanding 
goes: X.509 does not state that one may augment the algorithm to 
restrict the valid outputs to the validation algorithm.

All in all, what can cause "considerable surprise" in my humble opinion, 
is that one is *allowed* to use the certificate information you 
mentioned by RFC 5280, but not by X.509.

>> Alternatively, use the self-signed certificate twice: First, extract just the
>> trust anchor information from it; second, include the complete certificate
>> into the certification path that you are going to validate.

Unfortunately, you are supposed to ignore self-issued certificates 
during path processing, so this does not work.

> That requires that you know that this craziness even exists.
> 
> Peter.

Regards,

--
Julien

---

From: "Bodo Moeller" <[email-masked]>
Date: Wed, 18 Jun 2008 17:02:23 +0200

> See X.509 (I checked the 08/2005 edition), section 10.5.1 "Basic Certificate
> Checks": "Self-signed certificates, if encountered in the path, are ignored"

This text wasn't present in the 03/2000 edition that I was looking at
(it just has the obvious stuff about not counting them for
pathLenConstraints).  However, I've been able to track it down to the
following Defect Report:

     http://www.x500standard.com/uploads/Defects/DR_285.pdf

The Defect Report claims that the requirement to ignore self-signed
certificates follows from clause 8.1.5, which reads as follows:

    8.1.5  Self-issued certificates

    There are three circumstances under which a certification authority
    may issue a certificate to itself:

     a)   as a convenient way of encoding its public key for
          communication to, and storage by, its certificate users;

     b)   for certifying key usages other than certificate and CRL
          signing (such as time-stamping); and

     c)   for replacing its own expired certificates.

    These types of certificate are called self-issued certificates, and
    they can be recognized by the fact that the issuer and subject names
    present in them are identical. For purposes of path validation,
    self-issued certificates of type a) are verified with the public key
    contained in them, and if they are encountered in the path, they
    shall be ignored.

    Self-issued certificates of type b) may only appear as end
    certificates in a path, and shall be processed as end certificates.

    Self-issued certificates of type c) (also known as self-issued
    intermediate certificates) may appear as intermediate certificates
    in a path. As a matter of good practice, when replacing a key that
    is on the point of expiration, a certification authority should
    request the issuance of any in-bound cross-certificates that it
    requires for its replacement public key before using the
    key. Nevertheless, if self-issued certificates are encountered in
    the path, they shall be processed as intermediate certificates, with
    the following exception: they do not contribute to the path length
    for purposes of processing the pathLenConstraint component of the
    basicConstraints extension and the skip-certificates values
    associated with the policy-mapping-inhibit-pending and
    explicit-policy-pending indicators.

How would you tell apart a type a) self-signed certificate from a type
c) self-signed certificate?  Type a) would have to be ignored, type c)
not.  The Technical Corrigendum resulting from the Defect Report
doesn't change the wording in 8.1.5.  Why would you even need reason
c) given that the dates in the original certificate would be ignored
by the prescribed handling for type a) self-signed certificates?  Does
the 08/2005 edition still say that you must process type c)
self-signed certifcates (8.1.5) except that you must ignore them
(10.5.1)?

The only thing that is clear form this is that CAs creating
self-signed certificates in the intent to convey any information
beyond their public key, key usages, and possibly key expiration
operate outside of the scope of X.509.  Anything else would not be one
of the "circumstances under which a certification authority may issue
a certificate to itself".

Bodo

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 18 Jun 2008 11:14:25 -0400

Peter,

The text that you quoted does not constitute a *requirement* to ignore
everything in the self-signed certificate other than name and key
information.

The X.509 path validation algorithm specifies several inputs (e.g.,
initial-policy-mapping-inhibit, initial-permitted-subtrees-set, etc.).
The final paragraph of section 6.2 of RFC 5280 notes that
implementations may choose to use the contents of extensions in
self-signed "trust anchor" certificates as the basis for determining
the values of these inputs, and there is nothing in X.509 that
contradicts this.  It is true, however, that the self-signed
certificate is not supposed to be processed as if it were the first
certificate in the certification path and any use of the certificate
except as the source of trust anchor information (name and key
information) is outside the scope of the path validation algorithm.

Bodo Moeller wrote:

There is no need to create an intermediate CA for the sole purpose of
issuing it an "intermediate CA certificate with appropriate settings".
Rather than placing a nameConstraints extension in a self-signed "trust
anchor" certificate and relying on clients to process that extension,
the CA may simply (1) place such an extension in every
cross-certificate it issues and (2) refrain from issuing any
certificates with subject names that do not satisfy the name
constraint.  Rather than placing a basicConstraints extension with a
pathLenConstraint of 0 in a self-signed certificate, the CA may simply
refrain from issuing any cross-certificates (for a pathLenConstraint of
1 or more, the CA would simply need to impose the appropriate
pathLenConstraint in any cross-certificates it issues).

This is why I see no benefit in including information other than name
and key information in the self-signed certificate and why I see no
benefit in processing that information. The first certificate in the
certification path will always be issued by the CA that generated the
self-signed certificate, and there is no reason that the CA needs to
place information in the self-signed certificate to impose constraints
on itself.

Dave

Peter Gutmann wrote:

don't think that there is a *requirement* not to verify anything for the
trust anchor.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 19 Jun 2008 03:19:18 +1200

"Bodo Moeller" <[email-masked]> writes:

>The only thing that is clear form this is that CAs creating self-signed
>certificates in the intent to convey any information beyond their public key,
>key usages, and possibly key expiration operate outside of the scope of X.509.

I think you've got it reversed, it's more that X.509 is operating outside the
scope of reality :-).  I'm not really sure how to reconcile the two [0],
although perhaps the spec could at least include a warning that the behaviour
of real-world implementations is unlikely to correspond to the spec.  People
should at least be made aware of the fact that it's more or less random
whether any given implementation does this (although the random outcome does
seem strongly biased towards "No").

Peter.

[0] Well, I have a pretty good idea how it'll work out based on long-standing
    precedent: X.509 will continue to require bizarre behaviour and most of
    the world will continue to ignore it, in this case because they don't
    even know that the requirement for the behaviour exists.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 19 Jun 2008 01:24:46 +1200

Peter.

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 18 Jun 2008 14:37:36 -0400

This again does not contradict X.509, since the authorityKeyIdentifier 
and subjectKeyIdentifier extensions are not processed during path 
validation.  They are only used to add in path discovery.  The same is 
true of the id-ad-caIssuers access method of the authorityInfoAccess 
extension and the id-ad-caRepository access method of the 
subjectInfoAccess extension.

Despite Peter's claim, there is nothing in either X.509 or RFC 5280 that 
says that client software must not make use of extension information in 
self-signed certificates.  X.509 doesn't even prevent the use of this 
information in a way that would affect the outcome of path validation. 
However, the only way to use this information *in path validation* in a 
manner that is consistent to the path validation algorithm in X.509 is 
to use the information as a basis for deciding what values to specify 
for the path validation inputs (e.g., initial-policy-mapping-inhibit, 
initial-permitted-subtrees-set, etc.). The X.509 path validation 
algorithm specifies 8 inputs in addition to the certification path and 
the trust anchor information (name and key information), and it says 
nothing about what basis a client may use for deciding what values to 
specify for these inputs.  There is nothing in X.509 to prevent a client 
from choosing a value for initial-policy-mapping-inhibit based on the 
outcome of a coin flip (even though that would be a very odd 
implementation decision).  Similarly, there is nothing in X.509 to 
prevent a client from choosing a value for 
initial-policy-mapping-inhibit based on the presence or absence of a 
policyConstraints extension in the self-signed certificate from which 
trust anchor information was extracted.

Mike wrote:
> I think that more implementations of PKIX will use the other 
> information in
> self-signed certificates than not.  Consider the text in section 4.2.1.1
> about the Authority Key Identifier:
>
>   The keyIdentifier field of the authorityKeyIdentifier extension MUST
>   be included in all certificates generated by conforming CAs to
>   facilitate certification path construction.  There is one exception;
>   where a CA distributes its public key in the form of a "self-signed"
>   certificate, the authority key identifier MAY be omitted.  The
>   signature on a self-signed certificate is generated with the private
>   key associated with the certificate's subject public key.  (This
>   proves that the issuer possesses both the public and private keys.)
>   In this case, the subject and authority key identifiers would be
>   identical, but only the subject key identifier is needed for
>   certification path building.
>
> This implies that self-signed certificates will have at least a 
> subject key
> identifier, and optionally an authority key identifier.  So even the 
> authors
> of RFC 5280 seem to believe you should make use of the extension 
> information
> in self-signed certificates.
>
> Mike

---

From: Mike <[email-masked]>
Date: Wed, 18 Jun 2008 10:14:11 -0700

> seem strongly biased towards "No").

I think that more implementations of PKIX will use the other information in
self-signed certificates than not.  Consider the text in section 4.2.1.1
about the Authority Key Identifier:

This implies that self-signed certificates will have at least a subject key
identifier, and optionally an authority key identifier.  So even the authors
of RFC 5280 seem to believe you should make use of the extension information
in self-signed certificates.

Mike

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 20 Jun 2008 13:37:58 -0400

Agreed.  The distinction between a CA (a business entity) and a
Certificate (a data object produced by that entity) seems obvious.
Unlike "Certification Authority", "Trust Anchor" does not sound to me
like the name of a business entity, so I would prefer to go with the TA
Management definition of TA.  If the entity that produces trust anchors
needs a name, call it something else.

But it's not clear that the TA-generating entity needs a name.  The
issuer of a self-signed certificate is a CA, and the properties of the
CA do not suddenly change when that certificate is installed as a TA by
the first relying party.  When a path is validated using a certificate
or just the four items of TA information specified in 5280, the TA is
not "issued", it is configured by the application vendor, administrator,
or user.

I vote for Tom's second option.  If it is necessary to explicitly refer
to the generator of a certificate used as a TA, call it a TA Issuer,
Anchor CA, or whatever.

Dave

-----Original Message-----
On Behalf Of Tom Gindin

        Julien, Santosh:

                Tom Gindin