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

From: Charles Lynn <[email-masked]>
Date: Tue, 16 Sep 2003 00:20:53 -0400 (EDT)

James,

Thanks for your comments on our draft.

Do the following address your concerns?

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

Thanks for suggesting the improvement.
(Now to get the CA and other software to use it ... :-)

>2. [previously answered]

>3. Why does everything have to be sorted?  Does it really make it 
>   easier or faster for CAs

If by CAs you mean the generation code, not really.  The CAs need to
do the sorting and handle/eliminate the boundary cases (adjacent,
overlapping, or subsumed allocations).

>   and relying parties,

Yes.  The following text has been added...

   Sections 2 and 3 specify several rules about the encoding of the
   extensions defined in this specification that MUST be followed.
   These encoding rules serve the following purposes.  First, they
   result in a unique encoding of the extension's value; two instances
   of an extension can be compared for equality octet-by-octet.  Second,
   they achieve the minimal size encoding of the information.  Third,
   they allow relying parties to use one-pass algorithms when performing
   certification path validation; in particular, the reply parties do
   not need either to sort the information, or to implement extra code
   in the subset checking algorithms to handle several boundary cases
   (adjacent, overlapping, or subsumed allocations).

Should some other point be addressed?

For the case that the extensions were written, the CAs sign each of the
~ 200,000 certificate on the order of once a year.  The 15,000 relying
parties validate each certificate about once a day (less caching).

>   or just harder to implement & more fragile to interoperate?

Harder for the CA, easier for all the relying parties.  The boundary cases
are easy to code incorrectly (having observed three people doing it).
Since the intended use is to help secure Internet routing, we would like
to fail-safe rather than fail-unprotected.

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

Yes.

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

No.  The initial set comes directly from the set of trust anchor
certificates.  The follwing text (|) has been added.  Is it sufficient?
Should there be explicit text a la Section 6 of RFC 3280 that specifies
there is a working set of ranges, that is initialized from the trust
anchor certificate?  Do you think a description of the subset algorithm
is necessary to make it easier for folks to correctly implement the checks?

2.3.  IP Address Delegation Extension Certification Path Validation

   Certification path validation of a certificate containing the IP
   address delegation extension requires additional processing.  As each
   certificate in a path is validated, the IP addresses in the IP
   address delegation extension of that certificate MUST be subsumed by
   IP addresses in the IP address delegation extension in the issuer's
   certificate.  Validation MUST fail when this is not the case.  A
   certificate that is a trust anchor for certification path validation   |
   of certificates containing the IP address delegation extension, as     |
   well as all certificates along the path, MUST each contain the IP      |
   address delegation extension.  The initial set of allowed address      |
   ranges is taken from the trust anchor certificate.                     |

Charlie

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 16 Sep 2003 15:11:06 +1000

Thanks for addressing my comments.

3.
A while ago people wanted to sort CRL entries with ideas of faster searching and one-pass processing.  It was a poor idea as everything had to be processed anyway (to verify the signature) and hash tables (that ignored sorting) were more efficient for lookups.

I have not looked at the best algorithms for the required operations on the address range extensions, but I wanted to know that someone else had and that sorting really did help.  It looks like you (and the 3 coders you mention) have done this.

----------
From: Charles Lynn [mailto:[email-masked]]
Sent: Tuesday, 16 September 2003 2:21 PM

James,

Yes.

Charlie