Subject: Requested change for 2459

From: Robert Moskowitz <[email-masked]>
Date: Mon, 04 Oct 1999 14:45:34 -0400

Change to validityDate Choice rule:

Background:

in 

4.1.2.4  Issuer

We set a 'flag date' of 1/1/2004:

   The DirectoryString type is defined as a choice of PrintableString,
   TeletexString, BMPString, UTF8String, and UniversalString.  The
   UTF8String encoding is the preferred encoding, and all certificates
   issued after December 31, 2003 MUST use the UTF8String encoding of
   DirectoryString (except as noted below).  Until that date, conforming
   CAs MUST choose from the following options when creating a
   distinguished name, including their own:

Then in

4.1.2.5  Validity

we set a very indeterminant date with:

   CAs conforming to this profile MUST always encode certificate
   validity dates through the year 2049 as UTCTime; certificate validity
   dates in 2050 or later MUST be encoded as GeneralizedTime.

So sometime around 2040 or earlier, long-live root certs will start
appearing using GeneralizedTime, long after most of us are out of this
business.  I propose the following change to 4.1.2.5:

   CAs conforming to this profile MUST always encode certificate
   validity dates using GeneralizedTime for all certificates
   issued after December 31, 2003.  Y2K proccessing of UTCTime will
   assume century 19 if UTCTime is greater than 49 and century 20 if
   UTCTime is less than 50.

This gives PKIX one clear flag date for both UTF8String and GeneralizedTime
support.

It also makes sure that all of the programmers and product managers are
still around to answer to any failures....

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

---

From: Russ Housley <[email-masked]>
Date: Mon, 04 Oct 1999 13:13:45 -0400

Bob:

The use of SIZE (1..MAX) says that zero items are not allowed, just one or 
more.  Thus, when zero is a possibility, OPTIONAL means that the item 
should be absent if there are zero items.

By using these two together, there is only one legal way to represent zero 
items.  Our intent was to reduce complexity by not admitting multiple ways 
to include zero items.

Dave:

The use of NULL parameters with several algorithms has to do with the way 
that they were registered.  When the 1988 syntax for AlgorithmIdentifier 
was translated to the 1997 syntax, the OPTIONAL associated with the 
parameters got lost.  Later, via a defect report, it was recovered.  So, 
many people thought that algorithm parameters were mandatory.  If algorithm 
parameters were mandatory and there was nothing useful to include, NULL is 
a reasonable selection.

Russ

At 09:24 AM 9/30/99 -0400, Robert Moskowitz wrote:
>At 05:10 PM 9/29/1999 -0400, Robert Moskowitz wrote:
> >What is the difference between the following two structures:
> >
> >::= SEQUENCE SIZE (1..MAX) OF
> >
> >::= SET OF
> >
>Thank you all of you that answered.
>
>In 2459, SET seems to be used only in Name things.  SEQUENCE SIZE is used
>most of the time, and it always starts with 1..
>
>But some of them are 'optional':
>
>         policyQualifiers   SEQUENCE SIZE (1..MAX) OF
>                                 PolicyQualifierInfo OPTIONAL }
>
>
>Again this is a bit confusing to the casual reader.  The only LOGICAL
>interpretation is a SEQUENCE of SIZE 0 is different in the cert than not
>present and this is desireable.  OK.
>
>Some of this stuff is wicked.
>
>
>Robert Moskowitz
>ICSA