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

From: "Manger, James H" <[email-masked]>
Date: Thu, 3 Jul 2003 11:26:07 +1000

1.
Instead of a BOOLEAN type for which TRUE is required and FALSE is forbidden, simply use a NULL type.

Change the type of the inherit fields in IPAddressChoice (2.2.3) and ASIdentifierChoice (3.2.3) to the following:

   IPAddressChoice     ::= CHOICE {
      inherit              NULL, -- Inherit from Issuer
      addressesOrRanges    SEQUENCE OF IPAddressOrRange }

   ASIdentifierChoice ::= CHOICE {
      inherit             NULL, -- Inherit from Issuer
      asIdsOrRanges       SEQUENCE OF ASIdOrRange }

The associated text describing the inherit fields (2.2.3.5 & 3.2.3.3) can be simplified accordingly.

2.
It seems unnecessary to set these extensions to CRITICAL.  A relying party is not misled by ignoring these extensions -- it simply learns nothing new about IP address and AS allocations.

Perhaps making it CRITICAL is supposed to indicate that the certificate is binding a public key to these addresses instead of any other type of name so the subject (and subjectAltName) fields should be ignored.  If this is the case, it may be better to formulate the extensions as OTHER-NAME types to be used in the subjectAltName extension (in which case no other names needs to be included).

Perhaps making it CRITICAL is supposed to indicate that the certificate should only be used in, say, Secure BGP and not for, say, secure e-mail.  If this is the case, defining a new purpose identifier for the extendedKeyUsage extension may be more appropriate.

3.
Why does everything have to be sorted?  Does it really make it easy or faster for CAs and relying parties?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, 3 July 2003 8:10 AM
Cc: [email-masked]
Subject: IP addr: 01: draft-ietf-pkix-x509-ipaddr-as-extn-01.txt

	Title		: X.509 Extensions for IP Addresses and AS Identifiers
	Author(s)	: C. Lynn et al.
	Filename	: draft-ietf-pkix-x509-ipaddr-as-extn-01.txt
	Pages		: 24
	Date		: 2003-7-2
	
This document defines two private X.509 v3 certificate extensions.  The first binds a list of IP address blocks, or prefixes, to the subject of a certificate.  The second binds a list of Autonomous System Identifiers to the subject of a certificate.  These extensions may be used to convey the authorization of the subject to use the IP addresses and Autonomous System identifiers contained in the extensions.

http://www.ietf.org/internet-drafts/draft-ietf-pkix-x509-ipaddr-as-extn-01.txt

---

From: Russ Housley <[email-masked]>
Date: Wed, 16 Jul 2003 10:44:50 -0400

Since the extension imposes constraints on the values of subordinate 
certificates, it is clear that it must be critical in CA certificates.  I 
suppose that it could be non-critical in end entity certificates, but the 
certificate user must be able to process the extension in the CA 
certificates.  Not clear there is any value in allowing it to be 
non-critical only in end entity certificates.

Russ

At 11:26 AM 7/3/2003 +1000, Manger, James H wrote:
>It seems unnecessary to set these extensions to CRITICAL.  A relying party 
>is not misled by ignoring these extensions -- it simply learns nothing new 
>about IP address and AS allocations.
>
>Perhaps making it CRITICAL is supposed to indicate that the certificate is 
>binding a public key to these addresses instead of any other type of name 
>so the subject (and subjectAltName) fields should be ignored.  If this is 
>the case, it may be better to formulate the extensions as OTHER-NAME types 
>to be used in the subjectAltName extension (in which case no other names 
>needs to be included).
>
>Perhaps making it CRITICAL is supposed to indicate that the certificate 
>should only be used in, say, Secure BGP and not for, say, secure 
>e-mail.  If this is the case, defining a new purpose identifier for the 
>extendedKeyUsage extension may be more appropriate.

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 17 Jul 2003 12:15:25 +1000

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.

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.

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?]

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?

> ----------
> From: 	Manger, James H  
> Sent:	Thursday, 3 July 2003 11:26 AM
> 
> 2.
> 	----------
> 	From: 	Russ Housley [mailto:[email-masked]] 
> 	Sent:	Thursday, 17 July 2003 12:45 AM
> 	To:	Manger, James H; [email-masked]
> 
> 	Since the extension imposes constraints on the values of subordinate certificates, it is clear that it must be critical in CA certificates.  I suppose that it could be non-critical in end entity certificates, but the certificate user must be able to process the extension in the CA certificates.  Not clear there is any value in allowing it to be non-critical only in end entity certificates.
>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Jul 2003 02:57:03 -0400

Jim,

>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.

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.