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

jim


> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org 
> [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Manger, James H
> Sent: Sunday, September 07, 2003 5:23 PM
> To: ietf-pkix@imc.org
> 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.
> 
> 
> 
> 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:jimsch@nwlink.com]
> Sent: Sunday, 7 September 2003 2:59 PM
> To: 'Stephen Kent'; ietf-pkix@imc.org
> 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: owner-ietf-pkix@mail.imc.org
> > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Jim Schaad
> > Sent: Friday, September 05, 2003 5:35 PM
> > To: 'Stephen Kent'; ietf-pkix@imc.org
> > 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: owner-ietf-pkix@mail.imc.org 
> > > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent
> > > Sent: Tuesday, August 19, 2003 7:02 PM
> > > To: ietf-pkix@imc.org
> > > 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
> > > 
> > 
> 
>