Subject: I-D Action:draft-ietf-pkix-ta-format-01.txt

From: [email-masked]
Date: Wed, 4 Mar 2009 08:15:02 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : Trust Anchor Format
	Author(s)       : R. Housley, et al.
	Filename        : draft-ietf-pkix-ta-format-01.txt
	Pages           : 17
	Date            : 2009-03-04

This document describes a structure for representing trust anchor
information.  A trust anchor is an authoritative entity represented
by a public key and associated data.  The public key is used to
verify digital signatures and the associated data is used to
constrain the types of information or actions for which the trust
anchor is authoritative.  The structures defined in this document are
intended to satisfy the format-related requirements defined in Trust
Anchor Management Requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Julien Stern <[email-masked]>
Date: Wed, 04 Mar 2009 19:19:31 +0100

> 	Filename        : draft-ietf-pkix-ta-format-01.txt

Hi,

Nice work. Thanks.

One first comment regarding the CertPolicyFlags:

They are defined as:

CertPolicyFlags ::= BIT STRING {
       inhibitPolicyMapping   (0),
       requireExplicitPolicy  (1),
       inhibitAnyPolicy       (2) }

But in 5280, they are integer, not booleans, for example:

PolicyConstraints ::= SEQUENCE {
      requireExplicitPolicy   [0]     SkipCerts OPTIONAL,
      inhibitPolicyMapping    [1]     SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)

I believe that we should keep them integers to keep the full generality 
(unless I missed a point).

On a more global note, I noticed some time ago that a document from ETSI 
(namely ETSI 102 272) defined a fairly similar (albeit simpler) 
structure. It dates from 2003, but could provide some interesting bits.
For those interested, here is the link: 
http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=19571

For those interested, but lazy, here are the relevant "raw ASN.1" bits:

CertificateTrustPoint ::= SEQUENCE {
     trustpoint              Certificate,
     pathLenConstraint   [0] PathLenConstraint   OPTIONAL,
     acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, -- If not 
present "any policy"
     nameConstraints     [2] NameConstraints     OPTIONAL,
     policyConstraints   [3] PolicyConstraints   OPTIONAL }

PathLenConstraint ::= INTEGER (0..MAX)
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= OBJECT IDENTIFIER

NameConstraints ::= SEQUENCE {
           permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
           excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
           base                    GeneralName,
           minimum         [0]     BaseDistance DEFAULT 0,
           maximum         [1]     BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)

PolicyConstraints ::= SEQUENCE {
         requireExplicitPolicy    [0] SkipCerts OPTIONAL,
         inhibitPolicyMapping     [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX)

I like the fact that the certificate is optional in the TA draft, and 
that it can be defined as a pure DN/Public Key pair. I've always thought 
the direct inclusion of a self-signed certificate led to possible 
unclarities as regards treatment of extensions. But anyway, always 
interesting to compare with what exists ...

Regards,

--
Julien

---

From: Julien Stern <[email-masked]>
Date: Wed, 04 Mar 2009 19:43:46 +0100

> 	Filename        : draft-ietf-pkix-ta-format-01.txt

Hi again,

separating from the previous email due to the nature of the comment: 
this one is more "philosophical" :)

This draft defines a trust anchor as a public key with additional data.

I believe that the most common usage of the word "trust anchor" denotes 
the _binding_ of a public key _and_ a name. A certificate binds a name 
and a public key (along with other information) thanks to a signature. A 
trust anchor binds them through direct trust.

And indeed, the definition in X.509 is:

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.

I assume that you did not choose to make the DN optional without reason. 
But is that really something that we would like to have? Are there 
really cases where we want to use a public key without explicitly 
knowing whom it belongs to? Isn't there a risk to spread confusion on 
what a "trust anchor" is?

Granted, this RFC could define a Trust Anchor in a more global scope, 
without a need to bind it to a DN, but I'm (very personally) not sure 
this is a great idea and I believe that mandating the presence of a DN 
would not bring a strong limitation.

Have you considered moving the taName from the CertPathControls to the 
main structure (TrustAnchorInfo) and keeping the CertPathControls 
structure for fine tuning of the X.509 input algorithm?

(And along the same lines, why is the KeyIdentifier mandatory and not 
optional?)

Regards,

--
Julien

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 4 Mar 2009 15:23:33 -0500

<snip>
> I believe that we should keep them integers to keep the full 
> generality (unless I missed a point).

The booleans align with the inputs to the path validation algorithm.
Ideally, those would have been integers too.
 
> On a more global note, I noticed some time ago that a 
> document from ETSI (namely ETSI 102 272) defined a fairly 
> similar (albeit simpler) structure. It dates from 2003, but 
> could provide some interesting bits.
>      acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, -- 
> If not present "any policy"
> AcceptablePolicySet ::= SEQUENCE OF CertPolicyId CertPolicyId 
> ::= OBJECT IDENTIFIER
> 
> I like the fact that the certificate is optional in the TA 
> draft, and that it can be defined as a pure DN/Public Key 
> pair. I've always thought the direct inclusion of a 
> self-signed certificate led to possible unclarities as 
> regards treatment of extensions. But anyway, always 

Thanks for the reference.

---

From: Russ Housley <[email-masked]>
Date: Wed, 04 Mar 2009 17:58:53 -0500

Julien:

X.509 did not originally include a definition of trust anchor.  RFC 
2459 follow this example, and it caused problems when describing 
certification path validation.  Since RFC 3280 added a lot of 
material on this topic, a definition was needed.  RFC 3280 includes:

    In section 6.1, the text describes basic path validation.  Valid
    paths begin with certificates issued by a trust anchor.  The
    algorithm requires the public key of the CA, the CA's name, and any
    constraints upon the set of paths which may be validated using this
    key.

I consider these constraints to be additional data.  The RFC 3280 
definition is saying what is needed in a trust anchor for the path 
validation algorithm.  Constraints are implemented through settings 
in the path validation algorithm.  However, I do not see anything in 
this text that says other policy information cannot be part of a 
trust anchor.  The text you quote includes validity period, and I 
consider this to be an example of such policy information.

RFC 2459, RFC 3280, and RFC 5280 have all required CA certificates to 
include a Distinguished Name.  This is important for constructing a 
certification path and for identifying a particular certificate in a CRL.

The taName is needed for certification path construction and 
validation.  I do not really care if it is placed in a separate 
OPTIONAL element of TrustAnchorInfo.  How would this change help you?

TAMP requires a key identifier.  This format was originally embedded 
in TAMP.  I guess this linkage remains.  I do point out that a key 
identifier could be computed from the public key using the technique 
described in RFC 5280, so this is not an onerous requirement.

Russ

At 01:43 PM 3/4/2009, Julien Stern wrote:

>I believe that the most common usage of the word "trust anchor" 
>denotes the _binding_ of a public key _and_ a name. A certificate 
>binds a name and a public key (along with other information) thanks 
>to a signature. A trust anchor binds them through direct trust.
>
>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.
>I assume that you did not choose to make the DN optional without 
>reason. But is that really something that we would like to have? Are 
>there really cases where we want to use a public key without 
>explicitly knowing whom it belongs to? Isn't there a risk to spread 
>confusion on what a "trust anchor" is?
>
>Granted, this RFC could define a Trust Anchor in a more global 
>scope, without a need to bind it to a DN, but I'm (very personally) 
>not sure this is a great idea and I believe that mandating the 
>presence of a DN would not bring a strong limitation.
>
>Have you considered moving the taName from the CertPathControls to 
>the main structure (TrustAnchorInfo) and keeping the 
>CertPathControls structure for fine tuning of the X.509 input algorithm?
>
>(And along the same lines, why is the KeyIdentifier mandatory and 
>not optional?)
>
>Regards,
>
>--
>Julien
>

---

From: Tom Gindin <[email-masked]>
Date: Wed, 4 Mar 2009 20:41:19 -0500

Julian:

        I think you're wrong in believing that the name is central to the 
definition of a trust anchor.  I can have (and my browser may be shipped 
with) several trust anchors issued by the same organization, and the names 
which distinguish them are (to me as the  manager of the trust store) 
quite arbitrary.  A typical example is that there are two separate CA 
certificates from Entrust with CN="Entrust.net Secure Server Certification 
Authority".  Their OU's are slightly different, and one of them has a 
Country attribute.
        While philosophically I completely disagree with you, RFC 5280 
section 6.1.1 point d-1 requires that the trust anchor have an issuer 
name, as does the same section in 3280.  Thus, no trust anchor definition 
which does not include an issuer name can be used by our own existing 
algorithms.  I think that's a pretty good reason for PKIX to require the 
presence of a DN in this definition.

                Tom Gindin

P.S. - These views are mine personally, and not necessarily those of my 
employer

Julien Stern <[email-masked]> 
Sent by: [email-masked]
03/04/2009 01:43 PM

To

cc
[email-masked]
Subject
Re: I-D Action:draft-ietf-pkix-ta-format-01.txt

Hi again,

Regards,

--
Julien

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 4 Mar 2009 21:16:25 -0500

May be two wrongs can make a right since if a name should be required in
a TA, it is the subject and not issuer name. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tom Gindin
> Sent: Wednesday, March 04, 2009 8:41 PM
> To: Julien Stern
> Cc: [email-masked]
> Subject: Re: I-D Action:draft-ietf-pkix-ta-format-01.txt
> 
> 
>         Julian:
> 
>         I think you're wrong in believing that the name is 
> central to the definition of a trust anchor.  I can have (and 
> my browser may be shipped
> with) several trust anchors issued by the same organization, 
> and the names which distinguish them are (to me as the  
> manager of the trust store) quite arbitrary.  A typical 
> example is that there are two separate CA certificates from 
> Entrust with CN="Entrust.net Secure Server Certification 
> Authority".  Their OU's are slightly different, and one of 
> them has a Country attribute.
>         While philosophically I completely disagree with you, 
> RFC 5280 section 6.1.1 point d-1 requires that the trust 
> anchor have an issuer name, as does the same section in 3280. 
>  Thus, no trust anchor definition which does not include an 
> issuer name can be used by our own existing algorithms.  I 
> think that's a pretty good reason for PKIX to require the 
> P.S. - These views are mine personally, and not necessarily 
> those of my employer
> 
> 
> 
>

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 4 Mar 2009 21:48:08 -0500

The draft notes that omission of the taName field precludes path
validation.  Given that TAs serve other purposes that don't require DNs,
making the field optional makes sense.  All three formats in the draft
support including a DN.  This allows the 5280 requirement to be
satisfied with each structure.

---

From: Julien Stern <[email-masked]>
Date: Thu, 05 Mar 2009 13:59:38 +0100

Tom,

you are having me slightly confused here. You say that a name is not 
central to the definition of a trust anchor, but you quote examples of 
trust anchors that includes names. Also, I fail to see any examples of 
trust anchors without names.

I think just as you do that PKIX should require the presence of a DN and 
I was wondering why this DN was not simply always mandatory. What is the 
use of a key not linked to an identity?

Regards,

--
Julien

---

From: Julien Stern <[email-masked]>
Date: Thu, 05 Mar 2009 13:55:11 +0100

Russ,

Comments in line.

Regards,

--
Julien

Russ Housley wrote:
> 
> Julien:
> 
> X.509 did not originally include a definition of trust anchor.  RFC 2459 
> follow this example, and it caused problems when describing 
> certification path validation.  Since RFC 3280 added a lot of material 
> on this topic, a definition was needed.  RFC 3280 includes:
> 
> validation algorithm.  Constraints are implemented through settings in 
> the path validation algorithm.  However, I do not see anything in this 
> text that says other policy information cannot be part of a trust 
> anchor.  The text you quote includes validity period, and I consider 
> this to be an example of such policy information.

I fully share your view that the "other policy information" should only 
be an optional part of the trust anchor. However, I feel that the name 
is a fundamental part of the trust anchor. A trust anchor without a 
name, in my opinion, would be like a certificate without a name.

> validation.  I do not really care if it is placed in a separate OPTIONAL 
> element of TrustAnchorInfo.  How would this change help you?

Well, again, I was wondering about moving the taName up one level, but 
to keep it mandatory not OPTIONAL. I mean, in which use cases would you 
need a key which is not linked to an identity?

> TAMP requires a key identifier.  This format was originally embedded in 
> TAMP.  I guess this linkage remains.  I do point out that a key 

OK. Fair enough. Thanks for the clarification.

>> binds a name and a public key (along with other information) thanks to 
>> a signature. A trust anchor binds them through direct trust.
>>
>> addition to the public key: algorithm identifier, public key

---

From: Julien Stern <[email-masked]>
Date: Thu, 05 Mar 2009 14:09:20 +0100

Carl,

well, there may be strong "philosophical" disagreements from yourself 
and/or Tom of what a trust anchor is (which is fine :) ), but could you 
give an example of an actual use of a trust anchor that do not require 
an identity?

Again, my humble personal view is that a PKI in general is before all 
used to link cryptographic key to identities. This can be done by direct 
trust (e.g. a trust anchor) or vouched by an other entity (e.g. a 
certificate). This is why I believe the identity is a fundamental part 
of a trust anchor. Now the fact that this identity should be a DN is not 
as fundamental (it could be a string), but considering the global 
context, a DN is really what makes senses.

I read the fact that omission of the taName precludes path validation 
(and I naturally concur), but I actually think that omission of that 
name precludes _any_ usage of the corresponding public key, and that 
therefore the DN should be made mandatory in all cases.

--
Julien

Carl Wallace wrote:
>> parameters

---

From: Julien Stern <[email-masked]>
Date: Thu, 05 Mar 2009 14:18:44 +0100

> Ideally, those would have been integers too.

Hmm... That a tricky point I think. I agree that the validation 
algorithm has currently described takes booleans.

However,
1) It is allowed to augment the algorithm (and that would be a 
worthwhile augmentation)
2) What are some existing algorithm doing?Iif the indicator is set to 
true, some will look at the extension in the trust anchor to initialize 
a value which will be an integer, and not a boolean anymore.

So, if we leave them as boolean in the trust anchor, we will prevent 
trust anchor from defining these values, especially considering that the 
RFC explicitly states that the extensions which contains these elements 
should be ignored.

--
Julien

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 5 Mar 2009 08:34:42 -0500

Inline...

> From: Julien Stern [mailto:[email-masked]] 
> Sent: Thursday, March 05, 2009 8:09 AM
> To: Carl Wallace
> Cc: Tom Gindin; [email-masked]
> well, there may be strong "philosophical" disagreements from 
> yourself and/or Tom of what a trust anchor is (which is fine 
> :) ), but could you give an example of an actual use of a 
> trust anchor that do not require an identity?

CMS does not use a DN to identify a signer.  Timestamps, firmware
packages and key packages are all examples of objects signed using CMS
that could be verified using a TA that is not named using a DN but
identified with a key identifier.  OCSP responses aren't signed using
CMS but can also identify a signer using a key identifier and may be
validated by a TA. 
 
> Again, my humble personal view is that a PKI in general is 
> before all used to link cryptographic key to identities. This 
> can be done by direct trust (e.g. a trust anchor) or vouched 
> by an other entity (e.g. a certificate). This is why I 
> believe the identity is a fundamental part of a trust anchor. 
> Now the fact that this identity should be a DN is not as 
> fundamental (it could be a string), but considering the 
> global context, a DN is really what makes senses.

You could choose to use a DN and/or a TA title in all TAs used in your
environment.
 
> I read the fact that omission of the taName precludes path 
> validation (and I naturally concur), but I actually think 
> that omission of that name precludes _any_ usage of the 
> corresponding public key, and that therefore the DN should be 
> made mandatory in all cases.

The DN is required by 5280 for name chaining.  A DN is not required in
all cases where a TA could be used (see above) so making it mandatory is
not desirable.
 
> >>> A New Internet-Draft is available from the on-line 
> Internet-Drafts 
> >> directories.
> >>> This draft is a work item of the Public-Key 
> Infrastructure (X.509) 
> >> Working Group of the IETF.
> >>>

---

From: Julien Stern <[email-masked]>
Date: Thu, 05 Mar 2009 16:09:35 +0100

Carl,

Thanks for your reply.
I'm starting to see some of the rationale better.

What still slightly bothers me is the following:

I keep on thinking it would bring major confusion to say that a trust 
anchor can be reduced to a public key. A trust anchor has to be an 
_identified_ public key, else it's just... well... a public key.

Now, I feel I'm starting to understand why the keyIdentifier is always 
mandatory. Maybe you meant to be using this key identifier as a generic 
"name" for the key? In which case, we do have a difference between a 
public key and a trust anchor, e.g. the key is "identified". However, 
this keyIdentifier is usually directly inferred from the public key, so 
this "identification" is a weak one at best.

The very beginning of the TA draft says: "A trust anchor is an 
authoritative entity represented by a public key and associated data."
The bare minimum currently allowed is the key and the keyIdentifier.

I fail to see how the authoritative entity comes into play here. In all 
the examples you gave below, we may possibly go through a keyIdentifier 
instead of a DN to find the public key used to signing, but it does not 
make sense to use this key if it is an "anonymous" key.

Maybe, an other way to highlight the difference in our views is that you 
assume the "identification" of the key can be performed by external 
means? In which case, a trust anchor could be a public key whose owner 
happens to be known by external means or be implicit from the context? 
And that I believe the identity of the "authoritative entity" should be 
explicitly stated in the TA?

Regards,

--
Julien

---

From: Russ Housley <[email-masked]>
Date: Thu, 05 Mar 2009 09:00:46 -0500

Julien:

>I fully share your view that the "other policy information" should 
>only be an optional part of the trust anchor. However, I feel that 
>the name is a fundamental part of the trust anchor. A trust anchor 
>without a name, in my opinion, would be like a certificate without a name.

I have no objection to the taName becoming a mandatory element of the 
structure.  It is certainly needed for certification path 
construction and validation.  However, in the TAMP context, there are 
messages that are signed directly by the trust anchor.  In this case, 
a key identifier without a name is sufficient.  This element is 
optional to allow for a trust anchor that is able to sign such 
messages but not allowed to sign certificates.  So, if the taName 
becomes non-optional, another mechanism is needed to indicate whether 
the trust anchor can sign certificates.

Russ

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 5 Mar 2009 10:46:10 -0500

Inline... 

> Sent: Thursday, March 05, 2009 10:10 AM
> To: Carl Wallace
> I keep on thinking it would bring major confusion to say that 
> a trust anchor can be reduced to a public key. A trust anchor 
> has to be an _identified_ public key, else it's just... 
> well... a public key.

A TA is a public key and some constraints on its usage.  As referenced
in this thread, a DN is just one form of constraint.
 
> Now, I feel I'm starting to understand why the keyIdentifier 
> is always mandatory. Maybe you meant to be using this key 
> identifier as a generic "name" for the key? In which case, we 
> do have a difference between a public key and a trust anchor, 
> e.g. the key is "identified". However, this keyIdentifier is 
> usually directly inferred from the public key, so this 
> "identification" is a weak one at best.
>
> The very beginning of the TA draft says: "A trust anchor is 
> an authoritative entity represented by a public key and 
> associated data."
> I fail to see how the authoritative entity comes into play 
> here. 

The authoritative entity associated with the TA comes into play by using
the private key.  

> In all the examples you gave below, we may possibly go 
> through a keyIdentifier instead of a DN to find the public 
> key used to signing, but it does not make sense to use this 
> key if it is an "anonymous" key.

Why?  That some signature schemes use a key identifier instead of a DN
to locate the public key isn't a problem.  Even 5280 uses key identifier
more than DN to find a key (where one CA has multiple certs).  The
important thing is that the TA was obtained in a secure manner.  

> Maybe, an other way to highlight the difference in our views 
> is that you assume the "identification" of the key can be 
> performed by external means? In which case, a trust anchor 
> could be a public key whose owner happens to be known by 
> external means or be implicit from the context? 
> And that I believe the identity of the "authoritative entity" 
> should be explicitly stated in the TA?

Trust in the key is established by external means, i.e., manual check or
TAMP message verification.  DNs are generally not small.  The taName is
optional to allow omission in situations where they are not used.  Why
should a name be required since not all uses require a name?   
 
> >> and/or Tom of what a trust anchor is (which is fine
> >> :) ), but could you give an example of an actual use of a trust 
> >> anchor that do not require an identity?
> > 
> before all 
> >> used to link cryptographic key to identities. This can be done by 
> >> direct trust (e.g. a trust anchor) or vouched by an other entity 
> >> (e.g. a certificate). This is why I believe the identity is a 
> >> fundamental part of a trust anchor.
> fundamental 
> >> (it could be a string), but considering the global 
> context, a DN is 
> validation 
> > all cases where a TA could be used (see above) so making it 
> mandatory 
> > is not desirable.
> >  
> >> --
> >> Julien
> >>
> >> Carl Wallace wrote:
> >>>>         I think you're wrong in believing that the name 
> is central 
> >>>> to the definition of a trust anchor.  I can have (and my browser 
> >>>> may be shipped
> >>>> with) several trust anchors issued by the same organization, and 
> >>>> the names which distinguish them are (to me as the 
> manager of the 
> >>>> trust store) quite arbitrary.  A typical example is that 
> there are 
> >>>> two separate CA certificates from Entrust with CN="Entrust.net 
> >>>> Secure Server Certification Authority".  Their OU's are slightly 
> >>>> different, and one of them has a Country attribute.
> >>>>         While philosophically I completely disagree with 
> you, RFC 
> >>>> 5280 section 6.1.1 point d-1 requires that the trust 
> anchor have an 
> >>>> issuer name, as does the same section in 3280.
> >>>>  Thus, no trust anchor definition which does not include 
> an issuer 
> >>>> name can be used by our own existing algorithms.  I 
> think that's a 
> >>>> pretty good reason for PKIX to require the presence of a 
> DN in this 
> >>>> definition.
> >>>>
> >>>>                 Tom Gindin
> >>>>
> >>>> P.S. - These views are mine personally, and not 
> necessarily those 
> >>>> of my employer
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Julien Stern <[email-masked]> Sent by: 
> >>>> [email-masked]
> >>>> 03/04/2009 01:43 PM
> >>>>
> >>>> To
> >>>>
> >>>> cc
> >>>> [email-masked]
> >>>> Subject
> >>>> This draft defines a trust anchor as a public key with 
> additional 
> >>>> data.
> >>>>
> >> 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.
> >>>> reason.
> >>>> this is a great idea and I believe that mandating the 
> presence of a

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 Mar 2009 08:29:42 -0800

At 4:09 PM +0100 3/5/09, Julien Stern wrote:
>I keep on thinking it would bring major confusion to say that a trust anchor can be reduced to a public key. A trust anchor has to be an _identified_ public key, else it's just... well... a public key.

A trust anchor is a public key and some policy information related to the key, namely what the relying party can use the trust anchor to validate. That policy information is not the same for all applications, so specifying a single structure for it would be meaningless: it would be an octet hole that is filled in application by application.

I support the current structure in the draft: it allows each application to specify its policy in a way that is appropriate for the application, yet gives an interoperable format for trust anchors that work well beyond typical PKIX uses.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Kent <[email-masked]>
Date: Thu, 5 Mar 2009 11:31:15 -0500

>to a signature. A trust anchor binds them through direct trust.

A PKC, especially a v3 PKC, contains a number of attributes, of which 
name is often viewed as the most important. But not all PKIs view the 
subject name as the most important attribute, e.g., in the RPKI 
developed in the SIDR WG, the RFC 3779 extension are arguably the 
most important attributes. We have adopted this TA format for that 
work. So I think the current wording is appropriate.

In large part, motivation for not requiring a (subject) DN arises 
because of the intent to use this TA representation in the context of 
device management, where a key (but not a self-signed cert) makes 
sense.

Steve

---

From: Julien Stern <[email-masked]>
Date: Thu, 05 Mar 2009 17:44:54 +0100

Russ Housley wrote:
>> only be an optional part of the trust anchor. However, I feel that the 
>> name is a fundamental part of the trust anchor. A trust anchor without 
>> a name, in my opinion, would be like a certificate without a name.
> 
> structure.  It is certainly needed for certification path construction 
> and validation.  However, in the TAMP context, there are messages that 
> are signed directly by the trust anchor.  In this case, a key identifier 
> without a name is sufficient.  This element is optional to allow for a 
> trust anchor that is able to sign such messages but not allowed to sign 
> certificates.  So, if the taName becomes non-optional, another mechanism 
> is needed to indicate whether the trust anchor can sign certificates.

Russ,

As explained into more details in my reply to Carl, my understanding 
from the draft was;

1) the identity of the private key owner is optional
2) the taName can optionally be used to identity him in a X.500 context

I am in disagreement with 1). I still think that a TA without a name 
(whichever its form, DN or not) would be like a certificate without a 
name. However, I seem to be the only one, so I'll stop.

Now, from what you say, I understand that if I put a DN, it will _also_ 
mean that this TA can be used for X.509 validation.

Isn't it a limitation to combine the identification of the owner with a 
DN and the authorization to perform X.509 validation with this TA?

Regards,

--
Julien

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 5 Mar 2009 11:47:21 -0500

<snip>
> To sum things up:
> 
> 1) It still believe that mandating the inclusion of the 
> identity of the 
> private key owner in one way or an other (possibly not a DN) 
> would be nice.
> 2) If everyone thinks that this identity can be omitted if 
> implicit from 
> the context, well, fine. A short paragraph explaining that 
> could be nice.

Adding a paragraph to clarify this seems reasonable to me.

> 3) Providing a way to provide this identity (possibly under various 
> forms: string, DN, etc) _without_ necessarily linking the presence of 
> the DN to the fact that this TA can be used for X.509 
> validation would 
> certainly also be nice.

There are two means of implementing this with the current spec.  The
taTitle field can identify the TA using a string value.  A
subjectAltName extension could be included with any form of GeneralName.
Neither of these would enable path validation.

---

From: Julien Stern <[email-masked]>
Date: Thu, 05 Mar 2009 18:01:29 +0100

> taTitle field can identify the TA using a string value.

True. But if I do want to put a DN in there, I will bump into all the 
infamous Printable/BMP/UTF-8/etc encoding issues :)

 > A subjectAltName extension could be included with any form of 
GeneralName.
> Neither of these would enable path validation.

Also true, but no-one else will understand this extension as no standard 
extension are defined in the draft. It will likely be mostly a "private" 
extension.

---

From: Eric Norman <[email-masked]>
Date: Thu, 05 Mar 2009 11:05:44 -0600

> should a name be required since not all uses require a name?

Why not make a clear distinction between usage and inclusion?  If
information like a DN MUST be included in some structure, I don't
see why that implies that it MUST be used.  The part of the standard
that specifies usage can say that such information MUST or MAY be
ignored.

It seems to me that failing to make a clear distinction is getting
dangerously close to creating a situation where a creator of a
trust anchor will be required to prepare different structures
depending on usage.  I.e. there will be more structures flying
around.  Is this really a situation that y'all want?  Won't this
just lead to more confusion and more interoperability problems?

Personally, I don't see why trust anchors can't be specified with
the same format as X.509 certificates along with the proviso that
some components (like issuer, serial number, etc) may be ignored
in the validation algorithm.

Eric Norman

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 5 Mar 2009 12:05:38 -0500

> True. But if I do want to put a DN in there, I will bump into 
> all the infamous Printable/BMP/UTF-8/etc encoding issues :)
> 
>  > A subjectAltName extension could be included with any form 
> of GeneralName.

This can be clarified in the draft.

---

From: Julien Stern <[email-masked]>
Date: Thu, 05 Mar 2009 17:32:01 +0100

Inline...

Carl,

While I do agree with a lot of what you say, I just cannot agree with 
this :) A TA is not just a public key possibly with constraints of 
usage. A public key can be "promoted" to a TA if you KNOWN and TRUST the 
entity controlling the corresponding public key. Now this "promotion" 
can be explicit (you click on something) or implicit (you receive some 
hardware device with the manufacturer key embedded). But whether 
implicit or explicit, the fact you known the identity of the private key 
owner (and that you trust it) is what differentiates a public key from a TA.

If you do not believe that the identity of the private key owner is a 
fundamental part of a TA, then we have a strong disagreement.

Otherwise, we probably only have a very minor disagreement.
- You say that this identity can be omitted from the TA information and 
can be inferred by external means
- I felt that this identity was such a fundamental aspect that it needed 
to be an integral part of the TA information

No big deal, in fact :)

And well, I agree that it you receive a hardware device with an embedded 
public key, the identity of the private key owner (the hardware 
manufacturer most likely) can be implicitly inferred... On the other 
hand, it does not cost so much to embed it.

At any rate, if there is a consensus that this identity can be omitted 
and implicit, let us stop the thread on this aspect.

Now, as regards the DN:
I originally understood it was _the_ way to identity the private key 
owner and that it was optional. Apparently, it serves a dual-purpose:
1) to identify the private key owner
2) to indicate the public key can be used for X.509 validation

One may view this as a limitation: I cannot state the identity of the 
key owner using a DN unless I want to use the public key for X.509 
validation.

To sum things up:

1) It still believe that mandating the inclusion of the identity of the 
private key owner in one way or an other (possibly not a DN) would be nice.
2) If everyone thinks that this identity can be omitted if implicit from 
the context, well, fine. A short paragraph explaining that could be nice.
3) Providing a way to provide this identity (possibly under various 
forms: string, DN, etc) _without_ necessarily linking the presence of 
the DN to the fact that this TA can be used for X.509 validation would 
certainly also be nice.

Regards,

--
Julien

---

From: "Denis Pinkas"<[email-masked]>
Date: Fri, 6 Mar 2009 10:48:04 +0100

Yesterday, I have seen an avalanche of e-mails on this draft.

The main issue is that this document has two different goals which should be clearly advertised in the abstract:

It provides the controls needed to :

a) initialize an X.509 certification path validation algorithm implementation, and to 
b) verify digital signatures in contexts where X.509 certificates are NOT used.

The draft makes circumvolutions to address both cases. Quoted text:
"If the certificate is present, the subject name in the certificate MUST exactly match the X.500 distinguished name provided in the taName field, the public key MUST exactly match the public key in the pubKey field and the subjectKeyIdentifier extension, if present, MUST exactly match the key identifier in the keyId field". 
It would be simpler and clearer to separate both cases and to have a CHOICE between two simple structures from the very beginning.

Basically, I support Julien's view, saying that the name of the taTitle should be mandatory. However, it is only needed for case b).
When deciding to place a TA in a store, a human being may need to make a decision.
Currenty the keyId is only an octet string. This does not allow a human being to know to who the key belongs to.
On the contrary, taTitle is an UTF8String that can be easily displayed.

Besides these points, I would like to mention some other concerns on this draft.

1 - The draft states: "Though widely used, there is no standard format for representing trust anchor information".
This is untrue. Self-signed certificates are currently widely used to represent TAs. It may simply be argued that 
other forms ("more compact" as indicated) are also needed.

2 - For case a), a structure containing the hash of a self-signed certificate should also be considered. 
This would diminish the size of the foot-print.

3 - For case b, the validity period of the TA is a fundamental information. 
The current structure does not allow to support it. It should. 

Denis
  
----- Message reçu ----- 
De : owner-ietf-pkix 
À : i-d-announce 
Date : 2009-03-04, 17:15:02
Sujet : I-D Action:draft-ietf-pkix-ta-format-01.txt

Pièce(s) Jointe(s) au message original :
  (1). draft-ietf-pkix-ta-format-01.txt

---

From: "Carl Wallace" <[email-masked]>
Date: Fri, 6 Mar 2009 10:38:13 -0500

> Hmm... That a tricky point I think. I agree that the 
> validation algorithm has currently described takes booleans.
> 
> However,
> 1) It is allowed to augment the algorithm (and that would be 
> a worthwhile augmentation)
> 2) What are some existing algorithm doing?Iif the indicator 
> is set to true, some will look at the extension in the trust 
> anchor to initialize a value which will be an integer, and 
> not a boolean anymore.
> 
> So, if we leave them as boolean in the trust anchor, we will 
> prevent trust anchor from defining these values, especially 
> considering that the RFC explicitly states that the 
> extensions which contains these elements should be ignored.

Even if the algorithm were augmented, we'd need to describe how to use
the existing inputs.  Two possible options are:

	- Require the values to be 0.  This would have the effect of
setting the corresponding validation input flag to true.  Processing
would fail if the extension is present and the value is not zero.  
	- Turn on the corresponding validation input flag given any
SkipCerts value (i.e., presence of a field or extension corresponding to
a validation input flag causes the flag to be set to true and absence
causes the flag to be set to false).

The first option would also disallow using arbitrary CA certificates as
a trust anchor if the certificate contains a SkipCerts > 0.  Though it
could be used if the certificate were wrapped in a TrustAnchorInfo or
just the TBSCertificate structure were used.  I prefer the second
option.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 Mar 2009 08:44:34 -0800

>other forms ("more compact" as indicated) are also needed.

Self-signed certs are widely used for representing the trust anchor keys, but not the rest of the information, such as what chains those keys can be used for. The latter is much more interesting than the former.

--Paul Hoffman, Director
--VPN Consortium

---

From: Julien Stern <[email-masked]>
Date: Fri, 06 Mar 2009 17:49:47 +0100

Carl,

I agree. And indeed 5280 defines these flags as OPTIONAL, when taken 
from the certificate extension.

id-ce-policyConstraints OBJECT IDENTIFIER ::=  { id-ce 36 }

So, if we were to replace the booleans by integers, it would indeed be 
needed to make them OPTIONAL, and to set the value of the input flag to 
false if they are absent and true otherwise.

Regards,

--
Julien

---

From: Eric Norman <[email-masked]>
Date: Fri, 06 Mar 2009 13:44:55 -0600

On Mar 6, 2009, at 3:48 AM, Denis Pinkas wrote:

> 1 - The draft states: "Though widely used, there is no standard format 
> for representing trust anchor information".
> This is untrue. Self-signed certificates are currently widely used to 
> represent TAs. It may simply be argued that

Indeed, representation as self-signed certificates is almost universal.
What I would like to point out, and what I think documentation should
make clear, is that the "self-signed" part is not a requirement to be
a trust anchor.  The ultimate decision about "trust" lies with the
relying party, and I see no reason why a relying party should be denied
the ability to use any public key they chose as a trust anchor, even
if that public key is contained in a certificate that is not 
self-signed.
This is not a syntactic thing.  In my mind it just a clarification of
what often seems to be confusion between "must be represented" and "must
be used".

And on another topic.  Has the need for "more compact" been justified?
Really?  If someone seriously thinks there is a need for more 
compactness
nowadays, shouldn't they be talking to those XML folks?

Eric Norman

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 6 Mar 2009 15:17:47 -0500

There are environments where the device may be space challenged and/or the communication environment may be bandwidth challenged.

Thus, having only the required information in trust anchors and TAMP will be helpful.

> [mailto:[email-masked]] On Behalf Of Eric Norman
> Sent: Friday, March 06, 2009 2:45 PM
> To: ietf-pkix
> > represent TAs. It may simply be argued that other forms ("more 
> > compact" as indicated) are also needed.
> 
> What I would like to point out, and what I think 
> documentation should make clear, is that the "self-signed" 
> part is not a requirement to be a trust anchor.  The ultimate 
> decision about "trust" lies with the relying party, and I see 
> no reason why a relying party should be denied the ability to 
> use any public key they chose as a trust anchor, even if that 
> public key is contained in a certificate that is not self-signed.
> This is not a syntactic thing.  In my mind it just a 
> clarification of what often seems to be confusion between 
> "must be represented" and "must be used".
> 
> compactness nowadays, shouldn't they be talking to those XML folks?
> 
> Eric Norman
> 
>

---

From: Eric Norman <[email-masked]>
Date: Fri, 06 Mar 2009 14:59:10 -0600

On Mar 6, 2009, at 2:17 PM, Santosh Chokhani wrote:

>
> There are environments where the device may be space challenged and/or 
> the communication environment may be bandwidth challenged.
>

Really?  How many bytes can be stored on a ESB memory stick nowadays?
How many bits can be stored in one square millimeter nowadays?  How
much time does it take to transfer a few thousand bytes with USB or
Bluetooth nowadays?  Are you seriously suggesting that we need to
design for folks whose environment includes carrier pigeons or tin
cans and string as their communication mechanism?

TAMP may indeed be useful, but not in the area of saving resources.
Where it can be useful is to make it clearer which information is
necessary and which information can be ignored for something to be
a trust anchor and under what circumstances.

Eric Norman

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 7 Mar 2009 19:24:00 -0500

If making name optional meets the requirements of multiple environment,
then it is a better standard than making it mandatory.

As to memory challenged, I encourage you to speak with some real
implementers as they move their hardware tokens from 1024 bits to 2048
bits RSA.  They do need bigger and costlier cards.  So, memory in all
form factors is not free.

> Sent: Friday, March 06, 2009 3:59 PM
> To: ietf-pkix
> > Thus, having only the required information in trust anchors 
> and TAMP 
> > will be helpful.
> 
> How many bits can be stored in one square millimeter 
> nowadays?  How much time does it take to transfer a few 
> thousand bytes with USB or Bluetooth nowadays?  Are you 
> seriously suggesting that we need to design for folks whose 
> environment includes carrier pigeons or tin cans and string 
> as their communication mechanism?
> 
> Where it can be useful is to make it clearer which 
> information is necessary and which information can be ignored 
> for something to be a trust anchor and under what circumstances.
> 
> Eric Norman
> 
>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 11 Mar 2009 20:08:09 +0100

On the name issue I don't think names need to be mandatory.

If we for a second set aside what is right and pure and standards compliant
and stick to what is needed from a pure cryptographic and security
viewpoint, then there is no need for exact name matching in X.509 path
validation.

Long before UTF-8, name mismatch of Issuer/subject names in path processing
was a real problem. Some for example used T.61 Teletex to tag a string
carrying Latin-1 characters.

What many implementers did, including Microsoft, in order to be "liberal in
what you accept" was to ignore name mismatch as long as keys of the path
matched (could be used to validate certificates in the path). There was no
security problem with it and it worked a lot better.

So basically, I'm also fine with an optional DN.

/Stefan