Subject: Re: Successor to RFC 3280?

From: Denis Pinkas <[email-masked]>
Date: Fri, 09 Apr 2004 17:16:21 +0200

Steve,

This is an additional change proposal to the successor to RFC 3280.
We are currently deprecating the use of the private key usage period.

4.2.1.4  Private Key Usage Period

    This extension SHOULD NOT be used within the Internet PKI.  CAs
    conforming to this profile MUST NOT generate certificates that
    include a critical private key usage period extension.

I have been advocating this in the past, while being (too much) focussed on 
keys for human beings: it is not possible to prevent a human being to use 
his private key beyond that date.

However, if this key is placed within a(n evaluated) security module that 
has a secure clock, it possible to make sure that the security module 
prevents the use of the private key beyond the expiration date (e.g. the key 
can be zeroized). This is fully pertinent for time-stamping modules which 
must have a clock synchronised with UTC.

Thus I would propose to allow and even recommend the use of this extension 
for keys located in security modules that have a secure clock, in particular 
time-stamping modules, where it is possible to enforce this control.

Denis

> I have heard some folks say that we should have
> a successor to RFC 3280 (and 3279) and some folks
> say that we shouldn't. I'd like to raise this topic
> for discussion on the PKIX list to settle this matter.
> 
> I believe that an update to RFC 3280 is necessary
> for two reasons. First, some minor problems have
> been found during implementation and deployment
> (mostly typos and clarifications). These should
> be fixed so that future implementors don't have
> to suffer through them. Second, we are almost ready
> for RFC 3280 to progress to Draft Standard status.
> In order to do this, it must be revised. So I
> believe that an update to RFC 3280 (and 3279)
> should be undertaken.
> 
> HOWEVER, I think it is essential for us to limit
> the scope of this update. We should not add features
> to the spec or make substantial changes, especially
> changes that would break compatibility with RFC 3280.
> The scope of the update should be limited to
> "clarifying and correcting the document in light
> of implementation experience".
> 
> That's my perspective on this important matter.
> I would like to hear other perspectives and
> opinions so that we can arrive at a rough working
> group consensus on this.
> 
> Thanks,
> 
> Steve
> 
> P.S. I have a list of typos and clarifications
> that need to be fixed in the next version of
> RFC 3280. If we decide to proceed with a revision,
> I'll forward it to the editor and cc the PKIX list.

---

From: "todd glassey" <[email-masked]>
Date: Fri, 9 Apr 2004 10:22:49 -0700

----- Original Message ----- 
From: "Denis Pinkas" <[email-masked]>
To: "Steve Hanna" <[email-masked]>
Cc: "PKIX List" <[email-masked]>
Sent: Friday, April 09, 2004 8:16 AM
Subject: Re: Successor to RFC 3280?

>     include a critical private key usage period extension.

yes I agree - and IMHO this use of time as part of the keying validation
model clearly violates the Glassey-McNeil Patent's use claims.

> must have a clock synchronised with UTC.

No Denis it is not. It is possible to say that "this use conforms to this
recommendation" but there in fact is no way with today's technologies to
stop anyone from doing anything that they want to with SW systems. So... the
issues for time stamping systems that must be synchronized with UTC services
are just a recommendation and we wont talk about this use's violation (in my
opinion) of my patent rights in the Datum Controlling Access to Stored
Information Patent.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 9 Apr 2004 13:24:44 -0400

Denis,

Good point. It might make sense to say that this extension is 
reasonable under such circumstances.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 9 Apr 2004 14:48:03 -0400

>model clearly violates the Glassey-McNeil Patent's use claims.

Todd, you were warned by Russ to not bring this issue up on PKIX anymore.

One more time and I'll have to ask Paul Hoffman to revoke your 
posting privileges.

Steve

---

From: Tim Polk <[email-masked]>
Date: Thu, 22 Apr 2004 11:21:06 -0400

Steve,

I believe we have WG consensus that a successor to 3280 is an appropriate 
work item.  In light of the controlled shutdown of PKIX is, I believe the 
scope must be limited to the task of progressing to Draft Status.  That 
means we will need to remove those features that do not have two 
implementations, and clarify any errors and inconsistencies.  Any other 
work needs to be performed in separate documents (and probably needs to 
progress as a personal draft.)

I am volunteering David Cooper from NIST to act as lead editor for the 
successor to 3280.  He was a key contributor, particularly with respect to 
the path validation algorithm, in the development of 3280 itself and has 
been a key player in the interoperability testing.

In addition, David participated in the revisions to the ISO specification 
which leaves us well positioned to maintain the consistency of the ISO and 
IETF documents.

Thanks,

Tim Polk