Re: proposal for X.509 validity period

[Mark Bartel <mbartel@xxxxxxxxxxxx>]

I agree with Bob here (as evidenced my own similar suggestion) that we 
should move to v4 and specify just GeneralizedTime for the validity dates. 
 Several people have advised against advancing the version number; I must 
admit I don't understand the problems alluded to.

To more clearly articulate the problem I perceive:

With a CHOICE in v3, there is no DER (or whatever the X.509 version of 
those rules is called) encoding of the certificate.  There are a number of 
encodings that are possible; to verify the certificate, you must keep track 
of which encoding was used in the first place instead of just keeping track 
of the values of the fields.  This complicates matters significantly; I 
don't see this as a minor matter.  The whole point of DER encoding the 
certificate was to ensure that there was only one possible representation. 
 Moving to v4 and specifying GeneralizedTime (with X.690 DER for the 
encoding of the GeneralizedTime) avoids adding any more problems than X.509 
already has here.

Since the CRL definition needs to be fixed as well, I would think changing 
the version number (for both) makes even more sense.

And perhaps we could even specify X.690 DER instead of the short list in 
X.509, and disambiguate further, although I admit to being ignorant of any 
additional ramifications that change might have.  Since UTCTime is the only 
ambiguous X.509 type encoding I can think of at the moment, there might be 
no need for this.

How does keeping the version number at 3 simplify matters such that it is 
worth losing the above simplification?

(I realize that we could specify rules for when to use UTCTime such that 
there is a distinguished encoding, but it would also be more complicated 
than moving to v4.)

- Mark Bartel (mbartel@magmacom.com)

Bob Jueneman wrote:

>Maybe the simplest approach would be to progress to v4, and
>simply change the definition of validity to be expressed in
>generalizedTime only.  The use of v1, v2, and v3  for notBefore
>dates after 1 January 2000 would be strongly deprecated.
>The (minor) complexity caused by CHOICE would be avoided.
>
>CAs could offer their customers a choice of v3 and v4
>certificates until the demand for v3 certificates subsides
>sufficiently.
>
>Implementations would be strongly encouraged (by competitive
>pressure) to support the most current version, v4, but they could
>also continue to use v3, handling notBefore and notAfter dates
>as explicitly 2000 + N, so as not to perpetuate this into the next
>century. (We can probably defer support for 10,000AD until v5+
>with relatively little risk. :-)
>
>With this scheme, the CRL format would also advance to v3,
>supporting generalizedTime only.
>
>I haven't thought about this too much, but would it be reasonable
>to suggest that v3 certs be rejected with a v3 CRL, and v4 certs
>in a v3 CRL, publishing two CRLs in two different formats until
>all of the v3 certs have either expired or been revoked?
>
>How many implementations are yet handling CRLs at all?  I think
>perhaps very few??? Maybe the CRL processing could jump to
>v3 immediately??
>
>Maybe CHOICE is more appropriate here? This obviously needs
>some more thought.
>
>Bob
>
>
>
>Robert R. Jueneman
>Security Architect
>NetWare Security R&D
>Internet Infrastructure Division
>Novell, Inc. M/S-PRV-D241
>122 East 1700 South
>Provo, UT 84606
>801/861-7387
>
>>>> <H.Kesterson@az05.bull.com> 10/14/96 05:58am >>>
>In two weeks I will be chairing a directory meeting where one of the 
agenda
>items is to process defect reports. I would like to see a consensus on 
this
>problem so that I can get a technical corrigendum approved and maybe get 
that TC
>
>incorporated in the published edition. The procedure is defect report 
being
>accepted; writing a draft technical corrigendum containing the corrective 
text;
>
>submitting the DTC to a three month ballot; processing the national body 
 and
>liaison organization votes and comments; if the resulting text is 
acceptable
>producing the Technical Corrigendum; and finally incorporating that TC 
into the
>
>next published edition of the standard.
>
>[snip]
>
>
>>I believe the choice of methods come down to three
>
>>1) replace the UTCTime encoding with GeneralizedTime. As this would not 
only
>invalidate current implementations, but also currently issued 
certificates, this
>
>is not an acceptable solution.
>
>Assuming that we progress to v4, at the same time,  I believe that this IS
>and acceptable solution.
>
>>2) replace the current encoding with a CHOICE encoding of both UTCTime 
and
>GeneralizedTime. This would invalidate current implementations but not 
currently
>
>issued certificates. As mentioned, I don't believe that a new version 
would help
>
>interoperability. The only way that this would be acceptable is to get 
agreement
>
>that implementations would adopt this new encoding in their implementation 
right
>
>away. We have done this before. In fact this is the definition of normal 
defect
>
>resolution. The resulting Technical Corrigendum fixes an error and each
>implementation should incorporate that TC as quickly as possible. Where 
there is
>
>significant implementation interest, the defect resolution group has 
liaised
>with the implementation groups. Normally, this would be the implementor
>workshops. However, in this case I would also expect the blessing of at 
least
>also the PKIX and SET groups.
>
>Option 2 would be my second choice.
>
>>3) generate a new extension that has the validity date encoded in
>GeneralizedTime. This would not necessarily invalidate implementations. 
That
>would depend on whether or not an implementation could successfully 
process
>year 2000 and greater dates encoded in UTCTime. That is, if one did not 
mandate
>
>the understanding of the extension, e.g. via the critical flag, the 
encoder
>would still have encode the date in the existing Validity field and 
receivers
>would have to understand some sort of wrap rule.
>
>>I would like to make the following recommendation. I don't see the value 
of
>method three. Implementors would have to support both the extension and 
the wrap
>
>around rule for the existing Validity element. Unless we mandate support 
of the
>
>extension. If we are going to mandate anything, I recommend method two.
>
>Agreed. Option 3 seems really ugly. I wouldn't like to see the now-useless 
>UTCTime attribute carried around forever.
>
>>Although implementations would have to change, method two could turn out 
to be
>
>the cleanest. I suggest we implement the CHOICE (I don't believe a new 
version
>would help, but then it couldn't hurt). To keep it simple, I further 
suggest
>that we not adopt any wrap around rule. That is, the current UTCTime 
Validity
>field could only be used for dates that are before 1 January 2000. I also
>suggest that we don't mix the two forms. That is, if the notAfter value is 
after
>
>31 December 1999, both it and the notBefore value shall be encoded in
>GeneralizedTime even though the notBefore value is prior to 1 January 
2000.
>
>The only question is whether there are already certificates in existence
>that have notAfter dates that are post-2000, and/or a substantial number 
of
>certificates with three + year validity periods will have to be issued in 
1997.
>
>
>Bob
>
>
>
>