Subject: Re: [pkix] AD Review of draft-ietf-pkix-rfc5280-clarifications-03.txt

From: "David A. Cooper" <[email-masked]>
Date: Thu, 22 Sep 2011 12:39:07 -0400

I didn't really follow the discussion on self-signed EE
certificates, so I don't really know what people believe needs to be
added to the PKIX profile.  However, since I seem to have been
tasked with creating some text on this, here are my thoughts on the
subject.

There are essentially two ways in which one can accept an X.509
certificate:

1) Make a strictly out-of-band decision to accept the certificate;
or

2) Accept the certificate based on the results of certification path
validation, where an out-of-band decision was made to accept the
name and key that were used as the trust anchor input to the path
validation operation.  (Of course in most cases, this acceptance of
a trust anchor happens implicitly by using the default configuration
of a software application that comes pre-configured with a set of
trust anchors.)

A self-signed certificate can only be accepted via method (1).  Is
this self-signed certificate a CA certificate or an end-entity
certificate?  Does it really matter?

What would it mean for something to be a self-signed end-entity
certificate.  X.509 defines a CA as "An authority trusted by one or
more users to create and assign public-key certificates" and a CA
certificate as "A certificate for one CA issued by another CA."
X.509 defines an end entity as public-key certificate subject that
uses its private key for purposes other than signing certificates"
and an end-entity certificate as "a certificate issued to an
end-entity."

X.509 also says:

* "An end-entity certificate is a certificate issued by a CA to a
subject that is not an issuer of other public-key certificates."

* A Self-issued certificate "is a certificate where the issuer and
the subject are the same CA."

* A Self-signed certificate "is a special case of self-issued
certificates...."

So, in order for a self-signed end-entity certificate to exist, the
issuer must be both a CA and an end-entity.  In particular, the
issuer of the self-signed EE certificate would have to be "an
authority trusted by one or more users to create and assign
public-key certificates" "that is not an issuer of other
public-key certificates."  Perhaps this could occur if the issuer
were trusted by users to "create and assign" the self-signed
certificate, but didn't issuer and certificates other than the
self-signed certificate.  However, I believe that intent was that an
entity would be classified as either a CA or an end-entity, but not
both, and so I don't think X.509 intended to recognize self-signed
EE certificates.

But, again, does this really matter?  Any user can choose to make an
out-of-band decision to accept any key (a raw public key, a public
key in a self-signed certificate, or a public-key in a
non-self-signed certificate) for any purpose.  It may choose to
accept the key for use as a trust anchor for certification path
validation, to verify signatures on objects other than certificates,
or both (or for purposes other than signature verification).

So, what is the actual question at issue?  Can a relying party make
an out-of-band decision to use the public key in a self-signed
certificate to verify signatures on objects other than certificates,
but not accept the key for use as a trust anchor for certification
path validation?  Of course it can!  Can the owner of a key pair
that "uses its private key for purposes other than signing
certificates" distribute its public key in a self-signed certificate
in the hopes that others will make an out-of-band decision to accept
that public key to verify the signatures that the key owner creates
using the private key?  Of course it can!  Does the PKIX certificate
and CRL profile need to say this?

Dave

On 08/22/2011 11:08 AM, Paul Hoffman wrote:

On Aug 22, 2011, at 5:52 AM, Sean Turner wrote:

I think the -03 version is just about ready to go. That is I have no comments on the existing text though I expect getting it through the IESG will be interesting (Apps ADs love to discuss about anything to do with characters strings/sets). But, I think this draft needs to also address the issue of self-signed EE certificates. I know at least the DANE WG had a lengthy discussion about self-signed EE certificates, I see that Max's EST draft also includes them, and they're used in the wild. I want to see text included that addresses them.

+1. Given that this document already updates, not just clarifies, RFC 5280, it would be a great place to state exactly how PKIX will handle self-signed non-CA certificates in the future. David's terse writing style will be an extra bonus here.

Even if the above doesn't happen, the name of the document needs to be changed from "Clarifications to..." to "Updates to..." since both of the current sections are listed as updates, not clarifications.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 22 Sep 2011 12:21:16 -0700

A few notes inline. These are probably controversial, bordering on the religious. However, the topic is pretty important and the WG should strive to come to rough consensus.

On Sep 22, 2011, at 9:39 AM, David A. Cooper wrote:

> What would it mean for something to be a self-signed end-entity certificate.  X.509 defines a CA as "An authority trusted by one or more users to create and assign public-key certificates" and a CA certificate as "A certificate for one CA issued by another CA."  X.509 defines an end entity as public-key certificate subject that uses its private key for purposes other than signing certificates" and an end-entity certificate as "a certificate issued to an end-entity."
> 
> X.509 also says:
> 
> * "An end-entity certificate is a certificate issued by a CA to a subject that is not an issuer of other public-key certificates."
> * A Self-issued certificate "is a certificate where the issuer and the subject are the same CA."
> * A Self-signed certificate "is a special case of self-issued certificates...."

These are a lot of quotes from X.509. The idea here is to extend X.509 to handle a common use case for PKIX (not X.509) certificates, just as we have extended X.509 in the past.

> So, in order for a self-signed end-entity certificate to exist, the issuer must be both a CA and an end-entity.  In particular, the issuer of the self-signed EE certificate would have to be "an authority trusted by one or more users to create and assign public-key certificates" "that is not an issuer of other public-key certificates."  Perhaps this could occur if the issuer were trusted by users to "create and assign" the self-signed certificate, but didn't issuer and certificates other than the self-signed certificate.  However, I believe that intent was that an entity would be classified as either a CA or an end-entity, but not both, and so I don't think X.509 intended to recognize self-signed EE certificates.
> 
> But, again, does this really matter?  

Yes, definitely.

> Any user can choose to make an out-of-band decision to accept any key (a raw public key, a public key in a self-signed certificate, or a public-key in a non-self-signed certificate) for any purpose.  It may choose to accept the key for use as a trust anchor for certification path validation, to verify signatures on objects other than certificates, or both (or for purposes other than signature verification).

Exactly. But PKIX does not give an interoperable description of the format of the "public key in a self-signed certificate" for this use case. Which of the many bits are mandatory? Optional? Must not be included?

> So, what is the actual question at issue?  

Proposed target question: What is the format of public key in a self-signed certificate that is to be used for identifying an entity where path validation to existing trust anchors is not to be used?

> Can a relying party make an out-of-band decision to use the public key in a self-signed certificate to verify signatures on objects other than certificates, but not accept the key for use as a trust anchor for certification path validation?  Of course it can!  Can the owner of a key pair that "uses its private key for purposes other than signing certificates" distribute its public key in a self-signed certificate in the hopes that others will make an out-of-band decision to accept that public key to verify the signatures that the key owner creates using the private key?  Of course it can!  Does the PKIX certificate and CRL profile need to say this?

Yes, definitely, given the number of people who say that they are not allowed.

--Paul Hoffman

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 22 Sep 2011 16:30:48 -0400

On 09/22/2011 03:21 PM, Paul Hoffman wrote:
> Yes, definitely

It really matters whether we call this self-signed certificate a CA 
certificate or an end-entity certificate?  Even if X.509 classifies all 
self-signed certificates as CA certificates, that doesn't mean that a 
private key's owner can't restrict its use of the key to signing objects 
other than certificates (with the exception of the self-signed 
certificate itself) or that relying parties can't choose to only use the 
public key in the certificate to verify signatures on objects other than 
certificates.

> Exactly. But PKIX does not give an interoperable description of the format of the "public key in a self-signed certificate" for this use case. Which of the many bits are mandatory? Optional? Must n…

I guess I still don't understand what is missing.  The format of an 
X.509 certificate (self-signed or otherwise) is sufficiently well 
defined for applications to be able to parse the certificate and extract 
the public key.  Is there any other information from the certificate 
that all self-signed-certificate-using applications need?

> Proposed target question: What is the format of public key in a self-signed certificate that is to be used for identifying an entity where path validation to existing trust anchors is not to be use…

I don't understand.  Is there ever a self-signed certificate for which 
path validation to an existing trust anchor is to be used?  Are you 
looking for a way for an issuer to indicate in a self-signed 
certificate: "Please don't use me as a trust anchor for certification 
path validation?"  Would the goal be to preemptively limit the damage 
that might be caused by compromise of the private key by explicitly (in 
the certificate itself) discouraging use of the public key for purposes 
other than those originally intended by the issuer?  I suppose we could 
encourage issuers of self-signed certificates to include a 
basicConstraints extension with cA=FALSE if they do not intend to use 
the private key corresponding to the public key in the certificate to 
sign any certificates other than the self-signed certificate itself.  An 
issuer could include other extensions, such as extended key usage, to 
provide further information on how it intends to use the private key.  
However, this would only be a hint as we don't place any restrictions on 
relying parties on how they make an out-of-band decision to accept a 
public key for use as a trust anchor.

> Yes, definitely, given the number of people who say that they are not allowed.

Not allowed by who?  Do we need to say that "as of the time of this 
writing the PKIX WG is not aware of any legislation that would impose 
either civil or criminal penalties for the creation of a self-signed 
certificate by the owner of a public-key pair who does not intend to use 
the private key to sign any other certificates nor for the use of the 
public key in a self-signed certificate solely for purposes other than 
verifying signatures on certificates"?  :)

---

From: Scott Schmit <[email-masked]>
Date: Fri, 23 Sep 2011 01:14:35 -0400

On Thu, Sep 22, 2011 at 04:30:48PM -0400, David A. Cooper wrote:
> I don't understand.

As Sean mentioned, a while back, the DANE WG had an extended argument
about the validity of self-signed X.509v3 EE certificates and whether
RFC 5280 believes they are allowed, forbidden, or is mute on the
subject.

The thread starts about here:
https://www.ietf.org/mail-archive/web/dane/current/msg02227.html

but the argument starts here:
https://www.ietf.org/mail-archive/web/dane/current/msg02293.html

>              I suppose we could encourage issuers of self-signed
> certificates to include a basicConstraints extension with cA=FALSE
> if they do not intend to use the private key corresponding to the
> public key in the certificate to sign any certificates other than
> the self-signed certificate itself.
Simply stating that as a valid construction would be helpful. These
emails claim that would be invalid by definition:
https://www.ietf.org/mail-archive/web/dane/current/msg02303.html
https://www.ietf.org/mail-archive/web/dane/current/msg02309.html

others disagree:
https://www.ietf.org/mail-archive/web/dane/current/msg02311.html

> writing the PKIX WG is not aware of any legislation that would
> impose either civil or criminal penalties for the creation of a
> self-signed certificate by the owner of a public-key pair who does
> not intend to use the private key to sign any other certificates nor
> for the use of the public key in a self-signed certificate solely
> for purposes other than verifying signatures on certificates"?  :)

If you read through the thread pointed out above, you've seen examples
already, but here's a specific example:
https://www.ietf.org/mail-archive/web/dane/current/msg02382.html

Others say that the RFC is mute or ambiguous on the subject:
https://www.ietf.org/mail-archive/web/dane/current/msg02399.html
https://www.ietf.org/mail-archive/web/dane/current/msg02452.html

So some explicit language on the topic would definitely help!

Hope this helps...

-- 
Scott Schmit

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 23 Sep 2011 10:23:44 -0400

Given that the names "CA certificate" and "End-Entity certificate" are
used ONLY descriptively (applications have no knowledge of these names;
application behavior is determined solely by cert contents), the
question of whether names matter must be answered in the context of
descriptive text, NOT in the context of application behavior.

If a particular self-signed certificate cannot be used to validate
signatures on other certificates (because version >= v3 and basic
constraints is absent, for example), then it must be called an "EE cert"
and must not be called a "CA cert".  Any text that contradicts this
usage causes descriptive confusion and should be changed.

If the names don't matter, then abolish them entirely from the text of
5280 and X.509.  If they do matter, then use them correctly.

Dave

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

certificates.

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 23 Sep 2011 16:56:22 -0400

On 09/23/2011 10:23 AM, Kemp, David P. wrote:

What is the basis of your assertion that if a public key appears in
a self-signed X.509 v3 public-key certificate that doesn't contain a
basicConstraints extension that it cannot be used as a trust anchor
for certification path validation (and thus be used to validate
signatures on other certificates)?

RFC 5280 says that one of the inputs to the path validation
algorithm is trust anchor information, which essentially consists of
an issuer name and a public key.  I not aware of anything that says
that a particular issuer name and public key may not be used as
trust anchor information if ....

The only text I can find in RFC 5280 that seems to be relevant is:

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.

RFC 5280 does say that "Conforming CAs MUST include [the
basicConstraints] extension in all CA certificates that contain
public keys used to validate digital signatures on certificates and
MUST mark the extension as critical in such certificates."  However,
even if this requirement was intended to apply to self-signed
certificates, it is only a constraint on conforming CAs, not on
relying parties.  There is explicitly not a requirement for relying
parties to only accept certificates issued by CAs that conform to
the PKIX profile.

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 26 Sep 2011 09:10:55 -0400

Trust anchor information is handled out of band and is outside the
purview of standards.  So there is no prohibition against relying
parties doing anything they want with such information, including using
normal (non-self-signed) EE certificates as trust anchors.

However, if an entity is going to create a self-signed certificate to
convey trust anchor information, it should be a hint to relying parties
to treat it consistently with non-self-signed certificates, meaning
honoring extensions such as certificate policies, basic constraints, key
usage, path length constraints, name constraints, etc.  In other words,
validate paths as if the self-signed certificate is both a source of
minimal trust anchor information (name and public key) and as the first
certificate subject to normal validation rules:

     SSC
    /  \
   V    v
  TA -> SSC -> CA -> EE

The basis of my assertion is that the principle of least surprise is
satisfied when self-signed certificates are treated consistently with
all other certificates for path validation purposes.

Dave

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]] 
Sent: Friday, September 23, 2011 4:56 PM
To: Kemp, David P.
Cc: Paul Hoffman; PKIX
Subject: Re: [pkix] AD Review
ofdraft-ietf-pkix-rfc5280-clarifications-03.txt

	If a particular self-signed certificate cannot be used to
validate
	signatures on other certificates (because version >= v3 and
basic
	constraints is absent, for example), then it must be called an
"EE cert"
	and must not be called a "CA cert".  Any text that contradicts
this
	usage causes descriptive confusion and should be changed.

What is the basis of your assertion that if a public key appears in a
self-signed X.509 v3 public-key certificate that doesn't contain a
basicConstraints extension that it cannot be used as a trust anchor for
certification path validation (and thus be used to validate signatures
on other certificates)?

RFC 5280 says that one of the inputs to the path validation algorithm is
trust anchor information, which essentially consists of an issuer name
and a public key.  I not aware of anything that says that a particular
issuer name and public key may not be used as trust anchor information
if ....

	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.

RFC 5280 does say that "Conforming CAs MUST include [the
basicConstraints] extension in all CA certificates that contain public
keys used to validate digital signatures on certificates and MUST mark
the extension as critical in such certificates."  However, even if this
requirement was intended to apply to self-signed certificates, it is
only a constraint on conforming CAs, not on relying parties.  There is
explicitly not a requirement for relying parties to only accept
certificates issued by CAs that conform to the PKIX profile.

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 26 Sep 2011 09:24:55 -0400

I would like to take this discussion a bit differently.

When we were looking at comment on 5280, one of the proposals I had was the validity period in the self-signed trust anchor (TA) should be honored.  The rationale was that if the TA has undergone unauthorized modification, security of the relying party PKI is toast anyway.  Thus, assuming that the TA store is secure, enforcement is a useful security mechanism.  There was no objection to this in the list and Steve Kent suggested that this would be a good recommendation for the edits to 5280 when they occur.

I would think that the same rationale should and could apply and extensions and constraints on the TA should be and could be enforced regardless of what format the TA was in.  Now, in order to ensure backward compatibility, the suggestion could be RECOMMENDED as opposed to SHALL.  Security Considerations Section of 5280 would definitely benefit from such a discussion and rationale.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kemp, David P.
Sent: Monday, September 26, 2011 9:11 AM
To: David A. Cooper
Cc: PKIX; Paul Hoffman
Subject: Re: [pkix] AD Review ofdraft-ietf-pkix-rfc5280-clarifications-03.txt

     SSC
    /  \
   V    v
  TA -> SSC -> CA -> EE

Dave

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]] 
Sent: Friday, September 23, 2011 4:56 PM
To: Kemp, David P.
Cc: Paul Hoffman; PKIX
Subject: Re: [pkix] AD Review

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Russ Housley <[email-masked]>
Date: Mon, 26 Sep 2011 09:54:11 -0400

Santosh:

RFC 5280 does not require the TA to be distributed as a self-signed certificate.  You seems to be saying that when a self-signed certificate is used, then some aspects of the certificate ought to be checked.  This means that two relying parties might reach different conclusions based on the installation of the TA as a trusted raw public key as opposed to a trusted self-signed certificate.  What is the gain?

Russ

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 26 Sep 2011 10:11:13 -0400

Russ,

I am not saying that the TA is a self-signed certificate.

I am saying that any of the three formats of the TA (self-signed, TBS, or the other one per 5914) should enforce all the constraints.  Two parties who enforce all the constraints will be most secure and reach the same result.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Monday, September 26, 2011 9:54 AM
To: Santosh Chokhani
Cc: IETF PKIX
Subject: Re: [pkix] AD Review ofdraft-ietf-pkix-rfc5280-clarifications-03.txt

Santosh:

Russ

---

From: Martin Rex <[email-masked]>
Date: Mon, 26 Sep 2011 20:43:03 +0200 (MEST)

> all other certificates for path validation purposes.

+1

This is particularly true (desire for principle of least surprise) for CAs
that have their trust anchor certs re-issued as intermediate / cross-CA
certificates, such as those two VeriSign certificates below.

All of the certificate attributes are _restriction_ on the usage of
a self-signed certificate anyways,  And while I don't see a problem
allowing a user to neuter his trust anchors from stuff he does not
like, I also see no problem to have the PKI software honour
self-imposed restrictions from self-signed trust anchors by default.

-Martin

VeriSign G5 as cross-CA cert:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

VeriSign G5 as self-signed RootCA:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 26 Sep 2011 16:03:24 -0400

I disagree with this proposal for many reasons.

First, it is contrary to the standard and so for some extensions
would not lead to the so-called principle of least surprise.  In
particular, certificate policy processing generally requires that
every certificate in the path include a certificatePolicies
extension.  If PKIX suddenly changed the rules (and specified path
validation rules that were not compliant with X.509) and required
(or encouraged) a self-signed certificate that is used as a source
of trust anchor information to be processed as if it were the first
certificate in the path, then policy processing would fail unless
the self-signed certificate included a certificatePolicies
extension, which is frequently not included in self-signed
certificates since there is no reason for it to be there.

Second, the meaning of a constraints extension in a self-signed
certificate may be quite different from the meaning of a constraints
extension in a cross-certificate.  A constraints extension in a
cross-certificate (especially one issued to a peer CA rather than a
subordinate CA) may simply be intended to impose a limitation on the
issuing CA's relying parties.  For example, the cross-certificate
issued from the DoD Root CA to the Federal PKI includes a
policyConstraints extension with requireExplicitPolicy=0 and a
certificatePolicies extension that lists a limited number of
certificate policies.  DoD is not implying that a CA in the Federal
PKI is acting inappropriately if it issues a certificate under some
policy that DoD didn't include in its certificatePolicies
extension.  DoD simply doesn't want its relying parties to accept
any certificates issued within the Federal PKI that weren't issued
under one of the policies listed in the certificatePolicies
extension.

Do people envision a case in which a CA would want to use
constraints in its self-signed certificate to limit the set of
certificates accepted by relying parties that use the CA as a trust
anchor, but then issue certificate that violate that constraint with
the intention that these certificates should only be accepted by
relying parties that use a different CA as as trust anchor?  If not
then any constraints in a self-signed certificate should have no
effect since there should never be a certificate issued that
violates those constraints. [Note that if the CA is concerned that
CAs later in a certification path may issue certificates that
violate the constraints then the CA should include the appropriate
constraints extensions in its cross-certificates.]  If that is the
case then wouldn't the existence of a valid certificate that doesn't
conform to the constraints in the self-signed certificate be an
indication of an erroneously or fraudulently issued certificate?
Shouldn't discovery of such a certificate lead to something more
than simply path validation failure?  So, if people really think its
important for a CA to be able to constrain its own actions by
including constraint extension in a self-signed certificate, should
that self-signed certificate also include a mechanism for reporting
any discovery of a valid certificate that was issued in violation of
the specified constraints, similar to the suggestion that
draft-ietf-pkix-caa should include a mechanism for reporting a
certificate request that is contrary to the information in the DNS
record.

I also think it would be a bad idea to specify constraints in a
self-signed certificate even if all relying parties honored those
constraints.  An example of the problem with doing this can be seen
in SIDR.  RFC 3779 specified a new resource-allocation certificate
extension and included a rule specifying that this extension must
appear in the self-signed certificate used as a trust anchor.  The
resource-allocation extension is effectively a constraint extension,
since the subject of a certificate can only sub-allocate resources
that have been allocated to it.  As a result of a mistaken decision
to include constraints (i.e., the set of resources that the trust
anchor itself can allocate) in the self-signed certificate, SIDR had
to introduce the idea of a meta-trust anchor, which is used solely
to distribute the path validation trust anchor (draft-ietf-sidr-ta):

The motivation for defining the [Trust Anchor Locator]
is to enable selected data in the trust anchor to change, without
needing to effect re-distribution of the trust anchor per se.  In
the RPKI, certificates contain extensions that represent Internet
Number Resources (INRs) [RFC3779].  The set of INRs associated
with an entity likely will change over time.  Thus, if one were to
use the common PKI convention of distributing a TA to RPs in a
secure fashion, this procedure would need to be repeated whenever
the INR set for the TA changed.  By distributing the TAL (in a
secure fashion), instead of the TA, this problem is avoided, i.e.,
the TAL is constant so long as the TA's public key and its
location does not change.

Do we really want to encourage CAs to make this same mistake?  Or
should we warn CAs that there is a risk in including (unnecessary)
constraint information in a very-long-lived not-easily-replaceable
self-signed certificate.

If people really think it's important for CAs to be able to specify
constraints on their on activities, perhaps the solution is
something similar to CAA and/or DANE.  A CA that wishes to impose
constraints on itself would publish those constraints somewhere
other than in its self-signed certificate, but it could include a
pointer to the constraints in the self-signed certificate.  This
would allow the constraints to be updated without having to replace
the self-signed certificate.  A relying party would then verify that
any valid certificate did not violate the constraints information.
The constraints information would include a way to report any
certificate that violated the constraints.  [The CA would be able to
automatically process any reported certificates and only create an
alert also verifying that the reported certificate was actually
valid and in violation of the constraints information.]

On 09/26/2011 09:10 AM, Kemp, David P. wrote:

SSC
/ \
V v
TA -> SSC -> CA -> EE

Dave

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]]
Sent: Friday, September 23, 2011 4:56 PM
To: Kemp, David P.
Cc: Paul Hoffman; PKIX
Subject: Re: [pkix] AD Review

.

---

From: Tom Gindin <[email-masked]>
Date: Mon, 26 Sep 2011 20:46:40 -0400

David:

        I think it's legitimate for an intermediate CA certificate to be 
used as a trust anchor, and for the RP to honor the constraint extensions. 
 Given that, why should name constraints or policy constraints in a 
self-signed certificate not be honored?
        The cases I envision accept a trust anchor in the form an ordinary 
cross-certificate, at least in appearance.  I see two scenarios where this 
can be valuable.  In the first scenario, an extranet application trusts a 
set of corporate CA's by trusting their cross-certificates and enforces 
name constraints on them.  That application does NOT accept public 
certificates from the CA's which issued the corporate CA's certificates, 
nor certificates from all of the organizations which those CA's have 
cross-certified.  It simply trusts the corporate CA's on its list.
        In the second scenario, a distributor of RP software distributes 
trust anchors as certificates as many such packages do.  It wishes to 
enforce on many national root CA's a constraint that each may issue 
certificates containing only certain country codes in DNS names or in 
DN's, and may not issue certificates covering the global TLD's, while 
accepting their certificates for their own countries.  It creates a 
certificate for that CA with such a name constraint and an issuer 
representing the RP itself.  This certificate will not be self-signed, as 
the distributor is imposing the name constraint rather than the national 
root CA itself.  Is something wrong with this scenario?
        Constraints are always enforced as limitations on what a relying 
party will accept, and I don't see how that differs between a trust anchor 
and an intermediate CA.  We need not imply that a CA which exceeds its 
published constraints is thereby acting improperly to reject the exceeding 
certificates, and thus I don't see that the points in your second 
paragraph are relevant to implementations.

Tom Gindin

P.S.    The above opinions are my own, and not necessarily those of my 
employer.

From:   "David A. Cooper" <[email-masked]>
To:     "Kemp, David P." <[email-masked]>
Cc:     PKIX <[email-masked]>
Date:   09/26/2011 04:04 PM
Subject:        Re: [pkix] AD Review 
ofdraft-ietf-pkix-rfc5280-clarifications-03.txt
Sent by:        [email-masked]

First, it is contrary to the standard and so for some extensions would not 
lead to the so-called principle of least surprise.  In particular, 
certificate policy processing generally requires that every certificate in 
the path include a certificatePolicies extension.  If PKIX suddenly 
changed the rules (and specified path validation rules that were not 
compliant with X.509) and required (or encouraged) a self-signed 
certificate that is used as a source of trust anchor information to be 
processed as if it were the first certificate in the path, then policy 
processing would fail unless the self-signed certificate included a 
certificatePolicies extension, which is frequently not included in 
self-signed certificates since there is no reason for it to be there.

Second, the meaning of a constraints extension in a self-signed 
certificate may be quite different from the meaning of a constraints 
extension in a cross-certificate.  A constraints extension in a 
cross-certificate (especially one issued to a peer CA rather than a 
subordinate CA) may simply be intended to impose a limitation on the 
issuing CA's relying parties.  For example, the cross-certificate issued 
from the DoD Root CA to the Federal PKI includes a policyConstraints 
extension with requireExplicitPolicy=0 and a certificatePolicies extension 
that lists a limited number of certificate policies.  DoD is not implying 
that a CA in the Federal PKI is acting inappropriately if it issues a 
certificate under some policy that DoD didn't include in its 
certificatePolicies extension.  DoD simply doesn't want its relying 
parties to accept any certificates issued within the Federal PKI that 
weren't issued under one of the policies listed in the certificatePolicies 
extension.

Do people envision a case in which a CA would want to use constraints in 
its self-signed certificate to limit the set of certificates accepted by 
relying parties that use the CA as a trust anchor, but then issue 
certificate that violate that constraint with the intention that these 
certificates should only be accepted by relying parties that use a 
different CA as as trust anchor?  If not then any constraints in a 
self-signed certificate should have no effect since there should never be 
a certificate issued that violates those constraints. [Note that if the CA 
is concerned that CAs later in a certification path may issue certificates 
that violate the constraints then the CA should include the appropriate 
constraints extensions in its cross-certificates.]  If that is the case 
then wouldn't the existence of a valid certificate that doesn't conform to 
the constraints in the self-signed certificate be an indication of an 
erroneously or fraudulently issued certificate?  Shouldn't discovery of 
such a certificate lead to something more than simply path validation 
failure?  So, if people really think its important for a CA to be able to 
constrain its own actions by including constraint extension in a 
self-signed certificate, should that self-signed certificate also include 
a mechanism for reporting any discovery of a valid certificate that was 
issued in violation of the specified constraints, similar to the 
suggestion that draft-ietf-pkix-caa should include a mechanism for 
reporting a certificate request that is contrary to the information in the 
DNS record.

I also think it would be a bad idea to specify constraints in a 
self-signed certificate even if all relying parties honored those 
constraints.  An example of the problem with doing this can be seen in 
SIDR.  RFC 3779 specified a new resource-allocation certificate extension 
and included a rule specifying that this extension must appear in the 
self-signed certificate used as a trust anchor.  The resource-allocation 
extension is effectively a constraint extension, since the subject of a 
certificate can only sub-allocate resources that have been allocated to 
it.  As a result of a mistaken decision to include constraints (i.e., the 
set of resources that the trust anchor itself can allocate) in the 
self-signed certificate, SIDR had to introduce the idea of a meta-trust 
anchor, which is used solely to distribute the path validation trust 
anchor (draft-ietf-sidr-ta):
The motivation for defining the [Trust Anchor Locator] is to enable 
selected data in the trust anchor to change, without needing to effect 
re-distribution of the trust anchor per se.  In the RPKI, certificates 
contain extensions that represent Internet Number Resources (INRs) 
[RFC3779].  The set of INRs associated with an entity likely will change 
over time.  Thus, if one were to use the common PKI convention of 
distributing a TA to RPs in a secure fashion, this procedure would need to 
be repeated whenever the INR set for the TA changed.  By distributing the 
TAL (in a secure fashion), instead of the TA, this problem is avoided, 
i.e., the TAL is constant so long as the TA's public key and its location 
does not change.

Do we really want to encourage CAs to make this same mistake?  Or should 
we warn CAs that there is a risk in including (unnecessary) constraint 
information in a very-long-lived not-easily-replaceable self-signed 
certificate.

If people really think it's important for CAs to be able to specify 
constraints on their on activities, perhaps the solution is something 
similar to CAA and/or DANE.  A CA that wishes to impose constraints on 
itself would publish those constraints somewhere other than in its 
self-signed certificate, but it could include a pointer to the constraints 
in the self-signed certificate.  This would allow the constraints to be 
updated without having to replace the self-signed certificate.  A relying 
party would then verify that any valid certificate did not violate the 
constraints information.  The constraints information would include a way 
to report any certificate that violated the constraints.  [The CA would be 
able to automatically process any reported certificates and only create an 
alert also verifying that the reported certificate was actually valid and 
in violation of the constraints information.]

     SSC
    /  \
   V    v
  TA -> SSC -> CA -> EE

Dave

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]] 
Sent: Friday, September 23, 2011 4:56 PM
To: Kemp, David P.
Cc: Paul Hoffman; PKIX
Subject: Re: [pkix] AD Review

                 If a particular self-signed certificate cannot be used to
validate
                 signatures on other certificates (because version >= v3 
and
basic
                 constraints is absent, for example), then it must be 
called an
"EE cert"
                 and must not be called a "CA cert".  Any text that 
contradicts
this
                 usage causes descriptive confusion and should be changed.

does not

.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 27 Sep 2011 01:33:52 -0400

At 9:24 AM -0400 9/26/11, Santosh Chokhani wrote:
>When we were looking at comment on 5280, one of the proposals I had 
>was the validity period in the self-signed trust anchor (TA) should 
>be honored.  The rationale was that if the TA has undergone 
>unauthorized modification, security of the relying party PKI is 
>toast anyway.  Thus, assuming that the TA store is secure, 
>enforcement is a useful security mechanism.  There was no objection 
>to this in the list and Steve Kent suggested that this would be a 
>good recommendation for the edits to 5280 when they occur.
>
>I would think that the same rationale should and could apply and 
>extensions and constraints on the TA should be and could be enforced 
>regardless of what format the TA was in.  Now, in order to ensure 
>backward compatibility, the suggestion could be RECOMMENDED as 
>opposed to SHALL.  Security Considerations Section of 5280 would 
>definitely benefit from such a discussion and rationale.
>

I am in favor of your suggestion, as a RECOMMENDED procedure for RPs.

Steve

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 27 Sep 2011 16:52:17 +1000

>> ...

+1

If a trust anchor has extensions that are ignored then someone isn't getting the security they expect.

If a relying party want some restrictions enforced (such as CA #1 can only certify [email-masked] email addresses and *.example.com domains), then putting that in the root cert for CA #1 seems like a reasonable approach. Otherwise the relying party has to create their own CA and cross-certify CA #1 with the restricting extensions.

SIDR might have got themselves a bit tangled in RFC 3779 so they needed draft-ietf-sidr-ta. I don't think this shows restrictions in trust anchors are bad. RFC 3779 shows that SIDR really want to be able put restrictions on trust anchors. draft-ietf-sidr-ta shows that they don't want restrictions that might change. The obvious solution seems to be to make it optional to put the restrictions in the trust anchor (as opposed to mandatory that RFC 3779 does) [but I shouldn't talk about SIDR as I know too little about it].

--
James Manger

---

From: Stephen Kent <[email-masked]>
Date: Tue, 27 Sep 2011 03:24:48 -0400

At 4:52 PM +1000 9/27/11, Manger, James H wrote:
>  >...
>
>SIDR might have got themselves a bit tangled in RFC 3779 so they 
>needed draft-ietf-sidr-ta. I don't think this shows restrictions in 
>trust anchors are bad. RFC 3779 shows that SIDR really want to be 
>able put restrictions on trust anchors. draft-ietf-sidr-ta shows 
>that they don't want restrictions that might change. The obvious 
>solution seems to be to make it optional to put the restrictions in 
>the trust anchor (as opposed to mandatory that RFC 3779 does) [but I 
>shouldn't talk about SIDR as I know too little about it].

As a co-author of 3779, and of many SIDR docs, I can explain.

When we wrote 3779 we knew that 3280 did not mandate enforcing constraints
that might be associated with a TA, and we didn't have the set of TA 
format definitions that exist now.  So, 3779 made it clear that a 
cert used as a TA
for a path that contains 3779 extensions, MUST, itself, contain one 
or both of the 3779 extensions, and that these are used to initialize 
the 3779 path
validation parameters.

However, there is a downside to this requirement, when the trust anchors are
not stable re these values.  If, as 3779 envisioned, IANA is adopted as a TA,
there is no problem, as the IANA 3779 extensions are stable. However, 
if lower tier CAs (e.g., RIRs) want to be used as TAs, problems 
ensue.  So, the SIDR TA
doc describes how to accommodate TAs other than IANA.

Steve

---

From: Carl Wallace <[email-masked]>
Date: Tue, 27 Sep 2011 07:06:02 -0400

>I am in favor of your suggestion, as a RECOMMENDED procedure for RPs.

RFC 5937 defines how to use TA constraints during path validation.

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 27 Sep 2011 08:11:45 -0400

Carl,

I agree, except note that we should enforce constraints in the base fields as well, such as validity period.  I do not think either 5280 and 5937.

---

From: Carl Wallace <[email-masked]>
Date: Tue, 27 Sep 2011 08:14:18 -0400

On 9/27/11 8:11 AM, "Santosh Chokhani" <[email-masked]> wrote:

>Carl,
>
>I agree, except note that we should enforce constraints in the base
>fields as well, such as validity period.  I do not think either 5280 and
>5937.

Correct.  That's a good addition where validity is present.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 27 Sep 2011 06:55:19 -0700

>> I think the -03 version is just about ready to go.  That is I have no comments on the existing text though I expect getting it through the IESG will be interesting (Apps ADs love to discuss about…

This thread started there, but then sidetracked on more "improvements" on trust anchors that are express as certificates. Could we please have two threads?

--Paul Hoffman

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 27 Sep 2011 10:54:29 -0400

> If a relying party want some restrictions enforced (such as CA #1 can only certify [email-masked] email addresses and *.example.com domains), then putting that in the root cert for CA #1 seems like…

This discussion has nothing to do with a relying party choosing to 
enforce some restrictions.  This is about a CA specifying restrictions 
on itself that it (according to proponents) expects relying parties to 
enforce, even though (if I understand the argument) the CA may 
intentionally issue certificates that violate the constraints that it 
specified for itself.

A relying party can always impose constraints without the need to create 
a CA and issue cross-certificates. A relying party may impose 
restrictions via the inputs to the path validation algorithm (e.g., 
initial-permitted-subtrees).  The example you gave could be done by 
specifying an appropriate value for initial-permitted-subtrees whenever 
a path is being validated using CA #1 as the trust anchor.

Note the the relying party would not be putting the restrictions in the 
root cert (only the CA itself can place information in a self-signed 
certificate).  The relying party would be associating the restrictions 
with the root cert.

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 27 Sep 2011 11:07:43 -0400

Perhaps I am misunderstanding, but I don't see how your examples differ 
from ordinary path validation, except in the way that you describe them.

There are a couple of ways to look at your examples.  In the first 
scenario, the most logical view seems to be that the issuer of the 
cross-certificate is the trust anchor and the cross-certificate is the 
first certificate in the prospective certification path.

In the second scenario, the RP creates its own CA, which it uses as a 
trust anchor, and the certificates that it issues to the "national root 
CA's" are the first certificates in any prospective certification 
paths.  The second scenario could also be accomplished with the RP 
establishing a CA and issuing cross-certificates if the RP simply 
associated appropriate constraints with each of the national root CAs 
and used those constraints as inputs to the path validation algorithm.

It seems that only be viewing these scenarios in an unusual manner 
(i.e., calling the subject of the first (non-self-signed) certificate in 
the path the trust anchor even though you want that certificate to be 
included as part of the of the prospective certification path).

Neither of these examples, however, involve a CA issuing a self-signed 
certificate that includes constraints extensions, with the expectation 
that relying parties will enforce those constraints, and then 
intentionally issuing certificates that violate those constraints.

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 27 Sep 2011 12:16:59 -0400

Change 1 - on page 12 replace:
  "X.509 v3 also includes an extension that identifies the subject of a
   certificate as being either a CA or an end entity, reducing the
   reliance on out-of-band information demanded in PEM.

with:
   X.509 v3 also includes two extensions that identify ...

Change 2 - on page 12-13 replace:
  "This specification covers two classes of certificates: CA
   certificates and end entity certificates.  CA certificates may be
   further divided into three classes: cross-certificates, self-issued
   certificates, and self-signed certificates.  Cross-certificates are
   CA certificates in which the issuer and subject are different
   entities.  Cross-certificates describe a trust relationship between
   the two CAs.  Self-issued certificates are CA certificates in which
   the issuer and subject are the same entity.  Self-issued certificates
   are generated to support changes in policy or operations.  Self-
   signed certificates are self-issued certificates where the digital
   signature may be verified by the public key bound into the
   certificate.  Self-signed certificates are used to convey a public
   key for use to begin certification paths.  End entity certificates
   are issued to subjects that are not authorized to issue
certificates."

with:

  "This specification covers two classes of certificates: CA
   certificates and end entity certificates.  CA and EE certificates may
be
   further divided into three classes: CA-issued certificates,
self-issued
   certificates, and self-signed certificates.  Cross-certificates are
   CA certificates in which the issuer and subject are different
   entities.  Cross-certificates describe a trust relationship between
   the two CAs.  Self-issued certificates are certificates in which
   the issuer and subject are the same entity.  Self-issued certificates
   are generated to support changes in policy or operations.  Self-
   signed certificates are self-issued certificates where the digital
   signature may be verified by the public key bound into the
   certificate.  Self-signed CA certificates are used to convey a public
   key for use to begin certification paths.  End entity certificates
   are issued to subjects that are not authorized to issue certificates.
   Self-signed end entity certificates are used to convey a public key
   and other information directly to relying parties without using
   a PKI."

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Hoffman
Sent: Tuesday, September 27, 2011 9:55 AM
To: PKIX
Subject: [pkix] End-entity self-signed certs (was: Re: AD Review
ofdraft-ietf-pkix-rfc5280-clarifications-03.txt)

>> I think the -03 version is just about ready to go.  That is I have no
comments on the existing text though I expect getting it through the
IESG will be interesting (Apps ADs love to discuss about anything to do
with characters strings/sets).  But, I think this draft needs to also
address the issue of self-signed EE certificates.  I know at least the
DANE WG had a lengthy discussion about self-signed EE certificates, I
see that Max's EST draft also includes them, and they're used in the
wild.  I want to see text included that addresses them.

This thread started there, but then sidetracked on more "improvements"
on trust anchors that are express as certificates. Could we please have
two threads?

--Paul Hoffman

---

From: Tom Gindin <[email-masked]>
Date: Tue, 27 Sep 2011 21:13:21 -0400

The issuer of the cross-certificate is clearly NOT the trust 
anchor in the first scenario.  If it were, the RP would trust paths 
originating at that issuer through any of its many cross-certificates 
instead of only those using the trusted cross-certificate.  I am not 
requiring that the cross-certificates in question be checked for 
revocation or even verified, so they aren't part of the path.  It's only 
more logical to regard the issuer of the cross certificate as the anchor 
if you are committed to the idea that the only certificates which should 
be used as anchors are self-signed.  TrustAnchorInfo in RFC 5914 section 2 
has no analogue of the issuer field or the certificate signature, so 
whether a certificate is self-signed or a cross-certificate has no effect 
on whether it's a valid source for that information.
        Trust anchors are decided on by the RP, and whether the issuer of 
a CA certificate intended it to be used as an anchor does not bind him. We 
can assume that a self-signed CA certificate was intended for use by RP's 
as an anchor, but I see no reason why a cross-certificate cannot also be 
used as an anchor.

Tom Gindin

From:   "David A. Cooper" <[email-masked]>
To:     Tom Gindin/Watson/IBM@IBMUS
Cc:     PKIX <[email-masked]>
Date:   09/27/2011 11:09 AM
Subject:        Re: [pkix] AD Review 
ofdraft-ietf-pkix-rfc5280-clarifications-03.txt

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 28 Sep 2011 12:26:25 +1000

How does an RP impose those restrictions in practice?

Adding a trust anchor to, say, Windows or Firefox or Java is not too hard. On Windows or Firefox you can click through a handful of dialogs to restrict the trust anchor to, say, "server authentication" but not "code signing". It is far less clear if or how other restrictions can be applied.
Just because PKIX lists some inputs to the path validation algorithm doesn't make them easy to specify in actual software, nor consistently across different software -- unless they can be specified in the trust anchor cert itself.

--
James Manger

---

From: Stephen Kent <[email-masked]>
Date: Wed, 28 Sep 2011 03:40:47 -0400

Carl,

Thanks for the reminder. A reference to 5937 probably would be appropriate
as part of this clarification.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 28 Sep 2011 09:54:07 -0400

> Just because PKIX lists some inputs to the path validation algorithm doesn't make them easy to specify in actual software, nor consistently across different software -- unless they can be specified…

How does a relying put restrictions that it wishes to impose in a root 
certificate that was issued by a different entity?

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 28 Sep 2011 10:24:24 -0400

On 09/27/2011 09:13 PM, Tom Gindin wrote:
> instead of only those using the trusted cross-certificate.

The X.509 path validation algorithm simply takes a trust anchor, a 
prospective certification path, and other information, and provides a 
valid/not valid response (or at least that's a slightly simplified 
version of how it works).  There is nothing that says that if you choose 
to use a particular trust anchor when validating one particular 
prospective certification path that you must accept any certification 
path that can be validated using that same trust anchor.  So, any claim 
that the issuer of a certificate cannot have been used as a trust anchor 
when validating one prospective certification path because you would be 
unwilling to use that same trust anchor to validate other prospective 
certification paths simply demonstrates a misunderstanding of the standard.

> I am not
> revocation or even verified, so they aren't part of the path.

So what you are proposing is that the certificate from which you extract 
the trust anchor information is not actually processed as the first 
certificate in the path, as others are arguing should be done with the 
certificate from which trust anchor information is extracted.   Rather 
you are suggesting that the relying party should be free to impose 
constraints on the set of certification paths that it will accept from a 
given trust anchor.  I don't think anyone has argued against that.  That 
is why the path validation algorithm allows for inputs such as 
initial-permitted-subtrees to be specified.  But, the values of these 
inputs are specified by the relying party, not by the trust anchor.  The 
trust anchor imposes constraints by (1) not issuing certificates that 
violate its own self-imposed constraints and (2) including appropriate 
constraints extensions in an cross-certificates that it issues.

> It's only more logical to regard the issuer of the cross certificate as the anchor

Not true at all.  It is perfectly reasonable to regard the issue of the 
cross-certificate as the trust anchor if you intend to process the 
cross-certificate as if it were the first certificate in the prospective 
certification path in order to process any constraints extensions in the 
certificate.

> as an anchor, but I see no reason why a cross-certificate cannot also be

It can, and I never argued otherwise.  But, if you decide to process 
this extension in order to honor any constraints extensions that it has, 
then this cross-certificate is the first certificate in the 
certification path and the issuer of the certificate is the trust 
anchor.  The subject of the cross-certificate is only the trust anchor 
if that subject issued the first certificate in the prospective 
certification path, and in that case, since the relying party gets to 
select the values for the path validation inputs, it is up to the 
relying party to decide whether its wants to consider the information in 
the cross-certificate when it decides what values to use for the path 
validation inputs.

> From:   "David A. Cooper"<[email-masked]>
> Cc:     PKIX<[email-masked]>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 28 Sep 2011 10:33:16 -0400

At 9:54 AM -0400 9/28/11, David A. Cooper wrote:
>>Adding a trust anchor to, say, Windows or Firefox or Java is not 
>>too hard. On Windows or Firefox you can click through a handful of 
>>dialogs to restrict the trust anchor to, say, "server 
>>authentication" but not "code signing". It is far less clear if or 
>>how other restrictions can be applied.
>>Just because PKIX lists some inputs to the path validation 
>>algorithm doesn't make them easy to specify in actual software, nor 
>>consistently across different software -- unless they can be 
>>specified in the trust anchor cert itself.
>
>How does a relying put restrictions that it wishes to impose in a 
>root certificate that was issued by a different entity?

I have long suggested that every RP ought to have exactly one TA, 
managed by the RP itself. This enables the RP to take each ss-cert 
from a would-be TA, extract the name, public key and other params, 
and issue a cert under the RP's TA.
The local TA management ID in SIDR adopts this approach.  (That doc 
is complex because of the need to accommodate 3779, but the basic 
principle applies.)

Steve

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 29 Sep 2011 14:39:58 +1000

>is complex because of the need to accommodate 3779, but the basic 

Each RP being their one-and-only TA is a great idea... but does the RP actually need to manage a private key to do so?
Certs created by an RP for would-be TAs (adding the RP's own restrictions) aren't sent in on-the-wire protocols. They are just configured into the RP client system. I don't think it helps much to actually sign them with an RP private key -- as long as the restrictions are enforce when they are TAs.

--
James Manger

---

From: Stephen Kent <[email-masked]>
Date: Thu, 29 Sep 2011 03:10:11 -0400

James,

>...
>
>
>Each RP being their one-and-only TA is a great idea... but does the 
>RP actually need to manage a private key to do so?
>Certs created by an RP for would-be TAs (adding the RP's own 
>restrictions) aren't sent in on-the-wire protocols. They are just 
>configured into the RP client system. I don't think it helps much to 
>actually sign them with an RP private key -- as long as the 
>restrictions are enforce when they are TAs.

The RP needs a private key, because it is signing the certs it creates,
under it's TA. These certs will be processed as any other subordinate
cert, so one needs to validate the sig on these RP-issued certs; they
are not TAs.  I don't see the need for an RP to have its own key pair, used
just for this purpose, to be a big impediment.

Steve

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 29 Sep 2011 09:00:15 -0400

The private key is necessary to extend integrity protection of the TA
public key outward to the RP cert.  If device storage for TA and RP
certs
is equally resistant to modification, then there's no need for a private
key because the RP cert could be held in protected storage in TBS form.
But if protected storage is a precious commodity then a single TA
keypair
can be stored on, e.g., a TPM while protecting an unlimited number
of RP certs stored on normal filesystems, including removable media.

The private key isn't necessary for things like signed software
distribution
because the consumer doesn't modify the software.  But RPs do need to
create or modify validation constraints.

+1 for RP-signed RP certs.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Kent
Sent: Thursday, September 29, 2011 3:10 AM
To: Manger, James H
Cc: [email-masked]
Subject: Re: [pkix] AD Review
ofdraft-ietf-pkix-rfc5280-clarifications-03.txt

James,

are not TAs.  I don't see the need for an RP to have its own key pair,
used

Steve