James Kempf: Attached is a cert chain example from
Jonathan Trostle.

Certificate Chain Example:

Suppose iana.org is the trust anchor. The host receives the following certificate chain
containing three X.509 v3 certificates:

certificate 1:

issuer: iana.org
validity: 1-1-2004 to 1-1-2005
subject: iana.org
extensions: contains (among possibly other extensions) the IP address delegation extension
with some set of prefixes and IP address ranges, say P1, ..., Pk.

certificate 2:

issuer: iana.org
validity: 1-1-2004 to 1-1-2005
subject: isp_foo_example.com
extensions: contains (among possibly other extensions) the IP address delegation extension
with some set of prefixes and IP address ranges, say Q1, ..., Qr.

certificate 3:

issuer: isp_foo_example.com
validity: 1-1-2004 to 1-1-2005
subject: router_foo.isp_foo_example.com
extensions: contains (among possibly other extensions) the IP address delegation extension
with some set of prefixes and IP address ranges, say R1, ..., Rs.

NOTE: we have omitted version, serial number, signature and other
fields from the certificates, that are not essential to our example.

When processing this certificate chain, all the normal RFC 3280
certificate path validation checks (including revocation checks) MUST
be performed. Also, from [11], the IP addresses in the IP address
delegation extension must be subsumed by the IP addresses in the IP
address delegation extension in the issuer's certificate. So in this
example, R1, ..., Rs must be subsumed by Q1,...,Qr, and Q1,...,Qr must
be subsumed by P1,...,Pk. If the certificate chain is valid, then
router_foo.isp_foo_example.com is authorized to route the prefixes
R1,...,Rs.

-----------

Jari Arkko: I took the example, slightly edited:

   The following is an example of a certificate chain.  Suppose that
   ispgroup.com is the trust anchor.  The host has this certificate for
   it:

             Certificate 1:
               Issuer: isp_group.com
               Validity: Jan 1, 2004 through Dec 31, 2004
               Subject: isp_group.com
               Extensions:
                 IP address delegation extension:
                    Prefixes: P1, ..., Pk
                 ... possibly other extensions ...
               ... other certificate parameters ...

   The host attaches then to a linked served by router_x.isp_foo.com,
   and receives the following certificate chain:

             Certificate 2:
               Issuer: isp_group.com
               Validity: Jan 1, 2004 through Dec 31, 2004
               Subject: isp_foo.com
               Extensions:
                 IP address delegation extension:
                   Prefixes: Q1, ..., Qk
                 ... possibly other extensions ...
               ... other certificate parameters ...

             Certificate 3:
               Issuer: isp_foo.com
               Validity: Jan 1, 2004 through Dec 31, 2004
               Subject: router_x.isp_foo.com
               Extensions:
                 IP address delegation extension:
                   Prefixes R1, ..., Rk
                 ... possibly other extensions ...
               ... other certificate parameters ...

   When processing the three certificates, the usual RFC 3280
   certificate path validation is performed, for instance by checking
   for revoked certificates.  In addition, the IP addresses in the
   delegation extension must be subsumed by the IP addresses in the
   delegation extension in the issuer's certificate.  So in this
   example, R1, ..., Rs must be subsumed by Q1,...,Qr, and Q1,...,Qr
   must be subsumed by P1,...,Pk.  If the certificate chain is valid,
   then router_foo.isp_foo_example.com is authorized to route the
   prefixes R1,...,Rs.

-----------

James Kempf: Looks good.