RE: X.509 Extensions Enhancements

["Carlin Covey" <[e-mail]>]

Phil, I concede Tom's point (see my previous email).

And I agree that allowing an arbitrary number of trailing
zero bits is not a DER feature.  However my interpretation
did not involve allowing an arbitrary number.  It involved
encoding exactly the number of bits in the NamedBitList,
regardless of the value of the individual bits.

Yes, I agree that it is not possible for unused bits
to participate in the three-valued logic unless these
bits are at the trailing end of the NamedBitList.  But
the trailing end of the NamedBitList is where newly-defined
Boolean flags are added.

I also agree that the bit string can be extended even using
the "delete all trailing zeros" interpretation.  The issue
is in the application's interpretation of newly added bits.
An application that has been written after some additional
bits were defined in a new version of the standard may encounter
a DER-encoded NamedBitList that was created before these
additional bits were defined.  Under the "delete all trailing
zeros" interpretation, the application cannot determine whether
the issuer of the NamedBitList intended these additional bits
to be 0, or whether the issuer was ignorant of the definition
of these additional bits.  This is the extensibility issue.
The only way out of it with the "delete all trailing zeros"
interpretation is to ensure that the 0 value is a safe default
for all newly defined bits.  This would work OK, unless the
bits must be set in combination with other bits.

I do agree with you that X.690 is a hard read, but I disagree
that it is unambiguous.  Reading the interpretations that appear
in other books may indeed be helpful, but it introduces another
layer of interpretation between the reader and the actual standard.

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: Phil Griffin [mailto:[e-mail]]
Sent: Thursday, June 28, 2001 6:11 AM
To: Tom Gindin
Cc: Carlin Covey; David A. Cooper; [e-mail]
Subject: Re: X.509 Extensions Enhancements


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