Subject: RE: IP addr: 01: WG last call

From: "Manger, James H" <[email-masked]>
Date: Thu, 21 Aug 2003 10:13:54 +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 as follows:

"2.2.3.5.  Element inherit

   If the IPAddressChoice choice contains the inherit element, then the set of authorized IP addresses for the specified AFI and optional SAFI is taken from the Issuer's certificate, or the Issuer's Issuer's certificate, recursively, until a certificate containing an IPAddressChoice containing an addressesOrRanges element is located.  If no authorization is being granted for a particular AFI and optional SAFI, then there SHOULD NOT be an IPAddressFamily member for that AFI/SAFI in the IPAddrBlocks sequence."

2. [previously answered]

3.
Why does everything have to be sorted?  Does it really make it easier or faster for CAs and relying parties, or just harder to implement & more fragile to interoperate?

4.
Section 2.3 says delegations in a certificate must be a subset of the delegations in its issuer's certificate.  What does this mean for certificate path processing inputs and self-signed trust anchor certificates?  If a trust anchor is provided in the form of a self-signed certificate must it contain the delegation extension for the path to be valid?  Is some sort of "initial-delegation-set" required as a path processing input (or, perhaps, a boolean flag indicating if each sort of delegation is allowed or disallowed)?

	----------
	From: 	Stephen Kent [mailto:[email-masked]] 
	Sent:	Thursday, 17 July 2003 4:57 PM

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 21 Aug 2003 17:34:19 -0400

At 10:13 +1000 8/21/03, Manger, James H wrote:
>Change the type of the inherit fields in IPAddressChoice (2.2.3) and 
>ASIdentifierChoice (3.2.3) to the following:
>
>    If the IPAddressChoice choice contains the inherit element, then 
>the set of authorized IP addresses for the specified AFI and 
>optional SAFI is taken from the Issuer's certificate, or the 
>Issuer's Issuer's certificate, recursively, until a certificate 
>containing an IPAddressChoice containing an addressesOrRanges 
>element is located.  If no authorization is being granted for a 
>particular AFI and optional SAFI, then there SHOULD NOT be an 
>IPAddressFamily member for that AFI/SAFI in the IPAddrBlocks 
>sequence."

This does appear to be a reasonable simplification of the ASN.1.  I 
checked with Charlie and he has no objection to making this change.

>2. [previously answered]
>
>
>3.
>Why does everything have to be sorted?  Does it really make it 
>easier or faster for CAs and relying parties, or just harder to 
>implement & more fragile to interoperate?

Sorting of the addresses or As numbers makes it easier for an RP to 
do the path processing, since the sorting allows for easy, one-pass 
subset comparison.  It does impose a requirement on CAs to sort the 
values when a cert is created.  Since a CA need do this only when it 
issues a cert, but an RP gets to take advantage of the sorting very 
time a verification is performed, it seems like a good design 
tradeoff.

>4.
>Section 2.3 says delegations in a certificate must be a subset of 
>the delegations in its issuer's certificate.  What does this mean 
>for certificate path processing inputs and self-signed trust anchor 
>certificates?  If a trust anchor is provided in the form of a 
>self-signed certificate must it contain the delegation extension for 
>the path to be valid?  Is some sort of "initial-delegation-set" 
>required as a path processing input (or, perhaps, a boolean flag 
>indicating if each sort of delegation is allowed or disallowed)?
>

Good question. A trust anchor always requires some special handling 
in path processing, as a close reading of 3280 shows. In this case 
the intent is to treat a TA as trivially satisfying the subset 
requirement, i.e., whatever values the extensions contain are OK as a 
starting point, to initialize the path processing checks on the 
subset requirement. after all a set is a subset of itself :-)

Steve