Subject: Re: draft-housley-binarytime-00.txt

From: Peter Sylvester <[email-masked]>
Date: Mon, 20 Sep 2004 11:55:43 +0200 (MEST)

> 
> No.  That is not what I meant to say.  I was trying to answer your query 
> about the rule regarding 2050 and signing-time.

I see (at least I hope to).

> 
> Five years ago, there was a debate about the signing-time attribute.  In 
> PKCS#9, it only supports UTCTime.  There was a debate about using the same 
> OID with the construct that includes a GeneralizedTime alternative.  At 
> that time, the decision was to align with RFC 2459.  X.509 was also being 
> updated at roughly the same time.

The situation is different:

Supporting GeneralizedTime in the signedTime attribute is not necessary
before 2050, so you don't have an alternative encoding but a new one
after 2050. It is an upgrade that doe not create backwards compatibility
problems (as far as I see). 

PKCS#9 v2 had been aligned to add generalizedtime, 2?

Your spec creates an alternative encoding for dates, which require
more than a migration, you will need to code both
attributes, always.  

A receiving implementation of the new attributes must be prepared to handle
the two options, i.e. UTCTIME/GT or binary, since on creation you can
use any of them. So in one way or the other, a decoder need some
conversion routine, unless you have made some prior agreement. 

Or, at least I'd remove the non-binary choices from the new attribute,
i.e. use the initial proposition.