Subject: RE: WG last call - DER-encoded BIT STRING for IPAddress

From: "Manger, James H" <[email-masked]>
Date: Mon, 8 Sep 2003 10:22:38 +1000

Jim,

Trailing zeros are NOT removed when DER-encoding a BIT STRING, unless it is a "NamedBitList".  Hence they are not removed when DER-encoding a value of the IPAddress type in draft-ietf-pkix-x509-ipaddr-as-extn-01.txt.

ITU-T X.690 | ISO/IEC 8825-1 : 1994 "BER, CER & DER":

11.2.2 Where ITU-T Rec. X.680 | ISO/IEC 8824-1 clause 19.7 applies, the bitstring shall have all trailing 0 bits removed before it is encoded.

ITU-T X.680 | ISO/IEC 8824-1 : 1994 "ASN.1":

19.7 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.

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]
Sent: Sunday, 7 September 2003 2:59 PM
To: 'Stephen Kent'; [email-masked]
Subject: RE: WG last call

Steve,

I have finally figured out what was lying in the back of my mind and
screaming at me.

The element IPAddress cannot be DER encoded.  If you take a bit string
and DER encode it, you will automatically remove all trailing zeros as
these are assumed not to contain information.  However with IPAddress,
the trailing zeros do contain information. 

The element IPAddress cannot be BER encoded.  An implemeantion can DER
encode a bitstring and still claim full compliance to the BER
specification.

I cannot see how this draft can possibly progress without changing the
basic type of IPAddress.

jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jim Schaad
> Sent: Friday, September 05, 2003 5:35 PM
> To: 'Stephen Kent'; [email-masked]
> Subject: RE: WG last call
> 
> 
> 
> Steve,
> 
> Here are my comments on the draft.
> 
> 1.  I don't understand doing a draft to define private 
> extensions.  This is the phrase used in the abstract.used in 
> the message.
> 
> 2.  I have a complete lack of understanding on how the IP 
> adresses are to be encoded.  Either a section on this needs 
> to be added or a reference to this needs to be place in the document.
> 
> 3.  There is no ASN.1 module but this document defines new 
> items.  (At least there is no tagging so I don't need to know 
> explicit vs implicit.)
> 
> Jim
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Stephen Kent
> > Sent: Tuesday, August 19, 2003 7:02 PM
> > To: [email-masked]
> > Subject: WG last call
> > 
> > 
> > 
> > Folks,
> > 
> > We have a relatively old ID that was reposted in June, after minor
> > changes in response to some previous comments. The document defines 
> > two proposed extensions, one to carry IP address prefix 
> data and one 
> > to carry Autonomous System Identifier info, in PK certs. The 
> > extension was developed to enable creation of a PKI that 
> reflects the 
> > assignment of IP addresses and AS numbers, which happens to be done 
> > in a top down, singly rooted tree fashion, starting with IANA. The 
> > document is draft-ietf-pkix-x509-ipaddr-as-extn-01.txt.
> > 
> > I would like to initiate a 2-week WG last call on this ID. There are
> > now a couple of protocols that could make use of this extension in 
> > different contexts and so it would be good to have it as another, 
> > completed PKIX item.
> > 
> > Since I am a co-author of the document, I will recuse 
> myself from the
> > process of determining WG consensus in this case, and rely 
> on Tim to 
> > deal with any issues that may arise.
> > 
> > Steve
> > 
>

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 12 Sep 2003 21:44:44 -0700

I withdraw my objection on this issue.  I still think that some
clarification language on how IPAddresses are encoded makes sense.

jim

> [mailto:[email-masked]] On Behalf Of Manger, James H
> Sent: Sunday, September 07, 2003 5:23 PM
> To: [email-masked]
> Subject: RE: WG last call - DER-encoded BIT STRING for IPAddress
> 
> 
> 
> Jim,
> 
> Trailing zeros are NOT removed when DER-encoding a BIT 
> STRING, unless it is a "NamedBitList".  Hence they are not 
> removed when DER-encoding a value of the IPAddress type in 
> draft-ietf-pkix-x509-ipaddr-as-extn-01.txt.
> 
> 
> 
> 11.2.2 Where ITU-T Rec. X.680 | ISO/IEC 8824-1 clause 19.7 
> applies, the bitstring shall have all trailing 0 bits removed 
> before it is encoded.
> 
> 19.7 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.
> 
> 
> I have finally figured out what was lying in the back of my 
> mind and screaming at me.
> 
> The element IPAddress cannot be DER encoded.  If you take a 
> bit string and DER encode it, you will automatically remove 
> all trailing zeros as these are assumed not to contain 
> information.  However with IPAddress, the trailing zeros do 
> contain information. 
> 
> The element IPAddress cannot be BER encoded.  An 
> implemeantion can DER encode a bitstring and still claim full 
> compliance to the BER specification.
> 
> I cannot see how this draft can possibly progress without 
> changing the basic type of IPAddress.
> 
> jim
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Sep 2003 09:19:25 -0400

Jim,

Right.  We're adding the ASN.1 module and will provide more 
discussion of address encoding.

Steve