Skip to main content

X.509 Extensions for IP Addresses and AS Identifiers
draft-ietf-pkix-x509-ipaddr-as-extn-03

Revision differences

Document history

Date Rev. By Action
2012-08-22
03 (System) post-migration administrative database adjustment to the No Objection position for Ned Freed
2012-08-22
03 (System) post-migration administrative database adjustment to the No Objection position for Ted Hardie
2004-03-01
03 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-02-27
03 Amy Vezza IESG state changed to Approved-announcement sent
2004-02-27
03 Amy Vezza IESG has approved the document
2004-02-27
03 Amy Vezza Closed "Approve" ballot
2004-02-27
03 Russ Housley State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Russ Housley
2004-02-04
03 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie
2003-12-04
03 Amy Vezza Removed from agenda for telechat - 2003-12-04 by Amy Vezza
2003-12-04
03 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation - Defer by Amy Vezza
2003-12-04
03 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for  by Amy Vezza
2003-12-04
03 Amy Vezza [Ballot Position Update] New position, Yes, has been recorded for  by Amy Vezza
2003-12-04
03 Ned Freed [Ballot Position Update] Position for Ned Freed has been changed to No Objection from Discuss by Ned Freed
2003-12-04
03 Thomas Narten [Ballot Position Update] New position, No Objection, has been recorded for  by Thomas Narten
2003-12-04
03 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for  by Bill Fenner
2003-11-20
03 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Undefined by Bert Wijnen
2003-11-20
03 Bert Wijnen
[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 …
[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
2003-11-20
03 Bert Wijnen [Ballot Position Update] New position, Undefined, has been recorded for  by Bert Wijnen
2003-11-20
03 Alex Zinin State Changes to IESG Evaluation - Defer from IESG Evaluation by Alex Zinin
2003-11-20
03 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for  by Jon Peterson
2003-11-19
03 Margaret Cullen
[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 …
[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:
2003-11-19
03 Margaret Cullen
[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 …
[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:
2003-11-19
03 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for  by Margaret Wasserman
2003-11-19
03 Ted Hardie
[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 …
[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.
2003-11-19
03 Ted Hardie [Ballot Position Update] New position, Discuss, has been recorded for  by Ted Hardie
2003-11-19
03 Ned Freed
[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 …
[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.
2003-11-19
03 Ned Freed [Ballot Position Update] Position for Ned Freed has been changed to Discuss from No Objection by Ned Freed
2003-11-19
03 Ned Freed [Ballot Position Update] New position, No Objection, has been recorded for  by Ned Freed
2003-11-17
03 Steven Bellovin [Ballot Position Update] Position for Steve Bellovin has been changed to Yes from Undefined by Steve Bellovin
2003-11-17
03 Steven Bellovin
[Ballot comment]
This draft mixes syntax -- how a certificate should represent prefixes -- with policy (the notion that prefixes come from RIRs or ISPs).  …
[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?
2003-11-17
03 Steven Bellovin
[Ballot comment]
This draft mixes syntax -- how a certificate should represent prefixes -- with policy (the notion that prefixes come from RIRs or ISPs).  …
[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?
2003-11-17
03 Steven Bellovin [Ballot Position Update] New position, Undefined, has been recorded for  by Steve Bellovin
2003-11-17
03 Harald Alvestrand [Ballot Position Update] Position for Harald Alvestrand has been changed to No Objection from Undefined by Harald Alvestrand
2003-11-04
03 Harald Alvestrand
[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" …
[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?
2003-11-04
03 Harald Alvestrand [Ballot Position Update] New position, Undefined, has been recorded for  by Harald Alvestrand
2003-10-31
03 Russ Housley Placed on agenda for telechat - 2003-11-20 by Russ Housley
2003-10-31
03 Russ Housley State Changes to IESG Evaluation from Waiting for Writeup by Russ Housley
2003-10-31
03 Russ Housley Status date has been changed to 2003-10-31 from 2003-10-16
2003-10-31
03 Russ Housley [Ballot Position Update] New position, Yes, has been recorded for Russ Housley
2003-10-31
03 Russ Housley Ballot has been issued by Russ Housley
2003-10-31
03 Russ Housley Created "Approve" ballot
2003-10-30
03 (System) State has been changed to Waiting for Writeup from In Last Call by system
2003-10-16
03 Amy Vezza Last call sent
2003-10-16
03 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2003-10-16
03 Russ Housley State Changes to Last Call Requested from Last Call Requested by Russ Housley
2003-10-16
03 Russ Housley Status date has been changed to 2003-10-16 from 2003-10-15
2003-10-16
03 Russ Housley Last Call was requested by Russ Housley
2003-10-16
03 Russ Housley State Changes to Last Call Requested from Publication Requested by Russ Housley
2003-10-16
03 (System) Ballot writeup text was added
2003-10-16
03 (System) Last call text was added
2003-10-16
03 (System) Ballot approval text was added
2003-10-15
03 Russ Housley Draft Added by Russ Housley
2003-09-29
03 (System) New version available: draft-ietf-pkix-x509-ipaddr-as-extn-03.txt
2003-09-16
02 (System) New version available: draft-ietf-pkix-x509-ipaddr-as-extn-02.txt
2003-07-02
01 (System) New version available: draft-ietf-pkix-x509-ipaddr-as-extn-01.txt
2002-02-27
00 (System) New version available: draft-ietf-pkix-x509-ipaddr-as-extn-00.txt