Subject: [pkix] WGLC for TAMP

From: Stephen Kent <[email-masked]>
Date: Tue, 6 Oct 2009 07:08:09 -0400

Carl has requested that we initiate a WGLC for of 03 version of TAMP. 
The LC starts today (10/5) and will end in two weeks, on 10/19.

Thanks,

Steve

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 8 Oct 2009 16:30:23 +0200

Comments on draft-ietf-pkix-tamp-03

1. The wording trust anchor is used to specify in some places ”Trust Anchor 
information” and in some other places “Trust Anchor Authority”.

A distinction between these two concepts should be made through the entire 
document. Note that these two wordings are undefined, but should be defined.

2. The wording “trust anchor store” is being used but is left undefined. 
Generally, trust anchor information is used by validation policies or by 
signature policies. It is thus used for a given purpose and additional 
conditions apply for its use. In the current draft, the use to be done with 
the trust anchor information is left undefined. If the store could only contain 
a single trust anchor information, then this would not be a problem since one 
could say that the use and the other constraints that apply are locally defined. 
However, several trust anchor information may co-exist within the cryptographic 
module. They may or may not have the same use. In the latter case, an implicit 
or explicit means to identify its use is needed, but is currently missing. 

3. The text states: “All trust anchors are distinguished by the public key”. 
This means that it is impossible to have within a cryptographic module two 
“trust anchor information” with the same public key that would serve 
independently two different purposes.

4. The text states: 

All trust anchors [information] consist of the following components:

   o  A public key signature algorithm identifier and associated public
      key, which MAY include parameters

   o  A public key identifier.

The text states: 

   The public key is used to name a trust anchor, and the public key
   identifier is used to identify the trust anchor as a signer of a
   particular object.

In this model, since the public key may change, it would be more appropriate 
to say:

   The public key is used to locate a trust anchor information in 
   a trust anchor store.

The second sentence about the public key identifier is unclear. What is the 
“trust anchor as a signer of a particular object” ? Is it supposed to carry 
the name of a trust anchor authority ? 

Later on (see below) keyId is defined as "the public key identifier of 
the trust anchor public key".

Please clarify what is is supposed to be.

5. The text also states: 

   The fields of TrustAnchorChangeInfo are used as follows:

   o  pubKey contains the algorithm identifier and the public key of the
      management or identity trust anchor.  It is used to locate the to-
      be-updated trust anchor in the trust anchor store.

   o  keyId is OPTIONAL, and when present, it contains the public key
      identifier of the trust anchor public key.  If this field is not
      present, then the public key identifier remains unchanged.  If
      this field is present, the provided public key identifier replaces
      the previous one.

It means that an update of a trust anchor information is impossible if the 
current value of the public key from trust anchor information is unknown.
This may lead to have storage that cannot be re-used.

It should also be observed that only updates of trust anchor information are 
supported (see page 21), which means that setting a new trust anchor information 
is not supported. This implies that the cryptographic module must be locally 
loaded and only further updates are supported.

These restrictions should be advertised in the abstract section, since this is 
only a subset of the regular management functions that are usually expected.

6. After one or more updates, the public key and/or the keyid from a trust anchor 
information have changed and it may be rather difficult for a manager to know 
what kind of usage will apply for that a trust anchor information. This 
implicitly means that the cryptographic modules should be managed by a single 
entity; otherwise synchronization between two different management entities might 
be difficult. 

7. Suggestions. As the header indicates, the following are only suggestions for 
changes which might solve the above concerns. In order to keep things simple, 
trust anchor information should be stored in fixed locations. For example: 
location: 1, 22 or location 20, 12. The use of a structure similar to an OID 
that would have a local hierarchical interpretation could be considered: 
e.g. 1.2.3.1. Locally the cryptographic module could know that locations 1, X 
contain trust anchor information to validate CA chains, while locations 2, X 
contain trust anchor information to validate AA chains and locations 5, X 
contain trust anchor information to validate TSTs. Additional constraints could 
also be applied for each location. It would be possible to set up trust anchor 
information remotely (besides the apex trust anchor information the module would 
be empty) and no need to synchronize between different cryptographic module 
managers would be needed.

Denis

--------- 
>From : pkix-bounces 
To : pkix 
Date : 2009-10-06, 13:08:09
Subject : [pkix] WGLC for TAMP

Thanks,

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

---

From: "Carl Wallace" <[email-masked]>
Date: Tue, 13 Oct 2009 07:59:41 -0400

Responses inline...

From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Thursday, October 08, 2009 10:30 AM
To: pkix
Subject: Re: [pkix] WGLC for TAMP

1. The wording trust anchor is used to specify in some places "Trust Anchor 
information" and in some other places "Trust Anchor Authority".

[CW] I will review the draft and try to clarify where a structure is referenced vs. the entity associated with the structure to make sure there is no ambiguity.  Erik Anderson's draft should be useful in this effort.

2. The wording "trust anchor store" is being used but is left undefined. 

[CW] Section 1.3.2 summarizes the capabilities a trust anchor store must have.  I will incorporate the definition from the TAM requirements draft, either by reference or copy and paste.

[CW] Usage is expressed on a per-trust anchor basis, not on a per trust anchor store basis.  Section 1.3.4 discusses usage of constraints by applications.

3. The text states: "All trust anchors are distinguished by the public key". 
This means that it is impossible to have within a cryptographic module two 
"trust anchor information" with the same public key that would serve 
independently two different purposes.

[CW] Correct.  I will add a statement to section 1.3.2 to clarify that a public key may appear at most one time in a given trust anchor store.

4. The text states: 

The text states: 

   The public key is used to locate a trust anchor information in 
   a trust anchor store.
The second sentence about the public key identifier is unclear. What is the 
"trust anchor as a signer of a particular object" ? Is it supposed to carry 
the name of a trust anchor authority ? 

[CW] The public key cannot be changed.  In an update message, the public key is used to identify the trust anchor to update and other fields can be changed.  The public key value cannot be changed via an update message.  The use of the public key identifier to identify the signer of an object is similar to authorityKeyIdentifier in a certificate or SignerInfo in a SignedData object.  These could be given as examples here to clarify the intent.

[CW] I will add ", which is contained in the pubKey field" to the end of the sentence.

5. The text also states: 

[CW] The value can be retrieved using a status query.

[CW] New trust anchor information can be added using the add field of TrustAnchorUpdate.

[CW] Status query messages provide a means of synchronization.  Verbose response messages to an update provide an opportunity for review to ensure the post-update state is as expected.

[CW] This seems like an implementation possibility to me, not something that needs to be expressed in the spec.

Denis

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 22 Oct 2009 11:42:32 +0200

Carl,

Responses are also in line.

----- Message reçu ----- 
De : Carl Wallace 
À : denis.pinkas,pkix 
Date : 2009-10-13, 13:59:41
Sujet : RE: [pkix] WGLC for TAMP

Responses inline...

[DP] Since I also participate to the discussion with Erik, I made the following proposal:
trust anchor authority: An authority that may be trusted by relying parties as a root CA.
trust anchor information: information used for validating certificates in certification paths which consists at least of 
the distinguished name of the trust anchor, a validity period, an algorithm identifier, a public key, public key parameters (if applicable) 
and any constrains on its use. 
2. The wording "trust anchor store" is being used but is left undefined. 

[CW] Section 1.3.2 summarizes the capabilities a trust anchor store must have.  I will incorporate the definition from the TAM requirements draft, either by reference or copy and paste.
[DP] The current text in TAM requirements is:
Trust Anchor Store:   A trust anchor store is a set of one or more
      trust anchors stored in a device.  A trust anchor store may be
      managed by one or more trust anchor managers.  A device may have
      more than one trust anchor store, each of which may be used by one
      or more applications.
If we make the distinction between TAA and TAI, then it will become:
Trust Anchor Store:   A trust anchor store is a set of one or more
      trust anchors information stored in a device.  A trust anchor store may be
      managed by one or more trust anchor managers.  A device may have
      more than one trust anchor store, each of which may be used by one
      or more applications.
Generally, trust anchor information is used by validation policies or by 
signature policies. It is thus used for a given purpose and additional 
conditions apply for its use. In the current draft, the use to be done with 
the trust anchor information is left undefined. If the store could only contain 
a single trust anchor information, then this would not be a problem since one 
could say that the use and the other constraints that apply are locally defined. 
However, several trust anchor information may co-exist within the cryptographic 
module. They may or may not have the same use. In the latter case, an implicit 
or explicit means to identify its use is needed, but is currently missing. 

[CW] Usage is expressed on a per-trust anchor basis, not on a per trust anchor store basis.  Section 1.3.4 discusses usage of constraints by applications.
[DP] I still wonder whether the usage is on a per-trust anchor basis or on a per-trust anchor store basis.
If the public key value from a root CA is being used with different conditions for three different purposes 
(e.g. TLS server, TLS client and S/MIME) I do not see how this is possible with the current model 
if there is only one trust anchor store.
Even, if this would be possible, I would expect that thrre different managers would manage the conditions that apply 
to TLS server, TLS client and S/MIME. I do not see how this is possible with the current model. 

[CW] Correct.  I will add a statement to section 1.3.2 to clarify that a public key may appear at most one time in a given trust anchor store.
[DP] This would be an important restriction. Rather than adding such a statement, 
I would prefer a model where this restriction does not exist anymore. 
This means that the trust anchor information SHOULD NOT be addressed using the value of the public key.
I made a proposal in my previous comment 7. This would be one way to solve my concern. There may be other ways.
4. The text states: 

The text states: 

[CW] The public key cannot be changed.  In an update message, the public key is used to identify the trust anchor to update and other fields can be changed.  The public key value cannot be changed via an update message. The use of the public key identifier to identify the signer of an object is similar to authorityKeyIdentifier in a certificate or SignerInfo in a SignedData object. These could be given as examples here to clarify the intent. 
[DP] You said: "The public key cannot be changed". I am confused. Using a "remove" command followed by 
an "add" command (see pages 30 and 31), the public key can be changed.  The change command 
(from TrustAnchorUpdate) also allows to change the public key value.  
The main problem is still that there is no means to indicate which use should be done with each TAI.
Later on (see below) keyId is defined as "the public key identifier of 
the trust anchor public key".

[CW] I will add ", which is contained in the pubKey field" to the end of the sentence.
[DP] I would rather think that the right explanation would be: "the public key identifier of 
the trust anchor public key, as assigned by the trust anchor authority"
5. The text also states: 

[DP]. This is fine. 

[CW] New trust anchor information can be added using the add field of TrustAnchorUpdate.
[DP]. However, a location for placing this TAI should be added. At this time, the location is implicitly obtained 
through the value of the public key which is too restrictive. 

[CW] Status query messages provide a means of synchronization.  Verbose response messages to an update provide an opportunity for review to ensure the post-update state is as expected.
[DP] This does not solve my concern. This means of synchoronization is insufficient. 
This topic still relates to the way to point to a trust anchor information and to understand its use.
Trust anchor information SHOULD NOT be addressed using the value of the public key.

[CW] This seems like an implementation possibility to me, not something that needs to be expressed in the spec.
[DP] I do not see how it would be possible to support such an implementation with the current protocol.

Denis

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 22 Oct 2009 06:58:05 -0400

Responses below...

From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Thursday, October 22, 2009 5:43 AM
To: pkix
Subject: Re: [pkix] WGLC for TAMP

Carl,

	----- Message reçu ----- 

	De : Carl Wallace 

	À : denis.pinkas,pkix 

	Responses inline...
	
	From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Denis Pinkas
	Sent: Thursday, October 08, 2009 10:30 AM
	To: pkix
	Subject: Re: [pkix] WGLC for TAMP

	

[CW] I don't think we need new definitions.  With no changes, the context generally enables the reader to make the necessary distinction.  With some minor edits we can avoid ambiguity.  I have a revised version with the changes I noted in my first reply to you that I hope to submit before the deadline.

[CW] See above.

[CW] Different constraints could be achieved using a different trust anchor store for each application that required unique settings or by using a shared trust anchor store with application-specific path validation inputs.  One or more managers could set the constraints on a trust anchor in either case.  The entity responsible for setting application path validation inputs (i.e., possibly a browser user) need have no TA management privileges.  For example, a web browser and mail client could share a trust anchor store with Trust Anchor A allowed to issue certificates in the namespace o=Example Organization.  The mail client could operate with settings that further restrict the namespace to ou=People, o=Example Organization.  

[CW] The concept is not new.  Adding the statement to the front was simply a clarification.    

	4. The text states: 

	
	
	The text states: 

	

[CW] A public key can be removed.  A public key can be added.  We can view that as changing the public key.  A public key cannot be changed in place using a change command.  For change messages, the public key is used to locate the trust anchor (see page 32).  

You can indicate which use should be done with each TAI using CertPathControls and extensions.

	

[CW] "As assigned by the trust anchor authority" would hold for all of the fields.  I don't see any reason to state this here.

<snip> 

 [CW] The draft uses a public key to locate a trust anchor for TAMP purposes only.  This does not mean one needs the public key to find the trust anchor for usage.   The TA can be found using name, key identifier or any other retrieval means (i.e., usage, policy, etc.) an implementation allows.  We don't need a variety of handles for management purposes and the public key seems like the right value to use for this purpose to me.

	

[CW] See above.  

[CW] Will you be in Hiroshima?  I would be happy to give you a demonstration.

	Denis

---

From: Russ Housley <[email-masked]>
Date: Thu, 22 Oct 2009 10:24:56 -0400

Denis:

1. The wording trust anchor is used to specify in some places
"Trust Anchor

information" and in some other places "Trust Anchor
Authority".

A distinction between these two concepts should be made through the
entire

document. Note that these two wordings are undefined, but should be
defined.

[CW] I will review the draft and try to clarify where a structure is
referenced vs. the entity associated with the structure to make sure
there is no ambiguity. Erik Anderson's draft should be useful in this
effort.

[DP] Since I also participate to the discussion with Erik, I made
the following proposal:

trust anchor authority: An authority that may be
trusted by relying parties as a root CA.

trust anchor information: information used for
validating certificates in certification paths which consists at least of

the distinguished name of the trust anchor, a validity period, an
algorithm identifier, a public key, public key parameters (if applicable)

I personally do not accept that there is a problem here.  I have
looked at RFC 5280, and I do not find any use of "trust anchor"
to be ambiguous or confusing.  The information that mus be
distributed to the replying party to represent the trust anchor that you
list is misleading.  For example, the validity period is useful in
some situation, but it is certainly not required. When specifying the
TrustAnchorInfo, we thought about which things are required and which are
optional.  When optional elements are included, they directly impact
the path validation algorithm.

Russ

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 23 Oct 2009 11:00:45 +0200

I am posting this message both on PKIX and the X.500 lists separately.

The issue on trust anchor vs. trust anchor authority is primarily an PKIX
issue. X.509 treats the subject quite causally and need to be reconsidered
from scratch.

It appears to be that the term trust anchor is primarily used as an entity
in current finalized PKIX specification. It would be less disruptive, if the
term "trust anchor" is used for the entity rather than "trust anchor
authority".

Anyway, I do not feel strongly about it, but I do feel strongly that terms
should be used in a consistent way.   

Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

e-amail: [email-masked]

Skype: andersen-erik

http://www.x500.eu/

http://www.x500standard.com/

From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ
Housley
Sent: 22. oktober 2009 16:25
To: [email-masked]; pkix
Subject: [Spam] Re: [pkix] WGLC for TAMP

Denis:

[CW] I will review the draft and try to clarify where a structure is
referenced vs. the entity associated with the structure to make sure there
is no ambiguity. Erik Anderson's draft should be useful in this effort.

[DP] Since I also participate to the discussion with Erik, I made the
following proposal:

trust anchor authority: An authority that may be trusted by relying parties
as a root CA.
trust anchor information: information used for validating certificates in
certification paths which consists at least of 
the distinguished name of the trust anchor, a validity period, an algorithm
identifier, a public key, public key parameters (if applicable) 
and any constrains on its use. 

I personally do not accept that there is a problem here.  I have looked at
RFC 5280, and I do not find any use of "trust anchor" to be ambiguous or
confusing.  The information that mus be distributed to the replying party to
represent the trust anchor that you list is misleading.  For example, the
validity period is useful in some situation, but it is certainly not
required. When specifying the TrustAnchorInfo, we thought about which things
are required and which are optional.  When optional elements are included,
they directly impact the path validation algorithm.

Russ

---

From: "Denis Pinkas"<[email-masked]>
Date: Fri, 23 Oct 2009 14:16:20 +0200

Russ,

tamp-03 states on page 20:
TrustAnchorInfo is intended to serve as a minimalist representation of trust anchor information for scenarios where storage or bandwidth is highly constrained.
taf-04 defines it as:
   TrustAnchorInfo ::= SEQUENCE {      version   TrustAnchorInfoVersion DEFAULT v1,      pubKey    SubjectPublicKeyInfo,      keyId     KeyIdentifier,      taTitle   TrustAnchorTitle OPTIONAL,      certPath  CertPathControls OPTIONAL,      exts      [1] EXPLICIT Extensions   OPTIONAL,      taTitleLangTag   [2] UTF8String OPTIONAL }
with:
    CertPathControls ::= SEQUENCE {      taName           Name,      certificate      [0] Certificate OPTIONAL,      policySet        [1] CertificatePolicies OPTIONAL,      policyFlags      [2] CertPolicyFlags OPTIONAL,      nameConstr       [3] NameConstraints OPTIONAL,      pathLenConstraint[4] INTEGER (0..MAX) OPTIONAL}
I do not consider it as a "minimalist representation", since it can be much largeur than 
Certificate orTBSCertificate.

After some discussion on the X.500 list, several people considered than it was necessary 
to always include a validity period.

So I will suggest, in any case, to add a validity field to the current structure. 
We can discuss whether this field should be mandatory or OPTIONAL. 

Note that tamp-04 supports a protocol to change the validity period (see page 30, field TBSCertificateChangeInfo).

See my other message to Carl about TAMP-03 for a proposal for changing both 
TrustAnchorInfo and CertPathControls (for other reasons).

Denis

----- Message reçu ----- 
De : Russ Housley 
À : denis.pinkas,pkix 
Date : 2009-10-22, 16:24:56
Sujet : Re: [pkix] WGLC for TAMP

Denis:

I personally do not accept that there is a problem here.  I have looked at RFC 5280, and I do not find any use of "trust anchor" to be ambiguous or confusing.  The information that mus be distributed to the replying party to represent the trust anchor that you list is misleading.  For example, the validity period is useful in some situation, but it is certainly not required. When specifying the TrustAnchorInfo, we thought about which things are required and which are optional.  When optional elements are included, they directly impact the path validation algorithm.

Russ

---

From: "Denis Pinkas"<[email-masked]>
Date: Fri, 23 Oct 2009 14:21:33 +0200

Carl,

Your answers do not solve my concerns.
This e-mail contains detailed proposals to solve my concerns.

Look for [DP2] in the text below.

While reading again the document, I found section 4.3.1. talking about TrustAnchorList.
However, I could not relate it to the rest of the document since this structure is not used in TAMP.
Would you be able to clarify ? 

The security consideration section should also mention that since revocation checking of SIGNED requests is not required,
(e.g. see page 23) there are dangers with such an approach. They should be mentionned.

----- Message reçu ----- 
De : Carl Wallace 
À : denis.pinkas,pkix 
Date : 2009-10-22, 12:58:05
Sujet : RE: [pkix] WGLC for TAMP

Responses below…
----- Message reçu ----- 
De : Carl Wallace 
À : denis.pinkas,pkix 
Date : 2009-10-13, 13:59:41
Sujet : RE: [pkix] WGLC for TAMP
Responses inline...

[CW] I don’t think we need new definitions.  With no changes, the context generally enables the reader to make the necessary distinction.  With some minor edits we can avoid ambiguity.  I have a revised version with the changes I noted in my first reply to you that I hope to submit before the deadline.

[DP2] I still think that definitions are needed and that the text needs to be clarified.
2. The wording "trust anchor store" is being used but is left undefined. 

[DP2] I still think the definition should be fixed. 

[DP2] Only constraints can be added on a per trust anchor information basis. 
Usage can be implicity, if based on a trust anchor store basis, but a field is missing 
to indicate the usages on a per trust anchor information basis.

Please consider adding a new field called "usages" that will contain one or more OIDs. 
Each OID will specify a usage (see later on an ASN.1 proposal). 
3. The text states: "All trust anchors are distinguished by the public key". 
This means that it is impossible to have within a cryptographic module two 
"trust anchor information" with the same public key that would serve 
independently two different purposes.

[CW] Correct.  I will add a statement to section 1.3.2 to clarify that a public key may appear at most one time in a given trust anchor store.
[DP] This would be an important restriction. Rather than adding such a statement, 
I would prefer a model where this restriction does not exist anymore. 
This means that the trust anchor information SHOULD NOT be addressed using the value of the public key.
I made a proposal in my previous comment 7. This would be one way to solve my concern. There may be other ways.
[CW] The concept is not new.  Adding the statement to the front was simply a clarification. 
[DP2] I still prefer a model without thisrestriction. You use the public key as an handle wheras it should not be used for that purpose. Let us uses real handles to points to the various elements. Let us add a new command that would return all the handles as well as the sequence numbers for each handle. This command would be called: "Sequence Number Query". The Sequence Number Query command will include a random number in the query for replay protection and will be UNSIGNED.The response will always be signed and will include: the random number and pairs of : handles, sequence numbers. The first item in the list will always be for the trust anchor store. The others for trust anchor information (including the apex).The Sequence Number Adjust Command then seems to be unnecessary. This would solve the loss of synchronisation between a recipient and a trust anchor store. In particular, this would allow to change the sentence contained in section 6 which is:
The TAMP message recipient MUST maintain a database of the most recent sequence number from a successfully processed TAMP message from each trust anchor. 
into:
The TAMP message recipient SHOULD maintain a database of the most recent sequence number from a successfully processed TAMP message from each trust anchor and each trust anchor store. If synchronisation is lost, the recipient can use the Sequence Number Query command to get the right sequence numbers.
In this way, section 8 can also be removed. This approach would solve my concern when two managers manage the same TAS without strong synchronization.
   4. The text states: .

The text states: 

[CW] The public key cannot be changed.  In an update message, the public key is used to identify the trust anchor to update and other fields can be changed.  The public key value cannot be changed via an update message. The use of the public key identifier to identify the signer of an object is similar to authorityKeyIdentifier in a certificate or SignerInfo in a SignedData object. These could be given as examples here to clarify the intent. 
[DP] You said: "The public key cannot be changed". I am confused. Using a "remove" command followed by 
an "add" command (see pages 30 and 31), the public key can be changed.  The change command 
(from TrustAnchorUpdate) also allows to change the public key value.  
The main problem is still that there is no means to indicate which use should be done with each TAI.
[CW] A public key can be removed.  A public key can be added.  We can view that as changing the public key.  A public key cannot be changed in place using a change command.  For change messages, the public key is used to locate the trust anchor (see page 32).  
You can indicate which use should be done with each TAI using CertPathControls and extensions.
[DP2] This cannot be done easily with the current proposal. For example, it is impossible to set at the same time 
a Certificate structure and a CerthPathControl. It would be advantageous to change the structure of TrustAnchorChoice, 
so that additional constraints can be set at the same time. It is necessary to separate the certPath controls and the extensions 
which are usually not part of a self-signed certificate. I would propose something like:

    TrustAnchorChoice ::= SEQUENCE {
       trustAnchorPoint       TrustAnchorPoint,
       usages                 Usages           OPTIONAL,
       certPath               CertPathControls OPTIONAL,
       exts      [1] EXPLICIT Extensions       OPTIONAL }
   
   TrustAnchorPoint ::= CHOICE {
     certificate               Certificate,
     tbsCert      [1] EXPLICIT TBSCertificate,
     taInfo       [2] EXPLICIT TrustAnchorInfo }

   TrustAnchorInfo ::= SEQUENCE {
     version              TrustAnchorInfoVersion DEFAULT v1,
     pubKey               SubjectPublicKeyInfo,
     keyId                KeyIdentifier,
     validity             Validity         OPTIONAL,
     taTitle              TrustAnchorTitle OPTIONAL,
     taTitleLangTag   [2] UTF8String       OPTIONAL }

   Usages ::= SEQUENCE OF Usage
   Usage ::=  OBJECT IDENTIFIER 
   CertPathControls ::= SEQUENCE {
      policySet         [0] CertificatePolicies OPTIONAL,
      policyFlags       [1] CertPolicyFlags     OPTIONAL,
      nameConstr        [2] NameConstraints     OPTIONAL,
      pathLenConstraint [3] INTEGER (0..MAX)    OPTIONAL}
            
Notice that CertPathControls does not duplicate anymore the mandatory information 
that is in a self-signed certificate. Observe that TrustAnchorInfo now really becomes "minimalist". 
This impacts taf-04.
The add, remove and change commands from TrustAnchorUpdate should be revised accordingly :
    TrustAnchorUpdate ::= CHOICE {      add     [1] TrustAnchorChoice,      remove  [2] Handle,      change  [3] TrustAnchorChoice }
Later on (see below) keyId is defined as "the public key identifier of 
the trust anchor public key".

[CW] “As assigned by the trust anchor authority” would hold for all of the fields.  I don’t see any reason to state this here.

[CW] New trust anchor information can be added using the add field of TrustAnchorUpdate.
[DP]. However, a location for placing this TAI should be added. At this time, the location is implicitly obtained 
through the value of the public key which is too restrictive. 
 [CW] The draft uses a public key to locate a trust anchor for TAMP purposes only.  This does not mean one needs the public key to find the trust anchor for usage.   The TA can be found using name, key identifier or any other retrieval means (i.e., usage, policy, etc.) an implementation allows.  We don’t need a variety of handles for management purposes and the public key seems like the right value to use for this purpose to me.
[DP2] See the response above for the use of real handles. The public key is NOT the right value to be used.
These restrictions should be advertised in the abstract section, since this is 
only a subset of the regular management functions that are usually expected.

[DP2] Currently the TAM Status Query message is mentioned as RECOMMENDED (page 21). 
As soon as more that one TAI is supported, it should be mentioned as REQUIRED.

[CW] This seems like an implementation possibility to me, not something that needs to be expressed in the spec.
[DP] I do not see how it would be possible to support such an implementation with the current protocol.
[CW] Will you be in Hiroshima?  I would be happy to give you a demonstration.
[DP2] Unfortunately I won't be present. With the new approach I propose in this e-mail, 
i.e. using real handles and adding "usages", the approach of storing TAI in fixed locations may be discarded. 
Denis

---

From: "Carl Wallace" <[email-masked]>
Date: Fri, 23 Oct 2009 08:24:55 -0400

Inline...

From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Friday, October 23, 2009 8:16 AM
To: pkix
Subject: Re: [pkix] WGLC for TAMP

Russ,

TrustAnchorInfo is intended to serve as a minimalist representation of 

trust anchor information for scenarios where storage or bandwidth is highly constrained.

taf-04 defines it as:

      keyId     KeyIdentifier,

      exts      [1] EXPLICIT Extensions   OPTIONAL,

with:

      taName           Name,

      certificate      [0] Certificate OPTIONAL,

      policySet        [1] CertificatePolicies OPTIONAL,

      policyFlags      [2] CertPolicyFlags OPTIONAL,

      nameConstr       [3] NameConstraints OPTIONAL,

      pathLenConstraint[4] INTEGER (0..MAX) OPTIONAL}

[CW] It can also be much smaller.

[CW] This draft has finished WG LC.  There are two other structures that support inclusion of a validity field.  

Denis

	----- Message reçu ----- 

	De : Russ Housley 

	À : denis.pinkas,pkix 

	Denis:

	

	Russ

---

From: "Carl Wallace" <[email-masked]>
Date: Fri, 23 Oct 2009 09:01:29 -0400

Denis,

This message has gotten too lengthy for inline responses.  Here's a summary list of my responses.

Regarding changes to the definitions, we disagree.  I understand that you would like to see additional definitions added.  I don't agree this is necessary.  I think the document provides sufficient context for the reader to know whether an entity (i.e., person) is being referred to or a data structure and do not intend to add the suggested definitions.   The -04 draft submitted this morning aims to clarify the text in -03 that Erik identified as ambiguous.  

Regarding the various sweeping change proposals... 

- Usages can be asserted now using the extendedKeyUsage extension.  No new field is necessary.  

- We do not need to add a Sequence Number Query message.  Sequence numbers can be obtained using a TAMP Status Query.  If usage experience proves otherwise in time, we can always augment the toolbox with additional management messages.

- Using the public key as the handle for management operations has been a central part of TAMP since version -00.  I see no reason to change this even if you disparage the approach as not using "real handles".   

- I see no reason to change the TrustAnchorChoice in the way you suggest.  Amongst other reasons, your suggestion breaks backwards compatibility with certificates.  In TAF, a certificate is a TrustAnchorChoice.

Carl

From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Friday, October 23, 2009 8:22 AM
To: pkix
Subject: Re: [pkix] WGLC for TAMP

Carl,

	----- Message reçu ----- 

	De : Carl Wallace 

	À : denis.pinkas,pkix 

	Responses below...

	Carl,

		----- Message reçu ----- 

		De : Carl Wallace 

		À : denis.pinkas,pkix 

		Responses inline...

		

		

	[CW] See above.

		

[DP2] I still prefer a model without thisrestriction. You use the public key as an handle wheras it should not be used for that purpose. 
Let us uses real handles to points to the various elements. 
Let us add a new command that would return all the handles as well as the sequence numbers for each handle. 
This command would be called: "Sequence Number Query".
 
The Sequence Number Query command will include a random number in the query for replay protection and will be UNSIGNED.
The response will always be signed and will include: the random number and pairs of : handles, sequence numbers. 
The first item in the list will always be for the trust anchor store. The others for trust anchor information (including the apex).
The Sequence Number Adjust Command then seems to be unnecessary. 

This would solve the loss of synchronisation between a recipient and a trust anchor store. 
In particular, this would allow to change the sentence contained in section 6 which is:

The TAMP message recipient MUST maintain a database of the most recent sequence number 

from a successfully processed TAMP message from each trust anchor. 
into:
The TAMP message recipient SHOULD maintain a database of the most recent sequence number 

from a successfully processed TAMP message from each trust anchor and each trust anchor store. 

If synchronisation is lost, the recipient can use the Sequence Number Query command to get 

the right sequence numbers.
In this way, section 8 can also be removed. This approach would solve my concern when two managers manage the same TAS 

without strong synchronization.

   4. The text states: 

The text states: 

		

   

This impacts taf-04.

    TrustAnchorUpdate ::= CHOICE {

      add     [1] TrustAnchorChoice,

      remove  [2] Handle,

      change  [3] TrustAnchorChoice }

	<snip> 

		

	[CW] See above.  

		

Denis

---

From: "Denis Pinkas"<[email-masked]>
Date: Fri, 23 Oct 2009 17:47:05 +0200

Carl,

This is a fast response since I don't have sufficient time available for a detailed response.

I observed that you did'nt reply to the two comments I made in front of the e-mail.

We also need to give time for the other participants on the list to see the exchanges 
so that they may get and express an opinion.

----- Message reçu ----- 
De : pkix-bounces 
À : denis.pinkas,pkix 
Date : 2009-10-23, 15:01:29
Sujet : Re: [pkix] WGLC for TAMP

Denis,
This message has gotten too lengthy for inline responses.  Here’s a summary list of my responses.
Regarding changes to the definitions, we disagree.  I understand that you would like to see additional definitions added.  I don’t agree this is necessary.  I think the document provides sufficient context for the reader to know whether an entity (i.e., person) is being referred to or a data structure and do not intend to add the suggested definitions.   The -04 draft submitted this morning aims to clarify the text in -03 that Erik identified as ambiguous.  
When I have time available, I will take a look at the new text.
Regarding the various sweeping change proposals… 
- Usages can be asserted now using the extendedKeyUsage extension.  No new field is necessary.

extendedKeyUsage does not appear anywhere in the document. 

- We do not need to add a Sequence Number Query message.  Sequence numbers can be obtained using a TAMP Status Query.  If usage experience proves otherwise in time, we can always augment the toolbox with additional management messages.
The proposed Sequence Number Query message is UNSIGNED. All other current messages 
have the problems of being signed and requiring the right sequence number. 

The current approach do not solve the concern of two managers managing the same TAS.
Real handles should be used. Sequence numbers should be available without authentication.

Now, if some implemenatations do not want to take advantage of this new feature, they would not be forced to use it.
Anyway, a handle should be returned after each "add".
Using the public key as the handle for management operations has been a central part of TAMP since version -00.  I see no reason to change this even if you disparage the approach as not using “real handles”.   
- I see no reason to change the TrustAnchorChoice in the way you suggest.  Amongst other reasons, your suggestion breaks backwards compatibility with certificates.  In TAF, a certificate is a TrustAnchorChoice.

The reasons are indicated. The current structures are not homogeneous to handle in the same way the three basic choices. 
For Certificate and TBSCertificate,  two messages will be necessary to make an update or adding a new TAI, 
whereas my proposed solution allows to make it in a single message.

More important. The text states on page 20:

   Implementations are not required to support all three options.  

In practice if only "Certificate" is supported, no constraints can be added using "change",
.. unless the other options are also supported.

Denis
Carl
  
----- Message reçu ----- 
De : Carl Wallace 
À : denis.pinkas,pkix 
Date : 2009-10-22, 12:58:05
Sujet : RE: [pkix] WGLC for TAMP
Responses below…
----- Message reçu ----- 
De : Carl Wallace 
À : denis.pinkas,pkix 
Date : 2009-10-13, 13:59:41
Sujet : RE: [pkix] WGLC for TAMP
Responses inline...

 

 

The text states:

---

From: "Carl Wallace" <[email-masked]>
Date: Fri, 23 Oct 2009 12:37:19 -0400

Inline....

From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Friday, October 23, 2009 11:47 AM
To: pkix
Subject: Re: [pkix] WGLC for TAMP

Carl,

[CW] Sorry about that.   The TrustAnchorList section describes usage of the structure, defined in TAF, by comparing it to the TAMPUpdate message.  I'm not sure where the confusion arises.    

I do not see where revocation is allowed to be omitted.  There's no revocation checking done for a message signed with a trust anchor.  Where a certificate is used full path validation is expected.

[CW] Of course.  

	----- Message reçu ----- 

	De : pkix-bounces 

	À : denis.pinkas,pkix 

	Denis,

[CW] True.  

[CW] Sequence numbers should not be reused so having the "right" sequence number is not complicated.  Of course, if you have a batch of messages from the same manager, those need to be serially processed.  

[CW] This is false.  One manager's sequence number stored in a trust anchor store does not impede another's ability to manage the store.

[CW] Verbose responses to an "add" operation include the handles, i.e., the public keys.  

	Using the public key as the handle for management operations has been a central part of TAMP since version -00.  I see no reason to change this even if you disparage the approach as not using "real handles".   

The reasons are indicated. 

[CW] I should clarify.  I see no reasons that persuade me that these changes are necessary or a good idea and see some reasons to the contrary, such as loss of backwards compatibility with certificates.    

The current structures are not homogeneous to handle in the same way the three basic choices. 
For Certificate and TBSCertificate,  two messages will be necessary to make an update or adding a new TAI, 
whereas my proposed solution allows to make it in a single message.

[CW] You can change a certificate to a TrustAnchorInfo in a single message using the current spec.  The remove element must appear in the updates list before the add element.

In practice if only "Certificate" is supported, no constraints can be added using "change",
... unless the other options are also supported.

[CW] This is true.  You can choose to use a structure that does not allow constraints to be changed.  

Denis

	Carl

	Carl,

		----- Message reçu ----- 

		De : Carl Wallace 

		À : denis.pinkas,pkix 

		Responses below...

		Carl,

			----- Message reçu ----- 

			De : Carl Wallace 

			À : denis.pinkas,pkix 

			Responses inline...

			

			

		[CW] See above.

	

	

	 

	into:

	   4. The text states: 

	
	
	The text states: 

	

	

	

	This impacts taf-04.

	      remove  [2] Handle,

	 

		<snip> 

			

		[CW] See above.  

			

	Denis

---

From: Russ Housley <[email-masked]>
Date: Fri, 23 Oct 2009 13:05:55 -0400

Denis:

- We do not need to add a Sequence Number Query message.
Sequence numbers can be obtained using a TAMP Status Query.  If
usage experience proves otherwise in time, we can always augment the
toolbox with additional management messages.

The proposed Sequence Number Query message is UNSIGNED. All other
current messages

have the problems of being signed and requiring the right sequence
number.

The current approach do not solve the concern of two managers managing
the same TAS.

Real handles should be used. Sequence numbers should be available without
authentication.

Now, if some implemenatations do not want to take advantage of this new
feature, they would not be forced to use it.

Anyway, a handle should be returned after each
"add".

Perhaps in you haste, you were unable to make yourself clear, but I just
do not understand your concern here.  Query does not update the
trust anchor store.  What "add" are you talking
about?

Russ

---

From: Russ Housley <[email-masked]>
Date: Sun, 25 Oct 2009 18:09:13 -0400

Denis:

What is the concern that you are trying to address by making sequence
number tracking a SHOULD instead of a MUST?  In you last message you
raised this in the context of using the public key as a handle for the
trust anchor, so I guess I missed this point in the thread of many nested
replies.

Let us add a new command that
would return all the handles as well as the sequence numbers for each
handle.
This command would be called: "Sequence Number Query".

The Sequence Number Query command will include a random number in the
query for replay protection and will be UNSIGNED.
The response will always be signed and will include: the random number
and pairs of : handles, sequence numbers.
The first item in the list will always be for the trust anchor store. The
others for trust anchor information (including the apex).
The Sequence Number Adjust Command then seems to be unnecessary.

This would solve the loss of synchronisation between a recipient and a
trust anchor store.
In particular, this would allow to change the sentence contained in
section 6 which is:

The TAMP message recipient
MUST maintain a database of the most recent sequence number
from a successfully processed TAMP message from each trust anchor.

into:

The TAMP message recipient
SHOULD maintain a database of the most recent sequence number
from a successfully processed TAMP message from each trust anchor and
each trust anchor store.
If synchronisation is lost, the recipient can use the Sequence Number
Query command to get
the right sequence
numbers.

In this way, section 8 can also be removed. This approach would
solve my concern when two managers manage the same TAS
without strong
synchronization.

Russ

---

From: Russ Housley <[email-masked]>
Date: Sun, 25 Oct 2009 18:01:02 -0400

Denis:

I agree that the representation is not minimal.  That description
should be removed.

I do not agree that a validity period is always needed.  I can think
of cases where it might be useful for non-apex trust anchors.
However, I'd like to hear some rationale for this point of view, not just
a pointer to some non-IETF mail list.

Russ

At 08:16 AM 10/23/2009, Denis Pinkas wrote:

Russ,

TrustAnchorInfo is intended to serve as a minimalist representation
of
trust anchor information for scenarios where storage or bandwidth is
highly constrained.
taf-04
defines it as:

TrustAnchorInfo ::= SEQUENCE {
version   TrustAnchorInfoVersion
DEFAULT v1,
pubKey
SubjectPublicKeyInfo,
keyId
KeyIdentifier,
taTitle   TrustAnchorTitle
OPTIONAL,
certPath  CertPathControls OPTIONAL,
exts      [1]
EXPLICIT Extensions   OPTIONAL,
taTitleLangTag   [2] UTF8String
OPTIONAL }
with:

taName           Name,
certificate
[0] Certificate OPTIONAL,

policySet        [1]
CertificatePolicies OPTIONAL,
policyFlags
[2] CertPolicyFlags OPTIONAL,

nameConstr       [3] NameConstraints
OPTIONAL,
pathLenConstraint[4] INTEGER (0..MAX)
OPTIONAL}
I do not consider
it as a "minimalist representation", since it can be much
largeur than

After some discussion on the X.500 list, several people considered than
it was necessary

So I will suggest, in any case, to add a validity field to the current
structure.

Note that tamp-04 supports a protocol to change the validity period (see
page 30, field TBSCertificateChangeInfo).

See my other message to Carl about TAMP-03 for a proposal for changing
both

Denis

----- Message reçu -----

De : Russ Housley

À :

denis.pinkas,pkix

Denis:

Russ

pkix mailing list

[email-masked]

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 29 Oct 2009 10:31:59 +0100

Russ,

Responnses are in lines.
Denis:
- We do not need to add a Sequence Number Query message.  Sequence numbers can be obtained using a TAMP Status Query.  
If usage experience proves otherwise in time, we can always augment the toolbox with additional management messages.

[Denis] The problem is that the text says: 
   The TAMP Status Query message MUST be signed.  For the query message   to be valid, the trust anchor store MUST be an intended recipient of   the query, the sequence number checking described in Section 6 MUST   be successful when the TAMP message signer is a trust anchor, and the   digital signature MUST be validated by the apex trust anchor   operational public key, an authorized management trust anchor, or via   an authorized X.509 certification path originating with such a trust   anchor. 
There is a chicken and egg problem: If the sequence numbers are lost, it is no more possible 
to make a query since the right sequence number to make the query cannot be used.

Perhaps in you haste, you were unable to make yourself clear, but I just do not understand your concern here.  Query does not update the trust anchor store.  What "add" are you talking about?

 [Denis] I am referring to the "add" from:
     TrustAnchorUpdate ::= CHOICE {      add     [1] TrustAnchorChoice,      remove  [2] SubjectPublicKeyInfo,      change  [3] EXPLICIT TrustAnchorChangeInfoChoice }

Russ

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 29 Oct 2009 10:33:11 +0100

Russ,

Responses are in lines.
----- Message reçu ----- 
De : Russ Housley 
À : denis.pinkas 
Date : 2009-10-25, 23:01:02
Sujet : Re: [pkix] WGLC for TAMP

Denis:

I agree that the representation is not minimal.  That description should be removed.

I do not agree that a validity period is always needed.  I can think of cases where it might be useful 
for non-apex trust anchors. 
[Denis] So you  agree that it should be there, at least as OPTIONAL. 
This means that all the three choices should be able to have a time period.
     certificate  Certificate,     tbsCert      [1] EXPLICIT TBSCertificate,     taInfo       [2] EXPLICIT TrustAnchorInfo } 
This is not currently the case for TrustAnchorInfo. The ASN.1 definition should be changed.
However, I'd like to hear some rationale for this point of view, not just a pointer to some non-IETF mail list.
[Denis] The argument of making it mandatory comes from the following argumentation. 
All security modules are able to handle a clock, not very well synchronized with UTC 
but at least "as good or as bad as" the clock of a PC. TAI should not be used for ever and 
should be limited in time. The clock allows to control the time period during which root public keys 
can be used. In case some odd devices do not have such a clock available, the TAI should 
nevertheless be sent with the time period in it. Security modules unable to take advantage of it 
would simply ignore the field.
 
We would place requirements similar to a non critical extension: 
"A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized".
Russ

Russ,

     
taName           Name,
      certificate     
     
policySet        [1]

 

 
Denis

----- Message reçu ----- 

De : Russ Housley 

À : denis.pinkas,pkix 

Denis:

Russ

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 29 Oct 2009 10:34:21 +0100

Russ,

The topic of sequence numbers is not directly related to the topic of handles.

Let us first address the case of sequence numbers which is the motivation to change the MUST into a SHOULD.
 
The protocol attempts to address replay protection. 

There are two basic techniques that can be used: 

  - nonces generated by the client, or 
  - challenges generated by the server. 

When using challenges, the advantage is that clients only need to maintain state information 
between the request of the challenge and its use.
 
When using nonces based on the time, the advantage of using a combination of time and random numbers, 
is that clients do not need to maintain any state information between commands. 
However a clock reasonably synchronized is needed. It is unclear why this approach has not been chosen.

A relatively small amount of memory is needed to remember the nonces that have been *successfully* received 
during a time period from 5 to 10 minutes. All hardware security modules have a clock that is loosely synchronized 
and thus which can be used.
 
The approach which has been chosen is to use sequence numbers. The disadvantage is that 
state information between commands need to be maintained. The current text uses a MUST. 
But what happens if the memory of the sequence numbers is lost, despite of the MUST condition ? 
There is the need to recover from such a situation.
 
I made the assumption that the sequence numbers were lost by the client despite of the MUST condition. 
I proposed a new command (Sequence Number Query) to solve the issue, since the current commands 
do not seem to solve it (unless you have an explanation to provide).
 
Secondly, let us address the topic of handles. Handles should always be defined by the server as the result 
of a command. This makes no restriction to the content that can be stored in a TAS and this allows the same 
public key to be used with different constraints or purposes, which the present approach does not allow.

This also allows concurrent management by different TAS managers without strong synchronization between them, 
which the present approach does not allow.

Denis
----- Message reçu ----- 
De : Russ Housley 
À : denis.pinkas 
Date : 2009-10-25, 23:09:13
Sujet : Re: [pkix] WGLC for TAMP

Denis:

What is the concern that you are trying to address by making sequence number tracking a SHOULD instead of a MUST?  
In you last message you raised this in the context of using the public key as a handle for the trust anchor, 
so I guess I missed this point in the thread of many nested replies.

into:

Russ

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 29 Oct 2009 10:37:04 +0100

Carl,

Since I took the time to respond to three messages from Russ, I don't have sufficient time available 
to respond point by point to your e-mail, but will attempt to do it next week.

In between, I would like to insist on one point that is very important.

There are currently three basic choices:

     certificate  Certificate,
     tbsCert      [1] EXPLICIT TBSCertificate,
     taInfo       [2] EXPLICIT TrustAnchorInfo,

The first choice allows to use self-signed certificates. 
I believe that this choice will be used in 98% of the cases.

The next choice allows to use basically the same content, but unsigned.
I believe that this choice will be used in less than 1 % of the cases, but let us allow it.

The last choice should allow to pick a subset of the fields that are in the previous choice.
I believe that this choice will be used in 1 % of the cases, but let us allow it.

Now, let us come to the central point. When self-signed certificates are issued by CAs,
CAs do not generally know what kind of usages will be done by their published trust anchors 
and then constraints are NOT included in the self-signed certificate by the CA 
but added (i.e. defined) by Relying Parties, in our case Trust Anchor Store managers.

This means that whatever original format is being used (i.e. certificate, tbsCert or taInfo), TAS managers 
should be able to add constraints *and usage conditions*(see my proposal again) to any of these original 
three choices.

The current draft does not allow for it, and this motivates many of my change proposals to the protocol.

Denis

----- Message reçu ----- 
De : Carl Wallace 
À : denis.pinkas,pkix 
Date : 2009-10-23, 17:37:19
Sujet : RE: [pkix] WGLC for TAMP

Inline….
From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Friday, October 23, 2009 11:47 AM
To: pkix
Subject: Re: [pkix] WGLC for TAMP
Carl,
This is a fast response since I don't have sufficient time available for a detailed response.
I observed that you did'nt reply to the two comments I made in front of the e-mail.
[CW] Sorry about that.   The TrustAnchorList section describes usage of the structure, defined in TAF, by comparing it to the TAMPUpdate message.  I’m not sure where the confusion arises.    
I do not see where revocation is allowed to be omitted.  There’s no revocation checking done for a message signed with a trust anchor.  Where a certificate is used full path validation is expected.
We also need to give time for the other participants on the list to see the exchanges 
so that they may get and express an opinion.
[CW] Of course.  
----- Message reçu ----- 
De : pkix-bounces 
À : denis.pinkas,pkix 
Date : 2009-10-23, 15:01:29
Sujet : Re: [pkix] WGLC for TAMP
Denis,
[CW] Sequence numbers should not be reused so having the “right” sequence number is not complicated.  Of course, if you have a batch of messages from the same manager, those need to be serially processed.  

The current approach do not solve the concern of two managers managing the same TAS.
[CW] This is false.  One manager’s sequence number stored in a trust anchor store does not impede another’s ability to manage the store.

[CW] Verbose responses to an “add” operation include the handles, i.e., the public keys.  
  
----- Message reçu ----- 
De : Carl Wallace 
À : denis.pinkas,pkix 
Date : 2009-10-22, 12:58:05
Sujet : RE: [pkix] WGLC for TAMP
Responses below…
----- Message reçu ----- 
De : Carl Wallace 
À : denis.pinkas,pkix 
Date : 2009-10-13, 13:59:41
Sujet : RE: [pkix] WGLC for TAMP
Responses inline...

 

 

The text states: 

   

            

      remove  [2] Handle,

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 29 Oct 2009 07:04:54 -0400

TrustAnchorInfo allows a certificate to be carried precisely for the reason you cite - many apps will require a Certificate and there needs to be a means of associating constraints.  So, the current syntax does allow what you suggest - while maintaining backwards compatibility with Certificate structures that are not decorated with constraints.

Regarding usages/EKU, EKU does not apply across a certification path.  If this feature is desired, we should define a new extension in a separate draft that can be used by all three structures.  If there's already an extension that does this we could just use it.   The CCC extension serves this purpose for CMS-based protocols, i.e., usages are expressed in the TA and processed across a path.

Regarding validity (separate related thread), there are no processing requirements for a TA's validity field in 5280 and there are "expired" TAs in use.  For backwards compatibility, a new mechanism should be used if this is desired, i.e., a new extension should be defined that can be used by all three structures.

Regarding sequence numbers (separate unrelated thread), the easiest way to avoid problems due to loss of knowledge of sequence numbers in a particular store is to not reuse sequence numbers.  The signer should know what its current sequence number is and should exclusively use numbers higher than that value in new messages.  There are other ways too.  A TA store manager could use a time-based value instead of maintaining its sequence number state.  A TA store manager could have a dedicated status query key that is validated using a certificate instead of a trust anchor.  Sequence number processing is not required for TAMP messages verified using a certification path so messages validated using this certificate could always be used to query a store's contents.    

From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Thursday, October 29, 2009 5:37 AM
To: pkix
Subject: Re: [pkix] WGLC for TAMP

Carl,

     certificate  Certificate,

Denis

	----- Message reçu ----- 

	De : Carl Wallace 

	À : denis.pinkas,pkix 

	Inline....

	Carl,

	[CW] Of course.  

		----- Message reçu ----- 

		De : pkix-bounces 

		À : denis.pinkas,pkix 

		Denis,

	[CW] True.  

	

	Denis

		Carl

		Carl,

			----- Message reçu ----- 

			De : Carl Wallace 

			À : denis.pinkas,pkix 

			Responses below...

			Carl,

				----- Message reçu ----- 

				De : Carl Wallace 

				À : denis.pinkas,pkix 

				Responses inline...

				

				

			[CW] See above.

		

		

		 

		

		into:

		

		

		

		

		   4. The text states: 

		
		
		The text states: 

		

		

		

		This impacts taf-04.

		

		

		      remove  [2] Handle,

		 

			<snip> 

				

			[CW] See above.  

				

		Denis

---

From: Russ Housley <[email-masked]>
Date: Thu, 29 Oct 2009 10:12:45 -0400

Denis:

I agree that the representation is not minimal.  That
description should be removed.

I do not agree that a validity period is always needed.  I can
think of cases where it might be useful

[Denis] So you  agree that
it should be there, at least as OPTIONAL.

This means that all the three choices should be able to have a time
period.

certificate  Certificate,
tbsCert      [1]
EXPLICIT TBSCertificate,
taInfo       [2]
EXPLICIT TrustAnchorInfo }

This is not currently the case for
TrustAnchorInfo. The ASN.1 definition should be changed.

However, I'd like to hear some rationale for this point of view, not
just a pointer to some non-IETF mail list.

[Russ] I am saying that I would not oppose some mechanism for adding it,
perhaps using the extension mechanism described by Carl.  Such a
thing could be in the a separate extension document.  However, it is
important that the Apex Trust Anchor not be able to expire.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 29 Oct 2009 10:21:13 -0400

Denis:

So there is more than one mechanism that can be used in protocol
design.  You seem to prefer a different one.  Without WG
consensus that a change is needed here, I am not willing to make such a
large change at this stage in the protocol develpment.

Russ

The topic of sequence numbers is not
directly related to the topic of handles.

Let us first address the case of
sequence numbers which is the motivation to change the MUST into a
SHOULD.

The protocol attempts to address
replay protection.

When using challenges, the advantage
is that clients only need to maintain state information

When using nonces based on the time,
the advantage of using a combination of time and random numbers,

is that clients do not need to maintain any state information between
commands.

However a clock reasonably synchronized is needed. It is unclear why this
approach has not been chosen.

A relatively small amount of memory is needed to remember the nonces that
have been *successfully* received

during a time period from 5 to 10 minutes. All hardware security modules
have a clock that is loosely synchronized

The approach which has been chosen is
to use sequence numbers. The disadvantage is that

state information between commands need to be maintained. The current
text uses a MUST.

But what happens if the memory of the sequence numbers is lost, despite
of the MUST condition ?

I made the assumption that the
sequence numbers were lost by the client despite of the MUST condition.

I proposed a new command (Sequence Number Query) to solve the issue,
since the current commands

Secondly, let us address the topic of
handles. Handles should always be defined by the server as the result

of a command. This makes no restriction to the content that can be stored
in a TAS and this allows the same

public key to be used with different constraints or purposes, which the
present approach does not allow.

This also allows concurrent
management by different TAS managers without strong synchronization
between them,

Denis

----- Message reçu -----

De : Russ Housley

À : denis.pinkas

Denis:

What is the concern that you are trying to address by making sequence
number tracking a SHOULD instead of a MUST?

In you last message you raised this in the context of using the
public key as a handle for the trust anchor,

so I guess I missed this point in the thread of many nested
replies.

Let us add a new
command that

would return all the handles as well as the sequence numbers for
each

handle.

The Sequence Number Query command will include a random number in
the

The response will always be signed and will include: the random
number

The first item in the list will always be for the trust anchor store.
The

This would solve the loss of synchronisation between a recipient and
a

trust anchor store.

section 6 which is:

The TAMP message
recipient

from a successfully processed TAMP message from each trust
anchor.

into:

The TAMP message
recipient

from a successfully processed TAMP message from each trust anchor
and

each trust anchor store.

If synchronisation is lost, the recipient can use the Sequence
Number

Query command to get

the right sequence

numbers.

without strong

synchronization.

Russ

pkix mailing list

[email-masked]

---

From: Russ Housley <[email-masked]>
Date: Thu, 29 Oct 2009 09:56:32 -0400

Denis:

- We do not need to add a Sequence Number Query message.
Sequence numbers can be obtained using a TAMP Status Query.

If usage experience proves otherwise in time, we can always augment
the toolbox with additional management messages.

[Denis] The problem is that the
text says:

The TAMP Status Query message MUST be signed.  For
the query message
to be valid, the trust anchor store MUST be an intended
recipient of
the query, the sequence number checking described in Section
6 MUST
be successful when the TAMP message signer is a trust
anchor, and the
digital signature MUST be validated by the apex trust
anchor
operational public key, an authorized management trust
anchor, or via
an authorized X.509 certification path originating with such
a trust
anchor.

There is a chicken and egg problem:
If the sequence numbers are lost, it is no more possible

to make a query since the right sequence number to make the query cannot
be used.

[Russ] I understand your comment.  Is it wise to release the list of
trust anchors to an unauthenticated party?  Here the TAMP
specification is conservative.  If a sequence number query is added,
I think it should be signed and it should only release the sequence
number for the signer.  With this information, the TAMP Query can be
used to get information about the other trust anchors if the party is
authorized to do so.

[Russ] I wonder if tracking sequence number is so hard.  Is this
worth the complexity?  I'd like to hear from others, not just
Denis.

The current approach do not solve the concern of two managers
managing the same TAS.

Real handles should be used. Sequence numbers should be available
without authentication.

[Russ] If two managers are using the same trust anchors, then they trust
each other a lot.  They are sharing a private key.  Expecting
additional coordination between such managers seems reasonable.
This coordination can be avoided by installing separate trust anchors,
assuming memory is available within the trust anchor store.

[Russ] I still see no reason to share trust anchor store details without
authentication.

Now, if some implemenatations do not want to take advantage of this
new feature, they would not be forced to use it.

Perhaps in you haste, you were unable to make yourself clear, but I
just do not understand your concern here.  Query does not update the
trust anchor store.  What "add" are you talking
about?

[Denis] I am
referring to the "add" from:

TrustAnchorUpdate ::= CHOICE {
add     [1]
TrustAnchorChoice,
remove  [2] SubjectPublicKeyInfo,
change  [3] EXPLICIT
TrustAnchorChangeInfoChoice }

[Russ] I see no value in an additional handle.  Can you provide a
use case to justify it?  Is anyone else seeing a need here?

Russ