RE: X.509 Extensions Enhancements
"Carlin Covey" <ccovey@cylink.com> Thu, 28 June 2001 18:30 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 OAA01550 for <pkix-archive@odin.ietf.org>; Thu, 28 Jun 2001 14:30:14 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5SHfGT14291 for ietf-pkix-bks; Thu, 28 Jun 2001 10:41: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 f5SHfFm14286 for <ietf-pkix@imc.org>; Thu, 28 Jun 2001 10:41:15 -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 M4HJBXF4; Thu, 28 Jun 2001 10:39:56 -0700
From: Carlin Covey <ccovey@cylink.com>
To: Bodo Moeller <moeller@cdc.informatik.tu-darmstadt.de>, ietf-pkix@imc.org
Subject: RE: X.509 Extensions Enhancements
Date: Thu, 28 Jun 2001 10:42:00 -0700
Message-ID: <KHEDLMGGCCGHDAAKNAFOCEOMCAAA.ccovey@cylink.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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: <m15FYPb-000QdtC@epsilon>
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>
X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id f5SHfGT14291
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA01550
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:moeller@cdc.informatik.tu-darmstadt.de] Sent: Thursday, June 28, 2001 2:49 AM To: ietf-pkix@imc.org Cc: Carlin Covey Subject: Re: X.509 Extensions Enhancements Carlin Covey <ccovey@cylink.com> in epsilon.ietf-pkix: > 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.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 [...]. > 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). 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 > applies only to the "unused bits" that follow the NamedBitList. 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 > of June 12. 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. -- Bodo Möller <moeller@cdc.informatik.tu-darmstadt.de> 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
- X.509 Extensions Enhancements Housley, Russ
- RE: X.509 Extensions Enhancements Carlin Covey
- RE: X.509 Extensions Enhancements Charles W. Gardiner
- Re: X.509 Extensions Enhancements Dean Povey
- Re: X.509 Extensions Enhancements Hoyt L. Kesterson II
- RE: X.509 Extensions Enhancements Hoyt L. Kesterson II
- Re: X.509 Extensions Enhancements Bodo Moeller
- RE: X.509 Extensions Enhancements David A. Cooper
- RE: X.509 Extensions Enhancements Hoyt L. Kesterson II
- Re: X.509 Extensions Enhancements Bodo Moeller
- RE: X.509 Extensions Enhancements Carlin Covey
- RE: X.509 Extensions Enhancements Carlin Covey
- RE: X.509 Extensions Enhancements Tom Gindin
- Re: X.509 Extensions Enhancements Bodo Moeller
- Re: X.509 Extensions Enhancements Phil Griffin
- RE: X.509 Extensions Enhancements Carlin Covey
- RE: X.509 Extensions Enhancements Tom Gindin
- RE: X.509 Extensions Enhancements Carlin Covey
- RE: X.509 Extensions Enhancements Carlin Covey
- Re: X.509 Extensions Enhancements Phil Griffin
- RE: X.509 Extensions Enhancements Carlin Covey
- Re: X.509 Extensions Enhancements David P. Kemp
- Re: X.509 Extensions Enhancements Phil Griffin
- RE: X.509 Extensions Enhancements Carlin Covey
- RE: X.509 Extensions Enhancements David A. Cooper