Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-04.txt

[Danny McPherson <[e-mail]>]

I've reviewed the -04 version of the draft and have the following 
comments (most of which persist from the previous version of the 
draft, although many were accommodated - thanks).

-danny

===============================================
Substantial:

---
S 4.4 (&& S 4.6):

I remain concerned that independent publication points for 
product sets for different algorithms are not a mandatory 
requirement.  Is there any reason why, for example, this is a 
SHOULD rather than a MUST:

"Suite B product SHOULD be stored at independent publication 
points"

It's precisely the assumptions this introduces in S 4.4 that 
makes me think independent publication points must be a hard 
requirement (i.e., MUST).

S 4.6 on same issue:

   "Since the Suite B products SHOULD be published at distinct 
   publication points, RPs that cannot process Suite B products 
   can be expected to revert to the Suite A products that still exist."

This text to me still assumes interdependence between 
independent publication points, even after you explicitly 
stated that an algorithm that validates under either object 
(which technically, they're independent anyway) should be
considered valid.  It lends itself to the thought that an RP 
should prolly maintain both suites until EOL, which isn't 
necessarily the suggestion, methinks.


---
S 4.4:

   "If the Suite B algorithm is deemed unsuitable, the algorithm
   transition timeline and the algorithm specification documents MUST be
   replaced.  CAs MUST cease accepting requests for certificates under
   Suite B, and Suite B certificates that have been issued MUST be
   revoked."

I know this is in the Phase 1 section, but it may be worth iterating 
here that this is only possible in these early phases of the transition.

---
S 4.5:

   "An RP that validates all signed product sets using both Algorithm
   Suite A or Algorithm Suite B, SHOULD expect the same results.
   However, an object that validates using either Algorithm Suite A or
   Algorithm Suite B MUST be considered valid.  A detailed analysis on
   the validation of multiple instance of signed objects is included in
   Section 6."

---
S 4.6:

   "Phase 3 starts at the RP Ready Algorithm B Date.  During this phase,
   all signed product sets are available using both algorithm suites and
   all RPs MUST be able to validate them using either suite.  An object
   that validates using either Algorithm Suite A or Algorithm Suite B
   MUST be considered valid.  It is RECOMMENDED that, in preparation for
   Phase 4, RPs utilize Suite B as the first and preferred option for
   validation throughout this phase.  Thus, for example, an RP SHOULD
   try to validate the sets of signed products retrieved from the
   Algorithm Suite B repository first.  If this effort fails (relative
   to the local validation policy), the RP SHOULD revert to using the
   Algorithm Suite A repository."

Given that the two algorithm suite product sets are independent and 
use different publication points there may be a place where "all signed
product sets" are NOT available using both algorithm suites, no?  Else
what if they aren't what would you do anyway?   Phase 6 says there
must be parity as well, particularly during Phase 2 & 3, and it's not really
the case is it?  It's a darn good idea, but that's a different issue.

---
S 4.7: 

I don't know what this text is aiming to accomplish (i.e., where else
would they be published)?

   "All signed products sets issued using Suite A MUST be published 
   at their corresponding publication points, but signed products sets 
   issued using Suite C MAY be published at their corresponding 
   publication points."

---
S 4.7:

My previous concerns persist here:

   "Also, every RP MUST validate signed product sets using Suite A 
   but also MAY validate signed product sets using Suite C. However, 
   RPs SHOULD NOT assume the Suite C repository is complete."

If RPs do this and you've got Suite A that validates and Suite C that 
does not then what is the behavior?  It really has to be just as in earlier
phases, where valid in either is valid, period, no?  That's why I don't 
like this collision probability we're introducing.  

---
S 6:

Where do we say that both "instances" of such products MUST 
contain the same resources (and what's an "instance")?  I don't see 
this requirement earlier in the draft and it seems a REALLY bad 
requirement to be - they MUST be independent:

"Because both instances of such products MUST contain the same 
 resources, relying on either instance will yield the same outcome."

For example, this text in the following section itself is in conflict
with the S 6 requirement:

"As the algorithm migration process mandates the maintenance of 
two parallel certificate hierarchies, revocations requests for each
algorithm suite MUST be handled independently.  A Child CA 
MUST request revocation of a certificate relative to a specific 
algorithm suite."

---
S 7:

I don't understand this revocation requirement, the hierarchies are 
independent and it'd seem perfectly reasonable to revoke something
in one hierarchy and not in the other:

"During phase 2 and phase 3, the two parallel certificate hierarchies
are designed to carry identical information.  Consequently, a child
CA requesting the revocation of a certificate during these two phases
MUST perform that request for both algorithm suites (A and B).  A
non-leaf CA is NOT required to verify that its child CAs comply with
this requirement."

---
S 11:

This text is also in conflict with earlier requirements of absolute parity 
across the two independent hierarchies (e.g., CRLs in both, etc..):

"If a CA does not complete its migration to the new algorithm suite as
described in this document (after the EOL of the "old" algorithm
suite), its signed product set will no longer be valid.  Consequently, 
the RPKI may, at the end of Phase 4, have a smaller number of valid 
signed products than before starting the process."


===============================================
Nits:

---
S 2:

This seems a bit redundant:

"This document does not specify any algorithm suite.  This document 
does not specify any algorithm suite per se."

---
S 3:

Technically, all are changing algorithms suites in this document, 
why are you just indicating this for CA Y?

   CA X        The CA that issued CA Y's certificate (i.e., CA Y's
               parent), used in examples in this document.

   CA Y        The CA that is changing keys and/or algorithm suites,
               used in examples this document

   CA Z        A CA that is a "child" of CA Y, used in examples this
               document

---
S 3:

I think linking in this "unilateral" re-issuance function and employing
the term you've defined here would be of benefit (e.g., in S 4.1):

   Certificate re-issuance (unilateral)  A CA MAY reissue a certificate
               to a subordinate Subject without the involvement of the
               Subject.  The public key, resource extensions, and most
               other fields are copied from the current Subject
               certificate into the next Subject certificate.  The
               Issuer name MAY change, if necessary to reflect the
               Subject name in the CA certificate under which the
               reissued certificate will be validated.  The validity
               interval also MAY be changed.  This action is defined as
               a unilateral certificate re-issuance.

---
S 3: 

s/conventions use in examples/conventions used in examples/

---
S 4.1:

s/have re-issued all of its signed/have reissued all of their signed/

   "CA Go Algorithm B Date  - After this date, all (non-leaf) CAs MUST
               have re-issued all of its signed product set under the
               Algorithm B suite."

---
S 4.2:

s/certificate.(X.509/certificate.  (X.509/

s/RPs might be ready/RPs might not be ready/ ?

   "For example, many CAs might not prepared to issue signed
    products under Suite B, or many RPs might be ready to process 
   Suite B product sets."

---
S 4.4:

s/since Suite B product SHOULD/since Suite B product sets SHOULD/

---
S 4.5:

s/each signed product sets MUST/each signed product set MUST/

s/Section 4.2../Section 4.2./

s/Suite B, SHOULD/Suite B SHOULD/

s/multiple instance of signed objects/multiple instances of signed objects/

---
S 4.7:

"old Suite A"?  Isn't that now "Algorithm Suite C" by definition?
 
You do nearly the same thing in S 4.8 as well, but you add a qualifier:

"Suite C (old Suite A)"

---