X.509 Extensions for IP Addresses and AS Identifiers
RFC 3779

[Ballot comment]
According to our ID-NITS, IP addresses used in examples
should use a predefined set of address.
So
  10.5.0.5 is an example of an IPv4 address.
is not allowed (rfc3330)

There are more samples in this doc

[Ballot comment]
A couple of (probably ignorant) questions:

This document seems to describe an ASN.1 encoding for IP addresses.
Since we already have defined ways to express IP addresses in
ASN.1 (for MIBs), why do we need another one?

Since all of the IP address encodings use the same type, is there
some other context that makes it clear whether you are looking at
an IPv4 address, an IPv6 address, a prefix (of either type) or
an address range (of either type)?

Editorial Comments:

  IP v4 address - a 32-bit identifier written as four decimal numbers,
      each in the range 0 to 255, separated by a ".".  10.5.0.5 is an
      example of an IPv4 address.

  IP v6 address - a 128-bit identifier written as eight hexadecimal
      quantities, each in the range 0 to ffff, separated by a ":".
      2001:0:200:3:0:0:0:1 is an example of an IPv6 address.  One string
      of :0: fields may be replaced by "::", thus 2001:0:200:3::1
      represents the same address as the immediately preceding example.
      (See [RFC3513]).

> s/IP v4/IPv4/
> s/IP v6/IPv6/

> These are both used in the common form (IPv4, IPv6) later in the
> document.  Also the examples included here are included again
> later, which seems redundant.

  prefix - a bit string that consists of some number of initial bits of
      an address, written as an address followed by a "/", and the
      number of initial bits.  10.5.0.0/16 and 2001:0:200:3:0:0:0:0/64
      (or 2001:0:200:3::/64) are examples of prefixes.  A prefix is
      often abbreviated by omitting the less-significant zero fields,
      but there should be enough fields to contain the indicated number
      of initial bits.  10.5/16 and 2001:0:200:3/64 are examples of
      abbreviated prefixes.

>> This definition doesn't match the definition given later in the
>> document which is:

  An address prefix is a set of 2^k continuous addresses whose more-
  significant bits are identical.  For example, the set of 512 IPv4
  addresses from 10.5.0.0 through 10.5.1.255 all have the same 23 most-
  significant bits. 

>> I happen to like the first definition better, but I could live
>> with the second.  We just shouldn't include two different defs
>> in the same document.

  The special case of all IP address blocks, i.e., a prefix of all
  zero-bits -- "0/0", MUST be encoded per the DER with a length octet
  of one, an initial octet of zero, and no subsequent octets:

[Ballot comment]
A couple of (probably ignorant) questions:

This document seems to describe an ASN.1 encoding for IP addresses.
Since we already have defined ways to express IP addresses in
ASN.1 (for MIBs), why do we need another one?

Since all of the IP address encodings use the same type, is there
some other context that makes it clear whether you are looking at
an IPv4 address, and IPv6 address, a prefix (of either type) or
an address range (of either type)?

Editorial Comments:

  IP v4 address - a 32-bit identifier written as four decimal numbers,
      each in the range 0 to 255, separated by a ".".  10.5.0.5 is an
      example of an IPv4 address.

  IP v6 address - a 128-bit identifier written as eight hexadecimal
      quantities, each in the range 0 to ffff, separated by a ":".
      2001:0:200:3:0:0:0:1 is an example of an IPv6 address.  One string
      of :0: fields may be replaced by "::", thus 2001:0:200:3::1
      represents the same address as the immediately preceding example.
      (See [RFC3513]).

> s/IP v4/IPv4/
> s/IP v6/IPv6/

> These are both used in the common form (IPv4, IPv6) later in the
> document.  Also the examples included here are included again
> later, which seems redundant.

  prefix - a bit string that consists of some number of initial bits of
      an address, written as an address followed by a "/", and the
      number of initial bits.  10.5.0.0/16 and 2001:0:200:3:0:0:0:0/64
      (or 2001:0:200:3::/64) are examples of prefixes.  A prefix is
      often abbreviated by omitting the less-significant zero fields,
      but there should be enough fields to contain the indicated number
      of initial bits.  10.5/16 and 2001:0:200:3/64 are examples of
      abbreviated prefixes.

>> This definition doesn't match the definition given later in the
>> document which is:

  An address prefix is a set of 2^k continuous addresses whose more-
  significant bits are identical.  For example, the set of 512 IPv4
  addresses from 10.5.0.0 through 10.5.1.255 all have the same 23 most-
  significant bits. 

>> I happen to like the first definition better, but I could live
>> with the second.  We just shouldn't include two different defs
>> in the same document.

  The special case of all IP address blocks, i.e., a prefix of all
  zero-bits -- "0/0", MUST be encoded per the DER with a length octet
  of one, an initial octet of zero, and no subsequent octets:

[Ballot discuss]
A reference to RFC 1930 and a discussion of whether the new facility will have any affect on its procedures looks like it would be useful.  Normally, I would suggest separating the procedure discussion from the protocol mechanism, but this looks to be extremely tightly bound to the
whole AS/prefix allocation procedures, so it probably does belong here.  If this is discussed in
a different document then a pointer to that document instead of inclusion here would be fine as well.

[Ballot discuss]
OK, I'm sure I'm missing something totally obvious here, but I'm having
trouble understanding why a mechanism for binding a list of IP addresses
and/or ASes to a certificate is needed. The intent seems to be to use
this to indicate that someone has the right to use the IP addresses and/or
ASes. But this is the case, why not just create a document that says "so and so
has been given this allocation" and sign it using S/MIME and an appropriate
certificate? The document could be a DER-encoded ASN.1 object if having a
precise representation of this information is needed.

Making this a PKIX extension implies that all agents implementing PKIX
are supposed to know how to deal with this, right? Does it make
sense that every time we want to be able to make an authorization object
we build it into PKIX?

On a different note, the document makes mention of being able simply
compare these extension objects bit by bit. But a block of IP addresses
can be represented as either a block or a range. Does this dual representation
present a problem for bit-by-bit comparisons?

Finally, Steve, in answer to your concern about the encoding of 0/0, the way
that's specified is what the DER requires, so compliant parsers should have no
trouble with it.

[Ballot comment]
This draft mixes syntax -- how a certificate should represent prefixes -- with policy (the notion that prefixes come from RIRs or ISPs).  Is that right?

Is the special case encoding for 0/0 legal DER?  Or will it break some parsers?

[Ballot comment]
This draft mixes syntax -- how a certificate should represent prefixes -- with policy (the notion that prefixes come from RIRs or ISPs).  Is that right?

[Ballot comment]
Since multiple WGs have been involved in this effort (as Russ said on email), perhaps that should be mentioned in the "WG summary" writeup?