RE: X.509 Extensions Enhancements

"Hoyt L. Kesterson II" <hoytkesterson@earthlink.net> Wed, 13 June 2001 18:25 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28858 for <pkix-archive@odin.ietf.org>; Wed, 13 Jun 2001 14:25:03 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5DHcsC00548 for ietf-pkix-bks; Wed, 13 Jun 2001 10:38:54 -0700 (PDT)
Received: from phnxpop5.phnx.uswest.net (pop.phnx.uswest.net [206.80.192.5]) by above.proper.com (8.11.3/8.11.3) with SMTP id f5DHcrJ00543 for <ietf-pkix@imc.org>; Wed, 13 Jun 2001 10:38:53 -0700 (PDT)
Received: (qmail 75391 invoked by uid 0); 13 Jun 2001 17:35:28 -0000
Received: from akdialup82.phnx.uswest.net (HELO ?10.0.1.23?) (63.225.200.82) by pop.phnx.uswest.net with SMTP; 13 Jun 2001 17:35:28 -0000
Date: Wed, 13 Jun 2001 10:30:18 -0700
Message-Id: <a0510030bb74d5227dd7b@[10.0.1.23]>
From: "Hoyt L. Kesterson II" <hoytkesterson@earthlink.net>
To: "David A. Cooper" <david.cooper@nist.gov>, ietf-pkix@imc.org
Mime-Version: 1.0
X-Sender: hoytkesterson@mail.earthlink.net
In-Reply-To: <4.2.2.20010613091011.00b51650@email.nist.gov>
References: <5.1.0.14.2.20010612141554.02c05020@pobox1.bbn.com> <5.0.1.4.2.20010612120440.02009ef8@exna07.securitydynamics.com> <5.1.0.14.2.20010612141554.02c05020@pobox1.bbn.com> <4.2.2.20010613091011.00b51650@email.nist.gov>
Subject: RE: X.509 Extensions Enhancements
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
Content-Transfer-Encoding: quoted-printable

RE: X.509 Extensions Enhancements
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 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