Re: X.509 Extensions Enhancements

[Phil Griffin <[e-mail]>]

Tom Gindin wrote:
> 
>      IMHO, that subsection title (11.2 of X.690) is unfortunate.  It
> should, by analogy with subsections 11.1 and 11.3, be "Bit String values".
> Phil, what do you think?  The title of section 11.2 clearly applies to
> 11.2.1 almost perfectly but is much less obviously applicable to 11.2.2.

Given that "11.2 Unused bits" appears between clauses 
named "11.1 Boolean values" and "11.3 Real values" I 
would tend to agree that its title would be more 
consistent as "11.2 Bit string values".

There is currently a revision of the standards underway
which will merge the base documents with amendments and
corrected defects. This process happens every four years
or so. It is starting this time with the 1998 version as
base. 

Unless you wish to do so yourself, I'd be happy to propose
this as a defect and solution. Note that you can view the
defect reports and resolutions on the web by going to the
http://asn1.elibel.tm.fr/en/standards/defect-reports/ site
maintained by the ITU-T Rapporteur.

Just above this page is information on what has changed
since your 1994 version of the standards. For details 
see http://asn1.elibel.tm.fr/en/standards/index.htm.

Notice on this page the link to "ASN.1 Project". The 
ITU is currently amassing all of the ASN.1 modules in all
of their standards and will soon place these on the web
for free in a human readable format that can be processed
by machines. These free modules are in the process of
being syntax checked before being made available.

>      On a similar topic, does section 11 have a subsection for UTCTime in
> the most recent version?  In '94, it has GeneralizedTime but not UTCTime.
> If I had to guess, I would assume that time zone always being "Z" applies
> to UTCTime and the rule about midnight's hour being 0 of the coming day
> rather than 24 of the ending day does so as well.

In the trial merged version of the standards, the following
appears in X.690. This seems to be what you're after, and must
have been added as the result of a defect against the 1994
version of X.690: 

11.8  UTCTime

11.8.1 The encoding shall terminate with "Z", as described 
       in the ITU-T X.680 | ISO/IEC 8824-1 clause on UTCTime.

11.8.2	The seconds element shall always be present.

11.8.3	Midnight (GMT) shall be represented in the form:

   "YYMMDD000000Z"

   where "YYMMDD" represents the day following the midnight
   in question.

11.8.4	Examples of valid representations

   "920521000000Z"
   "920622123421Z"
   "920722132100Z"

11.8.5	Examples of invalid representations

   "920520240000Z"  (midnight represented incorrectly)
   "9207221321Z"    (seconds of 00 omitted)

Phil



>           Tom Gindin
> 
> "Carlin Covey" <[e-mail]> on 06/28/2001 11:24:03 AM
> 
> To:   "Tom Gindin" <[e-mail]>
> cc:   "David A. Cooper" <[e-mail]>, <[e-mail]>
> Subject:  RE: X.509 Extensions Enhancements
> 
> Tom, you raise a good point.  I had overlooked that note.
> That certainly presents a counter example to my interpretation.
> 
> But I'm still a bit puzzled.  Is there no significance to
> the fact that this text appears in a section entitled "Unused bits"?
> 
> Regards,
> 
> Carlin
> 
> ____________________________
> 
> -  Carlin Covey
>    Cylink Corporation
> 
> -----Original Message-----
> From: Tom Gindin [mailto:[e-mail]]
> Sent: Wednesday, June 27, 2001 7:52 PM
> To: Carlin Covey
> Cc: David A. Cooper; [e-mail]
> Subject: RE: X.509 Extensions Enhancements
> 
>      Carlin:
> 
>      Your argument would be more convincing if it weren't for note 2 to
> section 11.2.2 of X.690 (I'm using the '94 version), which strictly limits
> the length of an encoding with no 1 bits ("If a bitstring value has no 1
> bits then an encoder shall encode the value with a length of 1 and an
> initial octet set to 0"), without consideration of the number of bits in
> the named bit list.  The stuff you quoted from X.680 is applicable to BER
> (the original one of the encodings, after all) rather than DER.
> 
>           Tom Gindin
> 
> "Carlin Covey" <[e-mail]>@mail.imc.org on 06/27/2001 09:20:36 PM
> 
> Sent by:  [e-mail]
> 
> To:   "David A. Cooper" <[e-mail]>, <[e-mail]>
> cc:
> Subject:  RE: X.509 Extensions Enhancements
> 
> David,
> 
> Perhaps I'm still a bit jet-lagged from my vacation, but I don't follow
> your logic.  How does the text that
> says the "...rules are free to add (or remove) ..."  lead to your
> conclusion that the only rational DER is
> to delete all trailing zeros?
> 
> Despite my not being able to follow your logic, I don't dispute the fact
> that all trailing zeros should be deleted.
> However,  I do maintain that the wording is ambiguous concerning whether
> these trailing zeros begin within or
> after the NamedBitList.  That is, "values that are being encoded" could
> refer to NamedBitList's rather than to
> bits within a NamedBitList.
> 
> Regards,
> 
> Carlin
> 
> ____________________________
> 
> -  Carlin Covey
>    Cylink Corporation
> 
>      -----Original Message-----
>      From: [e-mail]
>      [mailto:[e-mail]]On Behalf Of David A. Cooper
>      Sent: Wednesday, June 13, 2001 6:44 AM
>      To: [e-mail]
>      Subject: RE: X.509 Extensions Enhancements
> 
>      Hoyt,
> 
>      I could not find anything in X.509 that specifies how to encode named
>      bit lists. However, as Bodo Möller pointed out, X.680 treats bit
>      strings differently when it includes a named bit list. The text that
>      Bodo quoted is also in section 19.7 of the 1994 edition of X.680:
> 
>              When a "NamedBitList" is used in defining a bitstring type
>      ASN.1 encoding rules
>              are free to add (or remove) arbitrarily many trailing 0 bits
>      to (or from) values that are
>              being encoded or decoded. Application designers should
>      therefore ensure that different
>              semantics are not associated with such values which differ
>      only in the number of trailing 0 bits.
> 
>      So, while it seems that X.509 does not specify how to encode bit
>      strings that use a "NamedBitList", I believe that the above text
>      allows for only one rational distinguished encoding rule: remove all
>      trailing 0 bits. Since this is the rule specified by X.690 for DER
>      encoding ("Where [a "NamedBitList" is used in defining a bitstring
>      type], the bitstring shall have all trailing 0 bits removed before it
>      is encoded."), I believe it is appropriate for X.509 to adopt this
>      rule. Since the PKIX certificate and CRL profile simply specifies the
>      use of the DER encoding rules, there would be no need to make any
>      changes in PKIX.
> 
>      Carlin Covey suggests that the number of used/unused bits in a named
>      bit list could be used to convey extra information:
> 
>              The newly added bits have three values: true, false, and
>      omitted. Omitted indicates that
>              the CA has no opinion about the value of these flags (probably
>      because the certificate
>              was issued or the CA software was written prior to these bits
>      being defined).
> 
>      But as the quotes above show, this is not only inconsistent with DER
>      but also with any "legal" encoding rules for named bit lists.
> 
>      Dave
> 
>      At 12:39 AM 6/13/01 -0700, Hoyt L. Kesterson II wrote:
>                    Paragraph 11.2.2 of X.690 states that, for named bit
>                strings (paragra[h 19.7 of X.680) all trailing zero bits
>                must be removed before encoding.  Paragraph 11.2.1, which
>                refers to bit strings of either kind, speaks of unused bits
>                in the final octet being zero.  I believe the specific case
>                for named bit strings trumps the general case.
> 
>                Charlie Gardiner
> 
>           from clause x in 509
> 
>           In order to enable the validation of SIGNED and SIGNATURE types
>           in a distributed environment, a distinguished encoding is
>           required. A distinguished encoding of a SIGNED or SIGNATURE data
>           value shall be obtained by applying the Basic Encoding Rules
>           defined in ITU-T Rec. X.690 (1997) | ISO/IEC 8825 :1998, with the
>           following restrictions: In order to enable the validation of
>           SIGNED and SIGNATURE types in a distributed environment, a
>           distinguished encoding is required. A distinguished encoding of a
>           SIGNED or SIGNATURE data value shall be obtained by applying the
>           Basic Encoding Rules defined in ITU-T Rec. X.690 (1997) | ISO/IEC
>           8825 :1998, with the following restrictions:
> 
>           in the list of restrictions is
> 
>           In order to enable the validation of SIGNED and SIGNATURE types
>           in a distributed environment, a distinguished encoding is
>           required. A distinguished encoding of a SIGNED or SIGNATURE data
>           value shall be obtained by applying the Basic Encoding Rules
>           defined in ITU-T Rec. X.690 (1997) | ISO/IEC 8825 :1998, with the
>           following restrictions:
> 
>           509 says to encode according to the rules in 509. the x.680 DER
>           rules were written later than those in x.509. in the case of bit
>           string, the rules are different. the rules in x.680 do not permit
>           extensibility in a bit string. the rules in 509 do.
> 
>              hoyt