Re: Federal Profile

Russ, and David,

Your explanation at least provides an understandable motivation,
although I'm not sure that I am convinced that sticking to a single 
transition period won't cause more harm than good..  But perhaps more
importantly, you have highlighted what I have to believe is a 
fundamental flaw in X.500, as I understand it.

If certificates are transferred in BER formats opposed to DER, then 
errors in translating from one restricted from to a general format and then
back again are almost guaranteed to show up. Time is merely one example -- 
character encoding variations are going to be far, far worse, especially 
since not all applications follow the "rules".And I haven't even begun 
to consider all of rest of the various CHOICE fields, or whether DEFAULT 
becomes an issue -- even with the "standard" X.509 and PKIX fields, 
much less any proprietary extensions.

And as Brian Kovar pointed out, all of the sequencing information 
has to be carried along as well.

Transporting certificates in BER encoding is a brain-dead approach,
it seems to me, and virtually guarantees a multiplicity of problems.

If this is required, or even permitted by X.500, I think a defect report is
in order. And if applications are doing it, God help them.

But in any case, since all of the various CHOICE instances are ALL
going to have to be handled by encoding what choice was used, somehow, 
this doesn't seem to be a sufficient reason to insist on one and only 
one encoding for time, given the lessons we are learning  regarding
the Y2K problem.

Bob

>>> Russ Housley <housley@xxxxxxxxxx> 08/11 8:04 PM >>>
David:

Yes, you understand my concern.

Bob:

Many implementations decode to structures.  For example, an implementation
might store the UTCTime an GeneralizedTime as binary value that is
comparable with their operating system.  If an implementation looses the
typing in their structure (does not know if the date was carried in a
UTCTime or GeneralizedTime), then the year will tell them which type to use
if they need to re-encode the data.  Re-encoding happens quite often since
certificates are often transferred with BER, and the signature validation
requires DER.

Russ

At 06:01 PM 8/10/98 +0100, David Boyce wrote:
>"Bob Jueneman" writes:
>
>>I agree that there must only be one DER encoding for a particular 
>attribute.
>>
>>But I see nothing wrong with allowing either GeneralizedTime or UTCTime
>>as a way of encoding time.  That's what CHOICE is all about, 
>presumably.
>
>I rather think Russ desires a one-to-one value-to-encoding mapping for
>ease of use in applications.  Allowing a pre-2050 Validity member to be
>encoded as GeneralisedTime would break this (since there would be 2
>valid encodings for the date).
>
>To check my understanding here, I'm stating the consequence of your
>statement in easy steps.
>
>1) A properly formed CHOICE construct (such as Validity) may be
>unambiguously encoded using DER.
>
>2) If the Validity date can only be expressed as GeneralisedTime, there
>is no problem with choosing an encoding CHOICE.
>
>3) If the date can be validly expressed as either UTCTime or
>GeneralisedTime, then it need not matter which encoding CHOICE you make 
>to
>generate the certificate, since there will be a single DER form for that
>value, depending on its tag.
>
>4) When re-encoding for verification, however, it is not sufficient to
>rely on the date's value alone in order to determine which CHOICE was
>used, since the value might validly be expressed in either form, and to
>choose the wrong form would invalidate the signature unnecessarily.
>
>5) Consequently it remains important to remember which CHOICE member was
>used in the original encoding of the structure.
>
>So, the reason one might want to enforce a single cutover is for the
>convenience of the application, to permit it not to have to record the
>CHOICE of the Validity members.  Depending on the application, this may
>or may not be a good thing.
>
>The applications I handle could quite easily be adapted to note the form
>of the original encoding, but that may not be so easy for others.
>
>>Having only binary choices tends to force flash cutovers, and that is 
>NEVER a
>>good thing, in my experience.
>
>Agreed.
>
>>
>>Bob
>>
>>>>> Russ Housley <housley@xxxxxxxxxx> 08/07 1:24 PM >>>
>>Bob:
>>
>>I have no problems with testing the GeneralizedTime aspects of the
>>certificate code.  Heck, it seems like a very good idea to shake it our
>>long before it becomes an operational issue.
>>
>>My concern is that we have a distinguished encoding for dates.  There 
>must
>>be onel and only one way to correctly encode any particular date value.
>>
>>Russ
>>
>>At 01:35 PM 8/7/98 -0400, Robert Moskowitz wrote:
>>>At 09:47 AM 8/6/98 -0400, Russ Housley wrote:
>>>>
>>>>Since there is no ambiguity, I do not understand why you are 
>concerned.
>>>>Given any date between 1-Jan-1950 and 31-Dec-9999, the pecification
>>>>provides one (and only one) way to encode the date.  I think that is
>>>>technically correct and responsible.
>>>
>
>-- 
>David Boyce
>
>Tel:   +44 181 332 9091                Richmond, Surrey, ENGLAND
>I'net: d.boyce@xxxxxxxxx       Isode's WWW: http://www.isode.com/ 
>X.400: I=d;S=boyce;P=isode;A=mailnet;C=fi;
>