Re: [pkix] TAMP spec

["Denis Pinkas"<[e-mail]>]

I will summarize in this email my comments on the draft.

I have finally been able to review the changes that were made to version 04. 
Some parts of the revised text are not crystal clear to me.

I am still wondering whether the draft complies with draft-ietf-pkix-ta-mgmt-reqs-04. 
On page 11, we have:
3.5.  RFC 5280 Support3.5.1.  Functional Requirements   A trust anchor management protocol MUST enable management of trust   anchors that will be used to validate certification paths and CRLs in   accordance with [RFC5280] and [RFC5055].  A trust anchor format MUST   enable the representation of constraints that influence certification   path validation or otherwise establish the scope of usage of the   trust anchor public key.  Examples of such constraints are name   constraints, certificate policies, and key usage.
The problem is that the current format does not allow a RP or a TAS manager to add constraints 
to a self-signed certificate. This limitation should be mentioned in the TAMP draft 
(or the TAMP draft should be changed).

Since it seems that no change will be made to the draft, I believe this limitation should be indicated.

I have provided some text below to address this concern.

=====================================================================

Stefan said:
 
I think the following text is confusing to a new reader:

“Some sequence number generation schemes, e.g., time-based, 
do not require maintenance of state information.”

This is a general design consideration for designing the protocol but 
has nothing to do with security considerations related to deployment of the specified protocol.

This text seems relevant only if you provide any security related rationales why such approach 
was not selected. Else, I would simply remove this text and possibly add a corresponding text 
in some other place of the document discussing design considerations.

In fact, using time-based sequence numbers allow to solve some issues in case 
more than one trust anchor store manager manages a given trust anchor store. 
I have provided some text at the end of this email to address the problem. 
Since parallel management is not mandated, the discussion can be in the security 
considerations section, since it really relates to security (denial of service in this case).


1. On page 21, the text says :

   “TrustAnchorInfo is intended to serve as a
   minimalist representation of trust anchor information for scenarios
   where storage or bandwidth is highly constrained”.

Russ, said: “I agree that the representation is not minimal.  
That description should be removed". 

I suggest : 

“TrustAnchorInfo does not use a structure derived from RFC 5280. 
Since it does not include a validity field, the validity period 
of the trust anchor information is unspecified.  The structure 
optionally includes a TrustAnchorTitle with a UTF8String syntax 
and which plays a role similar to the issuer field from a certificate 
with a DN syntax.  It may include a specific element called certPath 
to control certificate path validation”. 


2. Then the text says on the same page:

   “Implementations are not required to support all three options.  The
   unsupportedTrustAnchorFormat error code should be indicated when
   generating a TAMPError due to receipt of an unsupported trust anchor
   format”.

At this place, the characteristics of use of these three structures 
should be indicated since they are not identical. 


I propose to add the following text:

“The functionalities supported by each option are not the same. 
Usually self-signed certificates (supported through the certificate field) 
can be used for several purposes and it is up to relying parties 
to decide for which purpose(s) they should be used. However, when 
the certificate choice is being used, the TrustAnchorChoice structure 
does not allow a trust anchor store manager specifying constraints 
nor the purpose (or scope) for which a self-signed certificate may be used.

On the contrary, the two other structures are able to support 
additional constraints which may be defined by trust anchor store managers.
When they are used without additional specific extensions, 
the purposes for which the trust anchor info may be used to verify 
certification paths needs to be locally defined; this means that different 
usages for different trust anchors placed in the same trust anchor 
store are not possible either. One way to have different usages for different 
trust anchors without using specific extensions is to use a different trust 
anchor store for every different usage. 

Note that the Extended Key Usage extension, as defined in RFC 5280 
indicates one or more purposes for which the trust anchor itself may be used.
Thus, it cannot be used to indicate for which purpose certificates 
from paths terminating to that trust anchor may be used”.


3. On page 22, there is the following text:

   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,

What does the end of the sentence mean ? A signer is not a trust anchor. 
Please clarify and rephrase.


4. On page 33, the text says :

« The TrustAnchorChangeInfo structure or the TBSCertificateChangeInfo 
structure is used to provide the revised configuration of the management 
or identity trust anchor".

The end of the sentence is unclear “management or identity trust anchor” ?

Change proposal:

“The TrustAnchorChangeInfo structure or the TBSCertificateChangeInfo structure 
is used to provide the revised configuration of the tbsCert and the taInfo 
structures respectively. As a consequence, the trust anchor store must make 
a difference between the three options every time one of the structures 
is stored or changed”.


5. On page 55, the text says:

                       “This balance is achieved by performing sequence
   number checking on TAMP messages that are validated directly using a
   trust anchor, and allowing these checks to be skipped whenever the
   TAMP message originator is not represented by a trust anchor”.

What does the end of the sentence mean? What is the difference between 
a “TAMP message originator” that is represented by a trust anchor and 
one which is not? TAMP message originators are trust anchor store managers 
that use a signing key to access the trust anchor store.  

Some explanations may be found, but only on the next page:

   “This could be the apex trust anchor
   operational public key or a management trust anchor public key.  In
   the first case, the apex trust anchor operational public key is used
   directly to validate the TAMP message digital signature.  In the
   second case, a management trust anchor public key is used directly to
   validate the TAMP message digital signature”.

These explanations should be moved. However, I still have a problem 
to understand how a management trust anchor public key is defined.

A final question remains: why can checks be skipped “whenever 
the TAMP message originator is not represented by a trust anchor” ?


6. Then the text states on the same page:

   “Implementations MUST perform sequence number checking on TAMP
   messages that are validated directly using a trust anchor” 

but then the text states:

“and MAY perform sequence number checking for TAMP messages validated 
using a certification path”.

Why is there a difference between the two cases? Please explain and revise.


7. On page 64, at the end of the security considerations section, 
I propose to add the following text:

“In the event of loss sequence number values by one trust anchor store manager, 
sequence number state can be restored by inspecting the most recently 
generated TAMP messages, if these messages are logged.

As sequence number values are used to detect replay attempts, there are difficulties 
to use concurrently several trust anchor store managers unless a strong and 
continuous synchronization between them is being maintained at all times.

When only one trust anchor store manager is being active at a time and in case 
of a failure, a backup trust anchor store manager must use sequence numbers 
that are greater than the last ones being used. One way to avoid a continuous 
communication of the last sequence number values being used between different 
trust anchor store managers is to use sequence numbers built using a date and 
time value in the higher bits of the sequence number values and a random number 
in the lower bits. If reasonable time synchronization is maintained between 
the trust anchor store managers, after a few seconds, the backup trust anchor 
store manager should normally be able to successfully access the trust anchor 
stores initially managed by the master trust anchor store manager”.

Denis

============================================================================

De : Carl Wallace 
À : Stefan Santesson,denis.pinkas,pkix 
Date : 2009-11-10, 22:54:41
Sujet : RE: [pkix] TAMP spec


I agree this is an unanticipated statement for the security considerations section and will strike that sentence, which leaves the following as the draft text:
As sequence number values are used to detect replay attempts, trust anchor store managers must take care to maintain their own sequence number state, i.e., knowledge of which sequence number to include in the next TAMP message generated by the trust anchor store manager.  Loss of sequence number state can result in generation of TAMP messages that cannot be processed due to seqNumFailure.  In the event of loss, sequence number state can be restored by inspecting the most recently generated TAMP message or in collaboration with a trust anchor store manager who can successfully issue a TAMPStatusQuery message. 
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Wednesday, November 11, 2009 6:39 AM
To: Carl Wallace; [e-mail]; pkix
Subject: Re: [pkix] TAMP spec
Carl,

I think the following text is confusing to a new reader:

“Some sequence number generation schemes, e.g., time-based, do not require maintenance of state information.”

This is a general design consideration for designing the protocol but has nothing to do with security considerations related to deployment of the specified protocol.

This text seems relevant only if you provide any security related rationales why such approach was not selected.
Else, I would simply remove this text and possibly add a corresponding text in some other place of the document discussing design considerations.

/Stefan



On 09-11-11 3:23 AM, "Carl Wallace" <[e-mail]> wrote:
Some draft text for security considerations is below.  I don’t think we need text on the possible future extensions.  Once we agree on the text below, I’ll submit a new draft.
 
As sequence number values are used to detect replay attempts, trust anchor store managers must take care to maintain their own sequence number state, i.e., knowledge of which sequence number to include in the next TAMP message generated by the trust anchor store manager.  Loss of sequence number state can result in generation of TAMP messages that cannot be processed due to seqNumFailure.  In the event of loss, sequence number state can be restored by inspecting the most recently generated TAMP message or in collaboration with a trust anchor store manager who can successfully issue a TAMPStatusQuery message.  Some sequence number generation schemes, e.g., time-based, do not require maintenance of state information.
 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Denis Pinkas
Sent: Tuesday, November 10, 2009 7:49 PM
To: pkix
Subject: Re: [pkix] TAMP spec


Steve,



I still see need for additional changes to be made to the document.



In particular, Carl said on october 29:

"I will add some text to the security considerations section describing the consequences of losing sequence number state".

The text to cover this point is not present in version 4.



I also believe that text to cover the missing functionnalities and possible future evolutions should be added.

If there is an agreement on the principle of such an addition, I can propose such a text.



Denis



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

De : pkix-bounces <mailto%20:[e-mail]> 

À : pkix <mailto%20:[e-mail]>  

Date : 2009-11-10, 07:56:51

Sujet : [pkix] TAMP spec



Folks,

The TAMP WGLC period ended on 10/19. While there have been useful 
discussions beyond that time, it now seems appropriate to consider 
this WGLC to be over.

Based on the messages from Denis, Carl, Russ, and Santosh over the 
period from 10/8-11/3, I see no need for additional changes need to 
be made to this document. Additional features and options may be 
pursed in a future, extensions document.

Steve
_______________________________________________
pkix mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/pkix



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