Re: X.509 Extensions Enhancements

[Phil Griffin <[e-mail]>]

Tom,

You nailed it perfectly. Allowing trailing zero bits
does not lead to a "distinguished" encoding. Arbitrary
numbers of trailing zero bits is a BER feature, as it 
allows a sender more than one way to encode the same 
value.

Whether or not a given bit appears in a named bit list
is not a consideration. There is no indication whatsoever
in a BER/DER encoding that a bit has a name or not in
some ASN.1 type definition. 

And ASN.1 does not require that all bits that are 'used'
have a name. ASN.1 allows you to create bit string types
such as 

   Bits ::= BIT STRING { skipSomeBits (2) }

which leaves the leading bits 'used' but not 'named'. 

Though these leading bits are 'unassigned bits' with no
name, they must be present in a BER/DER encoding that 
carries the named bit 'skipSomeBits'. So it is not 
possible for leading bits to participate in some sort
of three value logic - such notions do not generalize
well.

And there is no loss of extensibility using DER (X.690).
Unconstrained bit strings such as 'Bits' are inherently
extensible. There is no size limit imposed by this ASN.1
type definition, no matter how many bits are named or
not.

Named bits in a type definition do carry semantics for 
human readers. So, they have a role in the XER encoding
rules and the new ASN.1/XML value notation. 

With the type definition 

   WorkDays ::= BIT STRING {
      monday    (1), 
      tuesday   (2),
      wednesday (3),
      thursday  (4),
      friday    (5)
   } 

a user might specify a value of WorkDays as

   <WorkDays> 0101 </WorkDays>

or, using the named bits, as

   <WorkDays> <monday/> <wednesday/> </WorkDays>

Looking at the text in X.680 will not tell you how to
encode a distinguished value. The text in X.680 must be
general enough to support, not just BER and DER, but all
possible encoding rules. This includes new ones such as
the XER rules written long after the words in X.680. 

It is X.690 that defines DER by restricting the rules
for BER. Though it may be a difficult read, X.690 is not
ambiguous on how to encode a bit string in one and only
one way. But some may find it easier to digest one of
the books at http://www.nokalva.com/asn1/booksintro.html.

Phil


Tom Gindin wrote:
> 
>      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