RE: X.509 Extensions Enhancements

"Carlin Covey" <ccovey@cylink.com> Thu, 28 June 2001 02:07 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28854 for <pkix-archive@odin.ietf.org>; Wed, 27 Jun 2001 22:07:21 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5S1Jt704904 for ietf-pkix-bks; Wed, 27 Jun 2001 18:19:55 -0700 (PDT)
Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5S1Jsm04900 for <ietf-pkix@imc.org>; Wed, 27 Jun 2001 18:19:54 -0700 (PDT)
Received: from COVEY (cpe-24-221-22-222.az.sprintbbd.net [24.221.22.222]) by exchange.cylink.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M4HJB4AY; Wed, 27 Jun 2001 18:18:35 -0700
From: Carlin Covey <ccovey@cylink.com>
To: "David A. Cooper" <david.cooper@nist.gov>, ietf-pkix@imc.org
Subject: RE: X.509 Extensions Enhancements
Date: Wed, 27 Jun 2001 18:20:36 -0700
Message-ID: <KHEDLMGGCCGHDAAKNAFOEEOFCAAA.ccovey@cylink.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01C0FF35.DCA20890"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <4.2.2.20010613091011.00b51650@email.nist.gov>
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>

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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org]On
Behalf Of David A. Cooper
  Sent: Wednesday, June 13, 2001 6:44 AM
  To: ietf-pkix@imc.org
  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