Subject: [pkix] TAMP spec

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Nov 2009 01:56:51 -0500

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

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 10 Nov 2009 11:48:46 +0100

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 
À : pkix 
Date : 2009-11-10, 07:56:51
Sujet : [pkix] TAMP spec

Folks,

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

---

From: "Carl Wallace" <[email-masked]>
Date: Tue, 10 Nov 2009 13:23:18 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Tuesday, November 10, 2009 7:49 PM
To: pkix
Subject: Re: [pkix] TAMP spec

Steve,

Denis

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

	De : pkix-bounces 

	À : pkix 

	Sujet : [pkix] TAMP spec

	Folks,

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Nov 2009 05:56:47 +0900

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

Disagree: it is not helpful to say "here are some possible extensions" when we don't have any general agreement on those extensions. It is also not worth holding up the document while we discuss those extensions.

---

From: Sean Turner <[email-masked]>
Date: Wed, 11 Nov 2009 06:16:35 +0900

> Disagree: it is not helpful to say "here are some possible extensions" when we don't have any general agreement on those extensions. It is also not worth holding up the document while we discuss th…

+1

spt

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 11 Nov 2009 06:38:34 +0900

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" <[email-masked]> 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.
>  
> 
> "I will add some text to the security considerations section describing the
> consequences of losing sequence number state".
> 
>> De : pkix-bounces <mailto%20:[email-masked]>
>> 
>> À : pkix <mailto%20:[email-masked]>
>>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 11 Nov 2009 06:39:55 +0900

Agree with Paul

/Stefan

On 09-11-11 6:16 AM, "Sean Turner" <[email-masked]> wrote:

>> Disagree: it is not helpful to say "here are some possible extensions" when
>> we don't have any general agreement on those extensions. It is also not worth
>> holding up the document while we discuss those extensions.
> 
> +1
> 
> spt

---

From: "Carl Wallace" <[email-masked]>
Date: Tue, 10 Nov 2009 16:54:41 -0500

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:[email-masked]] 
Sent: Wednesday, November 11, 2009 6:39 AM
To: Carl Wallace; [email-masked]; pkix
Subject: Re: [pkix] TAMP spec

Carl,

"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

 

Steve,

Denis

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

Sujet : [pkix] TAMP spec

Folks,

Steve

________________________________

---

From: "Denis Pinkas"<[email-masked]>
Date: Mon, 16 Nov 2009 10:23:18 +0100

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:

“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

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

/Stefan

On 09-11-11 3:23 AM, "Carl Wallace" <[email-masked]> 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.

Steve,

Denis

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

Sujet : [pkix] TAMP spec

Folks,

Steve

---

From: Geoff Beier <[email-masked]>
Date: Mon, 16 Nov 2009 07:35:23 -0500

Hi Denis,

I haven't looked at the rest of your email, but I don't understand
this portion of your commentary:

On Mon, Nov 16, 2009 at 04:23, Denis Pinkas <[email-masked]> wrote:
> 3.5.  RFC 5280 Support
> 3.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.
>

To add constraints to a self-signed certificate, you simply wrap it in
a TrustAnchorInfo structure. This works well. The certificate field of
the CertPathControls structure lets you keep the self-signed
certificate and add your constraints.Other fields of TrustAnchorInfo
can be filled in as part of your store management process.

Regards,

Geoff

---

From: "Carl Wallace" <[email-masked]>
Date: Mon, 16 Nov 2009 08:34:41 -0500

Inline...

From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Monday, November 16, 2009 4:23 AM
To: pkix
Subject: Re: [pkix] TAMP spec

On page 11, we have:

3.5.  RFC 5280 Support

[CW] Obviously this can also be done when the self-signed certificate is created.  As Geoff noted, this can also be done with a wrapper.  It's not clear to me why we'd want to include things in the TA that have no processing semantics but it's certainly possible as it is with RFC 5280.

Stefan said:

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

[CW] This is approach was not "not selected".  It's a method the fits the usage described in the draft.

[CW] As previously discussed, there are no synchronization issues between multiple TA store managers.  There is no denial of service unless you have access to my key. My sequence number has no bearing on messages you generate and vice versa.  

   "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". 
[CW] I do not agree with Russ that this is not a minimal representation.  I agree it need not be minimal since it can contain various information.  In any case, I prefer the existing text, which is historically accurate - the structure was in fact designed to enable expression representations as minimal as key and name.

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

[CW] The differences between these structures are discussed in TAF.

"The functionalities supported by each option are not the same. 

[CW] There is text in TAF that highlights the fact that no additional constraints can be associate with the certificate option but can be with TBSCert and TAI.

Thus, it cannot be used to indicate for which purpose certificates 
from paths terminating to that trust anchor may be used".
[CW] I don't see any reason note this in TAMP.  It's more would be a good fit for an EKU constraints draft, were one to be written.

What does the end of the sentence mean ? A signer is not a trust anchor. 
Please clarify and rephrase.
[CW] See section 6 for a clarification.  As you observe below, sequence number processing is not required when a TAMP message is validated using a certificate instead of a trust anchor.

The end of the sentence is unclear "management or identity trust anchor" ?
[CW] These terms are defined earlier in the draft.  The point here is that apex TAs cannot be changed with this structure.

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

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

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

A final question remains: why can checks be skipped "whenever 
the TAMP message originator is not represented by a trust anchor" ?
[CW] See the first paragraph of section 6.  The primary reason is that it's easier to know when to delete sequence number values for TAs, since they are resident in the store.  It's harder for certificate holders since expiration or deletion may occur independent of the store.

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

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

[CW] See above.  

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

[CW] OK.  I will add "if these messages are logged" to the previous proposed text.

[CW] As noted in previous messages, this is not true.  The only case where this would be true is where the two TA managers are sharing a private key and there is no need to support this scenario.

stores initially managed by the master trust anchor store manager".
[CW] No synchronization is required if they use different private keys.  

Denis

De : Carl Wallace 

	Carl,

	

	/Stefan

	 

	Steve,

	

	

	
	Denis

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

	
	
	Sujet : [pkix] TAMP spec

	Folks,

	
	Steve

---

From: "Denis Pinkas"<[email-masked]>
Date: Fri, 20 Nov 2009 12:45:15 +0100

Carl,

I don't have the time to answer to all the points right now, but I would like to respond to the most important one:

You said:

[CW] There is text in TAF that highlights the fact that no additional constraints can be associate 
with the certificate option but can be with TBSCert and TAI.

draft-ietf-pkix-ta-mgmt-reqs-04 states:

>From 3.5.1 : A trust anchor format MUST

>From 3.6.2 :

  Thus it is important to be able to impose constraints on the
   ways in which a given TA is employed.

>From 3.7.1 :

   A trust anchor format also SHOULD enable the
   representation of constraints that can be applied to restrict the use
   of a trust anchor.

The key point is that CA issue self-signed certificates *without* constraints 
in them, and it is up to the RPs or the TAS managers to decide which constraints
 should be used with a given self-signed certificate. 

These constraints will not be *within* the self-signed certificate but *outside*
 of it. TAMP does not allow supporting this case, but should be able to support it.

Denis

----- Message reçu ----- 
De : Carl Wallace 
À : denis.pinkas,pkix 
Date : 2009-11-16, 14:34:41
Sujet : RE: [pkix] TAMP spec

Inline…

Since it seems that no change will be made to the draft, I believe this limitation should be indicated.
[CW] Obviously this can also be done when the self-signed certificate is created.  As Geoff noted, this can also be done with a wrapper.  It’s not clear to me why we’d want to include things in the TA that have no processing semantics but it’s certainly possible as it is with RFC 5280.

Stefan said:

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.
[CW] This is approach was not “not selected”.  It’s a method the fits the usage described in the draft.

I suggest : 

[CW] I do not agree with Russ that this is not a minimal representation.  I agree it need not be minimal since it can contain various information.  In any case, I prefer the existing text, which is historically accurate – the structure was in fact designed to enable expression representations as minimal as key and name.

[CW] I don’t see any reason note this in TAMP.  It’s more would be a good fit for an EKU constraints draft, were one to be written.

Change proposal:

A final question remains: why can checks be skipped “whenever 
the TAMP message originator is not represented by a trust anchor” ?
[CW] See the first paragraph of section 6.  The primary reason is that it’s easier to know when to delete sequence number values for TAs, since they are resident in the store.  It’s harder for certificate holders since expiration or deletion may occur independent of the store.

“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.
[CW] OK.  I will add “if these messages are logged” to the previous proposed text.

Denis

De : Carl Wallace 

Carl,

/Stefan

Steve,

Denis

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

Sujet : [pkix] TAMP spec

Folks,

Steve

---

From: Geoff Beier <[email-masked]>
Date: Fri, 20 Nov 2009 07:13:41 -0500

Hi Denis,

> of it. TAMP does not allow supporting this case, but should be able to

This is not accurate. To add these constraints to a self-signed
certificate *outside* of it, you use a TrustAnchorInfo structure:

   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 }

pubKey and keyId come from the certificate. The certPath field carries
both the self-signed certificate itself and the constraints you'd like
to impose:

    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}

Other constraints (e.g. CCC) go in the exts field of TrustAnchorInfo.

Regards,

Geoff

---

From: "Carl Wallace" <[email-masked]>
Date: Fri, 20 Nov 2009 07:38:23 -0500

<snip>

The key point is that CA issue self-signed certificates *without*
constraints 
in them, and it is up to the RPs or the TAS managers to decide which
constraints
should be used with a given self-signed certificate. 

[CW] We agree this is the key point - RPs or TAS managers must be able
to decide.  TAF and TAMP provide two ways to accomplish this in your
scenario - removal of the signature with constraints going in the
extensions field of the remaining TBSCertificate structure or wrapping
the entire certificate in a TrustAnchorInfo with constraints going in
CertPathControls or extensions, as Geoff noted.  

These constraints will not be *within* the self-signed certificate but
*outside*
of it. TAMP does not allow supporting this case, but should be able to
support it.

[CW] Right, the constraints are not injected into the self-signed
certificate.  I think it's already been noted in a previous thread that
even if a self-signed certificate is resident in a store, a TAS manager
can add constraints by removing the self-signed certificate and adding
it back as a TBSCertificate or TrustAnchorInfo.  This can be done in
multiple messages or in a single message with the remove operation
appearing before the add operation.  TAMP fully supports this case.

Denis

<snip>

---

From: Thomas Pornin <[email-masked]>
Date: Fri, 20 Nov 2009 14:30:23 +0100

On Fri, Nov 20, 2009 at 12:45:15PM +0100, Denis Pinkas wrote:
> These constraints will not be *within* the self-signed certificate

Where is the problem ? Nobody cares about the certificate to be
_self-signed_ since it is a TA; there is no point in verifying that
signature. Correspondingly, anyone can reencode the certificate with
arbitrary extensions within it; this merely invalidates the signature,
which nobody looks at anyway.

	--Thomas Pornin

---

From: "Denis Pinkas"<[email-masked]>
Date: Mon, 23 Nov 2009 09:21:30 +0100

Responses in lines.
Look for [DP2].

Date : 2009-11-20, 13:38:23
Sujet : Re: [pkix] TAMP spec

<snip>
 
[CW] We agree this is the key point – RPs or TAS managers must be able to decide.  
[DP2] I am glad that you now agree, because in a previous message you said: 
There is text in TAF that highlights the fact that no additional constraints can be associate 
with the certificate option but can be with TBSCert and TAI.
TAF and TAMP provide two ways to accomplish this in your scenario – removal of the signature 
with constraints going in the extensions field of the remaining TBSCertificate structure or 
wrapping the entire certificate in a TrustAnchorInfo with constraints going in CertPathControls 
or extensions, as Geoff noted. 
[DP2] There are several problems with the approach you describe.
a) The need to transform the certificate structure into a TBSCertificate structure 
   is not indicated in the current draft.
b) If one TAS manager fails and another resends the initial configuration, 
   it will resent a self-signed certificate and when about the previous constraints ?
c) The current push approach should not preven to be able to also use a pull approach 
   using RFC 2510. This means that the self-signed certificate structure must be preserved.
d) The current text states on page 21: "  Implementations are not required to support 
   all three options". With the approach you propose, at least two options shall be 
   supported in order to support this functionality. 
It would be however correct to say that "Implementations are not required to support 
all three options".
One of the problem is that none of the three documens dealing with trust anchors 
is giving a definition of what a trust anchor is. It is thus obvious that we do not have 
the same understanding of what a trust anchor is, hence this debate. 
TAMP states on pages 5 & 6:
   A trust anchor contains a public key that is used to validate digital signatures.
   (...) Other information may appear in a trust anchor, including
   certification path processing controls and a human readable name.

The problem is to distinguish between information published by a root CA 
and information added by a RP or a TAS manager.

Currently the documents do not make a difference, but should.

Should we call the first one rootCaInfo (for information published by a root CA )
and the other one LocalConstraints(for information added by a RP or the TAS manager) ?
A change possibility would then be:

TrustPointChoice ::= SEQUENCE {
     rootCAInfo             RootCAInfo,
     localConstraints       LocalConstraints OPTIONAL }
   
RootCAInfo ::= CHOICE {
     certificate               Certificate,
     tbsCert      [1] EXPLICIT TBSCertificate,
     taInfo       [2] EXPLICIT TrustAnchorInfo }
 
LocalConstraints ::= SEQUENCE {
     usages                 Usages           OPTIONAL,
     certPath               CertPathControls OPTIONAL,
     exts      [1] EXPLICIT Extensions       OPTIONAL }
These constraints will not be *within* the self-signed certificate but *outside*
of it. TAMP does not allow supporting this case, but should be able to support it.
[CW] Right, the constraints are not injected into the self-signed certificate.  I think it’s already been noted 
in a previous thread that even if a self-signed certificate is resident in a store, a TAS manager can add constraints 
by removing the self-signed certificate and adding it back as a TBSCertificate or TrustAnchorInfo.  This can be done 
in multiple messages or in a single message with the remove operation appearing before the add operation.  
TAMP fully supports this case.
[DP2] I got the impression that the design is along the following lines:
 "Why make it simple, when it can be complicated" :-) 

Nevertheless the protocol would be prone to errors by mixing information 
that belongs to one structure with information from another structure.
Denis
<snip>

---

From: "Denis Pinkas"<[email-masked]>
Date: Mon, 23 Nov 2009 09:22:21 +0100

Response in-lines.
----- Message reçu ----- 
De : pkix-bounces 
À : pkix 
Date : 2009-11-20, 14:30:23
Sujet : Re: [pkix] TAMP spec

Where is the problem ? Nobody cares about the certificate to be
_self-signed_ since it is a TA; there is no point in verifying that
signature. Correspondingly, anyone can reencode the certificate with
arbitrary extensions within it; this merely invalidates the signature,
which nobody looks at anyway.
CAs which consider themselves to be root CAs currently publish self-signed certificates.
When a self-signed certificate is installed its genuiness must be checked by out-of-bands means, 
e.g. comparing it with a hash value obtained by other means.
Since the data structure is a certificate, its DER encoding should be checked, including the digital signature field and value.
RFC 2510 defines a protocol which allows a smoth transition between trust anchors when self-signed certificates are used.
Denis

  --Thomas Pornin

---

From: "Denis Pinkas"<[email-masked]>
Date: Mon, 23 Nov 2009 09:26:45 +0100

Carl,

Herafter are more detailed answers to your comments.

Look for [DP2].

Inline…
From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Monday, November 16, 2009 4:23 AM
To: pkix
Subject: Re: [pkix] TAMP spec
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 Support
3.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.
[CW] Obviously this can also be done when the self-signed certificate is created.  As Geoff noted, 
this can also be done with a wrapper.  It’s not clear to me why we’d want to include things in the TA 
that have no processing semantics but it’s certainly possible as it is with RFC 5280.
[DP2] See my other email sent earlier today on this topic.
I have provided some text below to address this concern.
=====================================================================
Stefan said:
I think the following text is confusing to a new reader:

[CW] This is approach was not “not selected”.  It’s a method the fits the usage described in the draft.
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).
[CW] As previously discussed, there are no synchronization issues between multiple TA store managers.  
There is no denial of service unless you have access to my key. My sequence number has no bearing 
on messages you generate and vice versa.  
[DP2] I may be may missing a point there, but when only the apex trust anchor 
is used, then it is shared. When you have a backup system you may use the same key 
and should not be forced to use different keys.
1. On page 21, the text says :

 
[CW] I do not agree with Russ that this is not a minimal representation.  I agree it need not be minimal 
since it can contain various information.  In any case, I prefer the existing text, which is historically accurate
– the structure was in fact designed to enable expression representations as minimal as key and name.

[DP2] Anyway, the current text that is in the draft should be changed since it still says: 
   TrustAnchorInfo is intended to serve as a
   minimalist representation of trust anchor information for scenarios
   where storage or bandwidth is highly constrained.
2. Then the text says on the same page:

[DP2] See my comments in the e-mail posted just before that email today.

[DP2] You changed your mind since you wrote this text. 
See my comments in the e-mail posted just before that email today.
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”.

[CW] I don’t see any reason note this in TAMP.  It’s more would be a good fit for an EKU constraints draft, 
were one to be written.
[DP2] I don't believe that a EKU constraints is appropriate to solve this issue, hence why this note is here.
 We need an extension to indicate constraints that apply to the leaf certificates of the certification path. 
It could be called LEKU(Leaf Extended Key Usage).   

[CW] See section 6 for a clarification.  
[DP2] The problem is that my comments apply to page 22 and section 6 is on page 55.
The text on page 22 is not understandable. Even reading page 55, I don't understand 
what this means.   
As you observe below, sequence number processing is not required when a TAMP message 
is validated using a certificate instead of a trust anchor.

[DP2] What you say may be true, but the current text does not allow to understand why.
4. On page 33, the text says :

[CW] These terms are defined earlier in the draft.  
[DP2] I propose to rephrase:

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

The point here is that apex TAs cannot be changed with this structure.
Change proposal:

[CW] See the first paragraph of section 6.  The primary reason is that it’s easier to know when to delete 
sequence number values for TAs, since they are resident in the store.  It’s harder for certificate holders 
since expiration or deletion may occur independent of the store.
[DP2] I still maintain that additional explanations should be given here.

[DP2] Fine. 
[CW] As noted in previous messages, this is not true.  The only case where this would be true 
is where the two TA managers are sharing a private key and there is no need to support this scenario
[DP2] This scenario may be supported when there is a configuration with a back up site. 
Adding these explanations may be useful.

[DP2] As said above, if the same key is used (e.g. from the apex), 
then the comment applies.

/Stefan

Steve,

Denis

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

Sujet : [pkix] TAMP spec

Folks,

Steve

---

From: "Carl Wallace" <[email-masked]>
Date: Mon, 23 Nov 2009 11:15:53 -0500

Denis, 

I don't believe we're covering any new ground in this thread. I will submit a new draft that includes that modified security considerations section somewhere in this thread.

Carl

From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Monday, November 23, 2009 3:27 AM
To: pkix
Subject: Re: [pkix] TAMP spec

Carl,

Look for [DP2].

	Inline...

	On page 11, we have:

	3.5.  RFC 5280 Support

	

	

	

	

	[CW] Obviously this can also be done when the self-signed certificate is created.  As Geoff noted, 
	this can also be done with a wrapper.  It's not clear to me why we'd want to include things in the TA 
	that have no processing semantics but it's certainly possible as it is with RFC 5280.

	Stefan said:

	

	

	I suggest : 

	[CW] I do not agree with Russ that this is not a minimal representation.  I agree it need not be minimal 
	since it can contain various information.  In any case, I prefer the existing text, which is historically accurate
	- the structure was in fact designed to enable expression representations as minimal as key and name.

	

	

	

	
	[CW] I don't see any reason note this in TAMP.  It's more would be a good fit for an EKU constraints draft, 
	were one to be written.

	

	

	

	

	Change proposal:

	

	

	
	[CW] See the first paragraph of section 6.  The primary reason is that it's easier to know when to delete 
	sequence number values for TAs, since they are resident in the store.  It's harder for certificate holders 
	since expiration or deletion may occur independent of the store.

	

	

	[CW] See above.  

[DP2] Fine. 

	

	Denis

	De : Carl Wallace 

		Carl,

		

		/Stefan

		 

		Steve,

		

		

		
		Denis

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

		
		
		Sujet : [pkix] TAMP spec

		Folks,

		
		Steve

---

From: "Denis Pinkas"<[email-masked]>
Date: Mon, 23 Nov 2009 17:36:58 +0100

Carl,

If so, I don't believe that my concerns have been solved.

Denis

----- Message reçu ----- 
De : pkix-bounces 
À : ietf-pkix 
Date : 2009-11-23, 17:15:53
Sujet : Re: [pkix] TAMP spec

Denis, 
I don't believe we're covering any new ground in this thread. 
I will submit a new draft that includes that modified security considerations section somewhere in this thread.
Carl
From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Monday, November 23, 2009 3:27 AM
To: pkix
Subject: Re: [pkix] TAMP spec

Carl,

Look for [DP2].

Inline…

 

De : Carl Wallace 

Carl,

/Stefan

Steve,

Denis

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

Sujet : [pkix] TAMP spec

Folks,

Steve

---

From: Russ Housley <[email-masked]>
Date: Mon, 23 Nov 2009 17:58:52 -0500

Dear PKIX WG Chairs:

>of service in this case).

Please provide a consensus call on this point.  From where I sit, 
Denis is the only person that suggesting that sequence numbers are 
the wrong choice of mechanism.  As best I can tell, Denis is the only 
advocate for a solution where a trust anchor private key is used from 
more than one physical location without coordination, which seems to 
be the justification for proposing an alternate mechanism.  Is there 
rough consensus to proceed with sequence numbers?

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 23 Nov 2009 17:50:03 -0500

Denis:

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

[CW] As previously discussed, there are no synchronization issues between
multiple TA store managers.

There is no denial of service unless you have access to my key. My
sequence number has no bearing

[DP2] I may be may missing a point
there, but when only the apex trust anchor

is used, then it is shared. When you have a backup system you may use the
same key

minimalist representation of trust anchor information for
scenarios

I suggest :

[CW] I do not agree with Russ that this is not a minimal
representation.  I agree it need not be minimal

since it can contain various information.  In any case, I prefer the
existing text, which is historically accurate

– the structure was in fact designed to enable expression representations
as minimal as key and name.

I do not think we should argue about "minimalist" that is the
reason I suggested dropping the word.

I strongly object to the alternate wording that you propose.  It is
neither accurate nor helpful to the reader.

Russ

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 24 Nov 2009 10:18:00 +0100

Dear PKIX WG Chairs:

1 - Russ said: "Denis is the only person that suggesting that sequence numbers are 
the wrong choice of mechanism". 

This is not fully correct. Challenge-response mechanisms would have been much more easy. 
However, nonce mechanisms, if imposed to TAS managers and TA stores would solve the problem.
This means that TA stores would need to have a reasonnably synchronized clock, since in this case 
the nonce would have a part which is derived from UTC. If crypto-devices have a clock, 
then this would be the best solution. If not, there is an alternative as explained below.  

Sequence numbers may still be used, if there is a way to query their current values.
I have proposed a way to query the current sequence numbers (using handles 
that are different from the public key value).  

2 - Russ also said: "Denis is the only advocate for a solution where a trust anchor private key 
is used from more than one physical location without coordination". In case of a disaster, 
there needs to be a Disaster Recovery Plan. With one of the two above solutions, the problem 
is solved without strong synchronization. Otherwise, strong synchronization is required. 

Whatever the final decision will be, this needs to be indicated in the security considerations section.

Denis

----- Message reçu ----- 
De : pkix-bounces 
À : stefans,kent 
Date : 2009-11-23, 23:58:52
Sujet : Re: [pkix] TAMP spec

Dear PKIX WG Chairs:

Denis said:

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

Russ

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 24 Nov 2009 12:56:51 +0100

Denis,

Thank you for the input to the process. Your comments are noted.
We are discussing how to proceed with this issue.

/Stefan

On 09-11-24 10:18 AM, "Denis Pinkas" <[email-masked]> wrote:

>> De  : pkix-bounces <mailto :[email-masked]>
>>  
>> À  : stefans,kent <mailto :[email-masked],[email-masked]>
>>  
>> [email-masked] <mailto: [email-masked]>