RE: X.509 Extensions Enhancements

"Carlin Covey" <ccovey@cylink.com> Thu, 28 June 2001 21:13 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 RAA26179 for <pkix-archive@odin.ietf.org>; Thu, 28 Jun 2001 17:13:48 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5SKLG625279 for ietf-pkix-bks; Thu, 28 Jun 2001 13:21:16 -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 f5SKLGm25275 for <ietf-pkix@imc.org>; Thu, 28 Jun 2001 13:21:16 -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 M4HJBYHJ; Thu, 28 Jun 2001 13:19:57 -0700
From: Carlin Covey <ccovey@cylink.com>
To: "David P. Kemp" <dpkemp@missi.ncsc.mil>
Cc: ietf-pkix@imc.org
Subject: RE: X.509 Extensions Enhancements
Date: Thu, 28 Jun 2001 13:22:02 -0700
Message-ID: <KHEDLMGGCCGHDAAKNAFOOEONCAAA.ccovey@cylink.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <200106281758.NAA21300@stingray.missi.ncsc.mil>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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: 7bit

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: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of David P. Kemp
Sent: Thursday, June 28, 2001 10:57 AM
Cc: ietf-pkix@imc.org
Subject: Re: X.509 Extensions Enhancements



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