Subject: RE: X.509 Extensions Enhancements

From: "Tom Gindin" <[email-masked]>
Date: Thu, 28 Jun 2001 11:47:51 -0400

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.
     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.

          Tom Gindin

"Carlin Covey" <[email-masked]> on 06/28/2001 11:24:03 AM

To:   "Tom Gindin" <[email-masked]>
cc:   "David A. Cooper" <[email-masked]>, <[email-masked]>
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:[email-masked]]
Sent: Wednesday, June 27, 2001 7:52 PM
To: Carlin Covey
Cc: David A. Cooper; [email-masked]
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" <[email-masked]>@mail.imc.org on 06/27/2001 09:20:36 PM

Sent by:  [email-masked]

To:   "David A. Cooper" <[email-masked]>, <[email-masked]>
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: [email-masked]
     [mailto:[email-masked]]On Behalf Of David A. Cooper
     Sent: Wednesday, June 13, 2001 6:44 AM
     To: [email-masked]
     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

---

From: Phil Griffin <[email-masked]>
Date: Thu, 28 Jun 2001 13:37:49 -0400

> 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.

> 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