[Top] [All Lists]

Re: draft-housley-binarytime-00.txt

2004-09-20 02:55:53

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.  


<Prev in Thread] Current Thread [Next in Thread>