Subject: Re: [pkix] WGLC for TAMP

From: "Denis Pinkas"<[email-masked]>
Date: Mon, 2 Nov 2009 09:33:04 +0100

Carl,

Responses are in lines.

Denis
----- Message reçu ----- 
De : Carl Wallace 
À : denis.pinkas,pkix 
Date : 2009-10-29, 12:04:54
Sujet : RE: [pkix] WGLC for TAMP

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.
I wished that what you say was true. Unfortunately, TrustAnchorInfo does not allow to carry a certificate. 
It is currently defined 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 }

The goal is precisely to be able to "decorate" the self-signed certificate, or any of the two other structures, with additional 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.
I have proposed to add a new field called "usages" that will contain one or more OIDs. 
"Usages" may point to one sub-component from a validation policy.
I have not proposed to use the extension EKU.The concept is close, but not identical.
We do no need to define any new extension to a certificate since the goal is precisely 
not to include it in a self-signed certificate. This field could be called "TA usage (TAU)".
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.
RFC 5280 allows additional processing to be done. Self-signed certificates necessarilly include a validity period. 
Since we should allow all three structures to have the same characteristics, this justifies the fact that we must 
add a validity period to the third choice, at least as being OPTIONAL.
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.
You did not answer to the question I raised : what to do if the signer has lost the values of the sequence numbers ?
Whatever the answer is, this should be indicated at least in the security considerations section.

I now understand that you wrote "sequence numbers", but you mean "monotonically increasing numbers", 
which is not the same. The draft should be corrected.

Using a time-based value, as you propose, does not solve the issue as soon as there is more than one TAS manager.
If there are two (or more) TAS managers, a cache of all successfullly received numbers shall be maintained 
during a time-window, but the draft is silent about this. In addition, both the TAS manager and the TAS shall 
apply the same rules, and the draft is also silent about this.

Using monotonically increasing numbers is not the best choice, since concurrent management is more difficult.
In any case, the draft needs to address this point.

Note: I could not understand your two last sentences from above.

Denis

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,
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,
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. 
[CW] True.  
- 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. 
[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.

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".
[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”.   
- 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. 
[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.
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.
[CW] This is true.  You can choose to use a structure that does not allow constraints to be changed.  
Denis
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,
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…
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,
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...

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

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.

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

[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.
[CW] See above.
[DP2] I still think the definition should be fixed. 
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] 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.  
 
[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: 

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 ? 

[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".
 
Please clarify what is is supposed to be.

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

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

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. 

[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] See above.  
[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.
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.

[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: Mon, 2 Nov 2009 06:32:04 -0500

From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Monday, November 02, 2009 3:33 AM
To: pkix
Subject: Re: [pkix] WGLC for TAMP

Carl,

Responses are in lines.

Denis

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

	De : Carl Wallace 

	À : denis.pinkas,pkix 

	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.

[CRW] Our implementation makes heavy use of the fact that TrustAnchorInfo can carry a certificate.  It is the primary means by which we associate constraints with a certificate, use them for enforcement the pass along the certificate through existing pipes that expect a certificate.  The certificate is in the TrustAnchorInfo.certPath.certificate field.  

	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.

"Usages" may point to one sub-component from a validation policy.
I have not proposed to use the extension EKU.The concept is close, but not identical.
We do no need to define any new extension to a certificate since the goal is precisely 
not to include it in a self-signed certificate. This field could be called "TA usage (TAU)"

[CRW] There's the TBSCertificate structure to consider too (and there may be folks who want to use it in their TAs and intermediate CAs instead of EKU).  As noted before, I think a new extension is needed for this purpose.  I can co-author if you like.

	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.

[CRW] As noted elsewhere in this thread, given that there are expired trust anchors in use today that rely on the existing text, I think we should support this goal using an extension.

	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.

[CRW] I will add some text to the security considerations section describing the consequences of losing sequence number state.  To the list of possible solutions, I'd add inspect recently generated TAMP messages to recover the sequence number.

[CRW] This is in Section 6 of the draft: "To provide replay protection, each TAMP message originator MUST treat the sequence number as a monotonically increasing non-negative integer."

[CRW] Section 6 describes sequence number processing in detail.

[CRW] Now I get it.  You mean concurrent with the same key.  I don't think we need to support this.

[CRW] Section 6 does not require sequence number processing for TAMP message signers validated using a certificate instead of a trust anchor.  A TA manager could maintain a key that corresponds to a trust anchor public key for management activities and a key that corresponds to a certificate for status query activities.  The latter could be used if the TA manager ever lost its sequence number state and history of recently generated TAMP messages but still had its private key.

Denis

	Carl,

	     certificate  Certificate,

	Denis

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

		De : Carl Wallace 

		À : denis.pinkas,pkix 

		Inline....

		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,

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

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

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

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

			

			

			 

			into:

			   4. The text states: 

			
			
			The text states: 

			

			

			

			This impacts taf-04.

			      remove  [2] Handle,

			 

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

					

			Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 2 Nov 2009 13:35:38 -0500

Based on the other thread on EKU, adding a new extension on usage types constrained via certification path is a good idea.
 
Based on discussion here and what I mentioned, requiring to enforce validity period should be done via an extension that can be optionally critical.

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Carl Wallace
	Sent: Monday, November 02, 2009 6:32 AM
	To: [email-masked]; pkix
	Subject: Re: [pkix] WGLC for TAMP

	Carl,

	Responses are in lines.

	Denis

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

		De : Carl Wallace 

		À : denis.pinkas,pkix 

	Denis

		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