Subject: X.509 Extensions Enhancements

From: "Housley, Russ" <[email-masked]>
Date: Tue, 12 Jun 2001 12:18:09 -0400

I have just been made aware that the most recent X.509 includes two 
additional reason codes.  This impacts the reasons in the CRL Distribution 
Points certificate extension and the onlySomeReasons in the Issuing 
Distribution Point CRL extension.  Both of these fields use the ReasonFlags 
type.  It also impacts the Reason Code CRL entry extension, which uses the 
CRLReason type.  I have provided the new definitions below.

    ReasonFlags ::= BIT STRING {
         unused                  (0),
         keyCompromise           (1),
         cACompromise            (2),
         affiliationChanged      (3),
         superseded              (4),
         cessationOfOperation    (5),
         certificateHold         (6),
         privilegeWithdrawn      (7),
         aACompromise            (8) }

    CRLReason ::= ENUMERATED {
         unspecified             (0),
         keyCompromise           (1),
         cACompromise            (2),
         affiliationChanged      (3),
         superseded              (4),
         cessationOfOperation    (5),
         certificateHold         (6),
         removeFromCRL           (8),
         privilegeWithdrawn      (9),
         aaCompromise           (10) }

The Issuing Distribution Point CRL extension has also been enhanced to 
include a boolean that indicates whether the CRL contains only entries 
associated with attribute certificates.  The new definition is:

    IssuingDistributionPoint ::= SEQUENCE {
         distributionPoint          [0] DistributionPointName OPTIONAL,
         onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
         onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
         onlySomeReasons            [3] ReasonFlags OPTIONAL,
         indirectCRL                [4] BOOLEAN DEFAULT FALSE,
         onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }

The original OIDs are still being used with these "enhanced" definitions, 
therefore I will be adding them to son-of-rfc2459.

Russ

---

From: "Carlin Covey" <[email-masked]>
Date: Tue, 12 Jun 2001 10:43:50 -0700

Russ,

Thank you for pointing this out.  I had seen the flags in X.509 but
didn't realize that they had not been incorporated into "son".

But I have a comment concerning the DER encoding of the named bit string.
Some people interpret X.680/690 as requiring that the DER encoding
omit trailing zeros from such a named bit string.  I (with some concurrence
from the X.509 folks) believe that this is an error.  X.680/690 say that
trailing UNUSED bits are to be omitted.  Bits (7) and (8) WERE unused,
and certificates issued in ignorance of the newly defined bits should
omit them.  But certificates issued in cognizance of the newly defined bits
should include these bits as either 1 or 0, as appropriate.  If relying
party
applications assume that omitted trailing bits have a value of 0, these
applications cannot discern between a CA that knows that the privilege is
still good and that the Attribute Authority is not compromised, from a CA
who hasn't a clue about either.

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

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Housley, Russ
Sent: Tuesday, June 12, 2001 9:18 AM
To: [email-masked]
Subject: X.509 Extensions Enhancements

Russ

---

From: "Charles W. Gardiner" <[email-masked]>
Date: Tue, 12 Jun 2001 14:21:52 -0400

At 10:43 AM 6/12/2001 -0700, Carlin Covey wrote:

>omit them.

     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

>  But certificates issued in cognizance of the newly defined bits

---

From: Dean Povey <[email-masked]>
Date: Wed, 13 Jun 2001 10:31:41 +1000

>trailing UNUSED bits are to be omitted.  

I am pretty sure it says to omit trailing zeros in bit fields, this means
that the DER in old implementations and new implementations will be the
same as it should be (although there are a very large number of vendors who
get this wrong and include trailing zeros (particularly in the KeyUsage 
extension.  If you are being strict about DER then you probably can't 
interoperate with anyone anyway :-).

But I'll restrain myself from grumbling about changing an extension syntax
and not changing the OID. This will break so many old implementations
unecessarily because while they could safely ignore non-critical extensions
that they don't understand, they are probably going to complain if they
parse extensions they recognise and find they contain data they don't
expect.

Oops, that wasn't showing much restraint was it :-).

-- 
Dean Povey,         | e-m: [email-masked] | JCSI: Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI: C PKI toolkit for embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |       systems
Brisbane, Australia | www: security.dstc.com |

---

From: "Hoyt L. Kesterson II" <[email-masked]>
Date: Wed, 13 Jun 2001 00:29:16 -0700

from clause 7 of x.509

If unkown elements appear
within the extension, and the extension is not marked critical, those
unknown elements shall be ignored according to the rules of
extensibility documented in 7.5.2.2 in ITU-T Rec. X.519 | ISO/IEC
9594-5.

hoyt

At 10:31 AM +1000 6/13/01, Dean Povey wrote:

>trailing UNUSED bits are to be omitted.

I am pretty sure it says to omit trailing zeros in bit fields, this
means

that the DER in old implementations and new implementations will be
the

same as it should be (although there are a very large number of
vendors who

get this wrong and include trailing zeros (particularly in the
KeyUsage

extension.  If you are being strict about DER then you probably
can't

But I'll restrain myself from grumbling about changing an extension
syntax

and not changing the OID. This will break so many old
implementations

unecessarily because while they could safely ignore non-critical
extensions

that they don't understand, they are probably going to complain if
they

parse extensions they recognise and find they contain data they
don't

expect.

--

Dean Povey,         | e-m:
[email-masked] | JCSI: Java Crypto Toolkit

Research Scientist  | ph:  +61 7 3864 5120   |
uPKI: C PKI toolkit for embedded

Security Unit, DSTC | fax: +61 7 3864 1282
|       systems

---

From: "Hoyt L. Kesterson II" <[email-masked]>
Date: Wed, 13 Jun 2001 00:39:06 -0700

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: Bodo Moeller <[email-masked]>
Date: Wed, 13 Jun 2001 10:08:14 +0200

On Tue, Jun 12, 2001 at 10:43:50AM -0700, Carlin Covey wrote:

> should include these bits as either 1 or 0, as appropriate.

I have no idea how one could read this out of X.680 and X.690.

X.680 (12/97), section 21.7, says

     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.

X.690 (12/97), section 11.2.2, says

     Where ITU-T Rec. X.680 | ISO/IEC 8824-1, 21.7, applies, the
     bitstring shall have all trailing 0 bits removed before it is
     encoded.

(Section 11 is entitled "Restrictions on BER employed by both CER
and DER", section 11.2 is entitled "Unused bits".)

This looks pretty clear to me: Trailing zeros in named bit strings
are forbidden in DER, period.

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 13 Jun 2001 09:43:45 -0400

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 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: "Hoyt L. Kesterson II" <[email-masked]>
Date: Wed, 13 Jun 2001 10:30:18 -0700

hi david

named bits are used bits. unused bits are unassigned bits. x509
does not refer to 681 der.

this is a problem i have raised many times. the fact is that 509
has bit strings encoded differently and for a reason. the asn.1
document does not adequately support bit string extensibility. i would
also like to point out her that the 509 rules were developed first.
the 681 rules were supposed to be a duplicate of them but i suspect
that they wanted an improvement. fyi, the cer rules were the first
rules the asn.1 group came up with. they developed cer because i
yelled about the mandating of using indefinite length encoding for all
structures.

the 681 encoding does not allow one to assign a bit which when
recognized is interpreted to do either function a or b. in other
words, 509 allows three states: not recognizing the named bit (i.e.
not recognizing the function), choice a of the function signalled by
the bit being zero, choice b of the function signalled by the bit
being one.

681 allows only two states for bits at the end of the string -
not indicated (because the string length is set to exclude the bit) or
set to one

this messes up extensibility. it has not effected the work so far
because the value assigned to the zero value is the same as the bit
not being interpreted

i recently discussed this problem with tim. i suggest you talk
with him.

hoyt

At 9:43 AM -0400 6/13/01, David A. Cooper wrote:

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

Paragraph 11.2.2 of

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 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: Bodo Moeller <[email-masked]>
Date: Thu, 14 Jun 2001 01:21:34 +0200 (CEST)

Hoyt L. Kesterson II <[email-masked]>:

> named bits are used bits. unused bits are unassigned bits. x509 does
> not refer to 681 der.
               ^^^^^^^
Do you mean X.690?  [Note that  X.680 + (X.209 - X.208) = X.690  :-) ]

Indeed it seems that X.509 does not refer to X.690 Distinguished
Encoding Rules (although the abbreviation DER is used in the ASN.1
definitions for HASH and ENCRYPTED-HASH and thus indirectly for
SIGNATURE and SIGNED).

In any case, X.509 says that X.690 Basic Encoding Rules apply with
certain restrictions, and section 8.6.2.4 of X.690 says

     Where ITU-T Rec. X.680 | ISO/IEC 8824-1, 21.7 applies [i.e. when
     a "NamedBitList" is used in defining a bitstring type ASN.1; --bm],
     a BER encoder/decoder can add or remove trailing zero bits from
     the value.

Adding or removing such trailing zero bits does not appear to be
forbidden by X.509, so the warning of X.680 section 21.7 should
still apply:
     
     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 encoders may not be really required to remove trailing zeros
from bitstrings types defined by NamedBitLists, at least removing
these zeros or adding zeros should not affect the interpretation.
Thus, any unused bits are implicitly zero.

Note that according to X.690, trailing zeros may be removed or added
even if the type definition uses a SIZE constraint (which is not the
case for the bitstring types defined in X.509).  In this case,
*abstract* values would have to be written with the appropriate number
of binary digits (unless they are written using IdentifierList
notation); but the SIZE constraint does not affect BER *encodings*.
(Cf. section 8.6.2.4 and note 1 in section 11.2.2 of X.690.)

---

From: "Carlin Covey" <[email-masked]>
Date: Wed, 27 Jun 2001 17:57:58 -0700

Bodo,

Sorry to be so late in responding, but I've been on vacation.

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

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.

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

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: Bodo Moeller [mailto:[email-masked]]
Sent: Wednesday, June 13, 2001 1:08 AM
To: Carlin Covey
Cc: Housley, Russ; [email-masked]
Subject: Re: X.509 Extensions Enhancements

--
Bodo Möller <[email-masked]>
PGP
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

---

From: "Carlin Covey" <[email-masked]>
Date: Wed, 27 Jun 2001 18:20:36 -0700

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

          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 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: Bodo Moeller <[email-masked]>
Date: Thu, 28 Jun 2001 11:48:35 +0200 (CEST)

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

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

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

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.

---

From: "Carlin Covey" <[email-masked]>
Date: Thu, 28 Jun 2001 10:42:00 -0700

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:[email-masked]]
Sent: Thursday, June 28, 2001 2:49 AM
To: [email-masked]
Cc: Carlin Covey
Subject: Re: X.509 Extensions Enhancements

the

According to 21.11,

explain why
entitled
bits

---

From: "Carlin Covey" <[email-masked]>
Date: Thu, 28 Jun 2001 10:44:15 -0700

Bodo,

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

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

the

According to 21.11,

explain why
entitled
bits

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 28 Jun 2001 13:56:57 -0400

Carlin,

"... rules are free to add (or remove) ..." is merely a statement of fact
concerning an arbitrary set of encoding rules, including encodings currently
undefined.  The important part is the recommendation derived from that fact:

   "Application designers should therefore ensure that different
    semantics are not associated with such values which differ
    only in the number of trailing 0 bits."

This prohibits tri-state logic.  Assume version 1 of a data item includes
three named bits (A,B,C) and version 2 includes five (A,B,C,D,E).  A version
2 decoder receives the value "100" (created by a v1 encoder using your
interpretation) and the value "10000" (created by a v2 encoder).  These
values have differing number of trailing 0 bits, but they must mean the
same thing.  The application cannot say "E is unknown" for the first
value and "E is definitely 0" for the second.

I believe David Cooper's logic is that because the number of trailing 0's
must be irrelevant to the semantics, the only rational distinguished encoding
is to delete them all.

An additional point:
    "ASN.1 encoding rules are free to remove arbitrarily many
     trailing 0 bits from values that are being encoded or decoded."

If this were only talking about adding trailing bits, you could argue that
there is a meaningful distinction between 0's which are within the named bit
list and those which are appended by the encoder.  But since it discusses
removing 0's, those removed can only be within the named bit list.  Therefore
the number of named bits is not communicated by any encoding, and there can
be no distinction between appended trailing 0's and trailing named bits whose
value is 0.

Dave K.

Carlin Covey wrote:
> 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

---

From: "Carlin Covey" <[email-masked]>
Date: Thu, 28 Jun 2001 13:22:02 -0700

David,

I am persuaded that X.680 & X.690 do intend the "delete all
trailing zeros" interpretation, despite the ambiguities in
crucial sentences.

I appreciate your taking the time to respond to my posting.
You have stated your position well, and I think you have probably
captured the essence of David's logic.

However, it seems to me that any agreed-upon number of trailing
zeros would have served the purposes of DER.  I agree
that the shortest such bit string is more rational than longer
encodings.  By the way, Bodo and Tom have both pointed out that the
last bit must be a 1, so the final bit (and indeed any string of 1's
at the end) is redundant if you know the number of bits that are
represented in the encoding.  It may have been possible to create
a shorter encoding that was incrementally more rational.  ;>)

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of David P. Kemp
Sent: Thursday, June 28, 2001 10:57 AM
Cc: [email-masked]
Subject: Re: X.509 Extensions Enhancements

Carlin,

I believe David Cooper's logic is that because the number of trailing 0's
must be irrelevant to the semantics, the only rational distinguished
encoding
is to delete them all.

An additional point:

If this were only talking about adding trailing bits, you could argue that
there is a meaningful distinction between 0's which are within the named bit
list and those which are appended by the encoder.  But since it discusses
removing 0's, those removed can only be within the named bit list.
Therefore
the number of named bits is not communicated by any encoding, and there can
be no distinction between appended trailing 0's and trailing named bits
whose
value is 0.

Dave K.

> Despite my not being able to follow your logic, I don't dispute the fact
that
> However,  I do maintain that the wording is ambiguous concerning whether
these
> after the NamedBitList.  That is, "values that are being encoded" could
refer

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 28 Jun 2001 17:49:15 -0400

>captured the essence of David's logic.

Yes. The way that I read X.680, when dealing with a NamedBitList, all of the following bit strings must have the same meaning:

10110000
1011
10110
101100000000000000000000000000000000000000000000000
1011000000000

Since they all have the same meaning, we must select one as the "distinguished" encoding for all of them.

>encodings.

I suppose the rule could be "include the minimum number of trailing zeros necessary to make the length of the bit string a multiple of 8", but the simplest rule is just to require that all trailing zeros be removed.

>By the way, Bodo and Tom have both pointed out that the

Perhaps, but X.509 requires a distinguished encoding that is also a BER encoding. I suppose we could define a set of distinguished packed encoding rules and then specify an X.509 version 4 that used those rules, but doing so wouldn't be very rationale. :-)

Dave