RE: X.509 Extensions Enhancements

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

Bodo,

Thank you for your thoughtful reply.  The points that you and Tom
raised do sway the argument in favor of the "delete all trailing
zeros" interpretation.

I do disagree on some additional points, but the foregoing makes
my disagreement somewhat academic.

I did note this sentence: "Application designers should ensure that
different semantics are not associated with such values which differ
only in the number of trailing 0 bits."  This appears to be an
admonition to the designers of the decoding application, but I
can see that it could also be interpreted as a similar admonition
to the designers of the encoding application.  In either case,
this argues against the tri-value logic interpretation only if
the phrase "trailing 0 bits" applies to 0-valued bits within
the NamedBitList, as opposed to 0-valued bits that follow the
NamedBitList.

I disagree that a bit is "unused" if it happens to be set to 0 rather
than 1.  Relying Party applications are supposed to reject a key usage
associated with a bit in KeyUsage whose value is set to 0.  Rejecting
a key usage seems like as much a use of the bit as accepting the key usage.

I disagree that "all previous encodings of values suddenly become invalid"
under my interpretation.  In fact, the previous encodings are more valid,
because the decoding application can distinguish between an "intended 0
value" and an "no opinion" value.  Based upon this knowledge, the decoding
application can take some appropriate action.  The action could be to
assume a safe default (which is the only option under the "delete trailing
zeros" interpretation), or the action could be to reject the NamedBitList
(and perhaps the certificate it rode in on).

But, as I said earlier, this is somewhat academic in view of the fact that
X.680 and X.690 appear to favor the "delete trailing zeros" interpretation.

Thanks again for your thoughtful reply.

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation


-----Original Message-----
From: Bodo Moeller [mailto:[e-mail]]
Sent: Thursday, June 28, 2001 2:49 AM
To: [e-mail]
Cc: Carlin Covey
Subject: Re: X.509 Extensions Enhancements


Carlin Covey <[e-mail]> in epsilon.ietf-pkix:

> My rationale for my trailing zeros interpretation is this:
>
> (1) X.680 and X.690 are ambiguously worded.
> (2) The deletion of trailing 0 bits is associated with "unused bits."
> (3) The "delete all trailing zeros" interpretation inhibits extensibility.

> Re (1):  Here's why X.680 is ambiguously worded:
>
> X.680 could have said "... encoding rules are free to concatenate
> arbitrarily
>      many trailing 0 bits to the NamedBitList, and are free to truncate
any
>      trailing zeros following the NamedBitList"
>
> or X.680 could have said "... encoding rules are free to concatenate
> arbitrarily
>      many trailing 0 bits to the NamedBitList, and are free to truncate
any
>      trailing zeros within or following the NamedBitList"
>
> Instead X.680 says  "... encoding rules are free to add (or remove)
> arbitrarily
>      many trailing 0 bits to (or from) values that are being encoded or
>      decoded."
>
> The current wording is briefer, but allows for either interpretation
(since the
> "values that are being encoded" is a bit string that may contain 0 bits at
the
> trailing end).

X.680 section 21.7 says that

      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 ensure that different
      semantics are not associated with such values which differ only
      in the number of trailing 0 bits.

Especially note the second sentence!

According to 21.11,

     The "BitStringValue" notation denotes a bitstring value with ones
     in the bit positions specified by the numbers corresponding to he
     "identifier"s, and with all other bits zero.

This indeed ambiguous -- what are "all other" bits?  Just those bits
that exist according to the underlying NamedBitList definition, or
arbitrarily many bits?  If we look at 21.6, we see that

      The presence of a "NameBitList" has not effect on the set of
      abstract values of this type.  Values containing 1 bit other
      than the named bits are permitted.

So the type is not limited to the number of bits that are "used"
by the NamedBitList definition.  Also see the example at the end
of section 21:

     [...]  If the type was defined using a "NamedBitList", the
     (single) trailing zero does not form part of the value [...].
     If the type was defined without a "NamedBitList", the trailing
     zero does form part of the value [...].


> X.690 is similarly ambiguous:
>
> It says "the bitstring shall have all trailing 0 bits removed before it is
> encoded." but doesn't specify whether the trailing 0 bits to be removed
> include those within the bitstring, or only those that follow the
bitstring
> (i.e. the 0 bits that X.680 said could be added arbitrarily).

X.690 references the definition of "trailing bit" given in X.680.
("The first bit in a bit stringg is called *bit zero*.  The final bit
in a bit string is called the *trailing bit*.")  The plural (trailing
bits) is not explicitly defined, but it would be strange if there
was a "trailing bit" which is zero and yet is not part of the
"trailing 0 bits", which could happend according to your
interpretation.

> Re (2):  Note that the "delete all trailing 0's" interpretation doesn't
explain why
> X.690 section 11.2.2 should be included within section 11.2, which is
entitled
> "Unused Bits."  My interpretation does explain this.  Deleting trailing 0
bits
> applies only to the "unused bits" that follow the NamedBitList.

Actually, both interpretations would justify speaking of "unused
bits".

In the "delete all trailing 0's" interpretation, all trailing zeros of
NamedBitList values are "unused" because they are not relevant for the
value being encoded (cf. the example in section 21, quoted above).


> Re (3): I won't repeat the extensibility argument that appeared in my
email
> of June 12.

Actually, both interpretations inhibit extensibility (in different ways).
If a "NamedBitList" is ever extended, then

- with the "delete all trailing 0's" interpretation, you cannot tell
  from the encoding whether a bit has intentionally been set to 0
  or whether it did not have a meaning to the entity generating the
  value.

- with your interpretation, all previous encodings of values suddenly
  become invalid.

The first problem is not a problem if "NamedBitList"s are extended
only such that it makes sense for new bits to default to zero --
i.e., such that tri-state logic is not required.

Also note that with your interpretation, applications would still be
allowed to *add* zero bits to bit strings, which runs counter to
you extensibility arguments.


I won't argue that the wording of the X.680 and X.690 specifications
is quite ambiguous.  However, I think the examples (in particular, the
example at the end of section 21) make clear which meaning is the
intended one.  Thus, the trailing bit of a DER-encoded NamedBitString
whose length is non-zero always must be a 1.



--
Bodo Möller <[e-mail]>
PGP
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]