Subject: Re: [pkix] WGLC for TAMP

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

Russ,

So you agree that it might be useful. So let us add it in the structure rather than, as you propose, trying to use some extension mechanism.

I got the impression the protocol is completly frozen and that no change, whatever it is is, is acceptable.

If some people want to make available a protocol to the IETF community, you can use the INFORMATIONAL track.
When using the STANDARDS track, the protocol can be changed, even at WG LC.

I do not agree with you when you say that the APEX anchor shall not expire.
It would be a bd practice to maintain it for yeras. It would be a pity to ahve a protocol managemeing TAI and unavble to change teh APEX trust anchor.

As you know, RFC 2510 allows to gracefully change any APEX trust anchor. It uses self-signed certificates.
An APEX trust anchor can be defined using a self-signed certifiacte and thus always includes a validity period.

Denis

----- Message reçu ----- 
De : Russ Housley 
À : denis.pinkas 
Date : 2009-10-29, 15:12:45
Sujet : Re: [pkix] WGLC for TAMP

Denis:

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

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

for non-apex trust anchors. 

[Denis] So you  agree that it should be there, at least as OPTIONAL. 
This means that all the three choices should be able to have a time period.

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

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

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

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

Russ

---

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

The wrong key was hit, before the message was polished.

Here it is again.

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

Russ,

So you agree that it might be useful. So let us add it in the structure rather than, as you propose, 
trying to use some extension mechanism.

I do not agree with you when you say that the APEX anchor shall not expire.
It would be a bad practice to maintain it for years. It would be a pitty to have a protocol managing TAI and 
unable to change the APEX trust anchor.

As you know, RFC 2510 allows to gracefully change any APEX trust anchor using the certificates NewWithNew
and NewWithOld. It uses self-signed certificates. An APEX trust anchor can be defined using a self-signed certificate 
and thus always includes a validity period.

Denis

----- Message reçu ----- 
De : Russ Housley 
À : denis.pinkas 
Date : 2009-10-29, 15:12:45
Sujet : Re: [pkix] WGLC for TAMP

Denis:

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

Russ

---

From: "Carl Wallace" <[email-masked]>
Date: Mon, 2 Nov 2009 06:14:00 -0500

Inline...

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

Russ,

[CRW] You should use the diff tools on the IETF site.  It's been just over two weeks since a change (addition of the language tag field) was made to the structure you are referencing.  The change was a result of a suggestion made during IESG last call.  There were also changes resulting from working group last call and many changes over the two plus years these specs have been before the working group.  

[CRW] As noted elsewhere in these threads, the inputs to the 5280 algorithm do not include the validity period from the trust anchor.  I don't disagree with the notion that validity (and extended key usages) could be useful in a trust anchor.  The problem is that 5280 does not require processing the existing values.  New extensions are needed for these purposes.  

Denis

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

	De : Russ Housley 

	À : denis.pinkas 

	Denis:

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

	
	Russ

---

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

Due to backward compatibility reasons, I agree that in order to enforce expiry on a trust anchor, a new extension should be used.  You can even enforce that this value be same as that in the validity period.  You can also call it to be critical if you want existing implementations to enforce the extension.
 
Right around when 5280 was in last call, I mentioned on this list the need to enforce validity period and stating something regarding this in the security consideration section of the revision to 5280.  In order to maintain backward compatibility, that is the best we can do.

________________________________

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

	Inline...

	Russ,

	Denis

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

		De : Russ Housley 

		À : denis.pinkas 

		Denis:

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

		
		Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 02 Nov 2009 16:11:27 -0500

Denis:

>So you agree that it might be useful. So let us add it in the 
>structure rather than, as you propose, trying to use some extension mechanism.

I said that I see cases where it might be useful, but it is also 
harmful for Apex Trust Anchors, so no, I do not agree that it should 
go in the base structure.

>I do not agree with you when you say that the APEX anchor shall not expire.

I do not think it is appropriate for the Apex trust anchor to 
expire.  Instead it should be actively replaced, avoiding the 
possibility of there being no valid Apex Trust Anchor.

>It would be a bd practice to maintain it for yeras. It would be a 
>pity to ahve a protocol managemeing TAI and unavble to change teh 
>APEX trust anchor.

The protocol already includes mechanisms to replace the Apex trust anchor.

>  As you know, RFC 2510 allows to gracefully change any APEX trust 
> anchor. It uses self-signed certificates.
>An APEX trust anchor can be defined using a self-signed certifiacte 

You do not seem to be using the same definition for Apex trust 
anchor.  The concept did not yet exist when RFC 2510 was written.

Russ