RE: IP addr: 01: use NULL instead of BOOLEAN for inherit

[Stephen Kent <kent@xxxxxxx>]

Jim,

> http://www.ietf.org/internet-drafts/draft-ietf-pkix-x509-ipaddr-as-extn-01.txt
>
> I had not fully not appreciated section 2.3 "IP Address Delegation 
> Extension Certification Path Validation".  The IP address delegation 
> extension acts as both a subject name and a name constraint.  It is 
> marked as CRITICAL due to the latter role.  I wonder if combining 
> these 2 functions in one extensions is the most sensible approach? 
> [RFC 2050 "Internet Registry IP Allocation Guidelines" (section 2.1) 
> makes a distinction between the allocation of IP addresses and the 
> assignment of IP addresses.]  Perhaps you can distinguish these 
> cases based on whether or not the certificate is a CA certificate.

No, the addresses are NOT subject names. The extension represents an 
authorization to use the addresses contained therein.

> Interestingly, though a name constraint would normally have to be 
> marked critical (in case someone understands a name but not a name 
> constraint) we can probably get away without this restriction in 
> this case.  A relying party either:
> * recognizes the extension and, hence, processes the constraint that 
> address ranges must be subsumed by the address ranges in the issuers 
> certificate; or
> * does not recognize the extension and, hence, does not process the 
> constraints (so the address range may be outside that of the issuer) 
> but it ignores the address range anyway.
> It should be acceptable to ignore a name constraint if you also 
> ignore any name of the type it is constraining.  Perhaps the 
> difficulty is that the output from a typical certificate path 
> processing module cannot indicate that only a subset of the subject 
> names should be considered by the application.

You are right that, in a sense, the subsetting requirement imposed on 
validation of a cert path containing these extensions is analogous to 
that imposed by name constraints. But, this is an extension designed 
to represent authorization data, not name data, and thus the name 
constraints extension is not be appropriate here.

> If a certificate includes an IP address in the subjectAltName 
> extension must it be within the ranges defined  by any IP address 
> delegation extensions in the same certificate or certificates 
> further up the chain?  Either way, this should probably be 
> explicitly mentioned in section 2.3.
> [How about e-mail address or URIs in subjectAltName that use IP addresses?]

As I noted above, the addresses here are NOT names, so they have 
nothing to do with the subject name or subject alt name fields.

> In a certificate chain (CACert1->CACert2->CACert3->EECert) does it 
> matter which certificates have the IP address delegation extension? 
> For instance, can CACert2 and EECert have the extension but not the 
> certs before and between them?

The model envisioned here requires that all CA certs on the path 
contain the extension, terminating in an EE cert containing the 
extension. We couild clarify this in a revision of the doc.