Re: X.509 Extensions Enhancements

"David P. Kemp" <dpkemp@missi.ncsc.mil> Thu, 28 June 2001 18:47 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 OAA13160 for <pkix-archive@odin.ietf.org>; Thu, 28 Jun 2001 14:47:28 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5SI0tS16009 for ietf-pkix-bks; Thu, 28 Jun 2001 11:00:55 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5SI0sm16004 for <ietf-pkix@imc.org>; Thu, 28 Jun 2001 11:00:54 -0700 (PDT)
Message-ID: <200106281758.NAA21300@stingray.missi.ncsc.mil>
Date: Thu, 28 Jun 2001 13:56:57 -0400
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
CC: ietf-pkix@imc.org
Subject: Re: X.509 Extensions Enhancements
References: <KHEDLMGGCCGHDAAKNAFOEEOFCAAA.ccovey@cylink.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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

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