> From: Danny McPherson <da...@tcb.net> > Date: December 23, 2011 6:15:54 AM GMT+01:00 > To: <sidr@ietf.org> > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-04.txt > > > 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, I want to thank you for your second throughout review. You spot some new
problems with the old and new text.
Please see comments inline.
Roque
>> -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).
>
(Roque) Having a SHOULD was discuss a while ago when checking pro a cons of a
complete separation from a separation based on the information in the manifest.
The complete separation was preferred but a separation based on the information
in the different manifests while sharing the same publication points was not
ruled out.
>
>> 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.
>
(Roque) This new piece of the text is part of a paragraph on how to stop the
transition process at this stage. In the previous paragraph it is clearly
stated that "failure" is defined by local policies. So, at this stage all
product MUST be using both algorithm suites, the RP can decide to use local
policies such as:
- validate both repositories and stay with the union of the
validated objects
- validate only B and under certain conditions of number of
total valid/invalid objects validate A
An RP can decide to continue validating A until EOL. The only policy for RP
that we are requesting is that it MUST be validating Algorithm B at Twilight
and that it MUST stop validating Algorithm C after EOL.
>
>>
>> ---
>> 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.
>
(Roque) The "cancelation" text changes in every phase. I rather not clarify
that this text should be read in the correspondent section.... :-)
>> ---
>> 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."
>>
(Roque) I guess you are referring here to the SHOULD to be changed for MUST.
See above.
>
>
>> ---
>> 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.
>>
>
(Roque) At this phase the CA MUST use both algorithm suites. The RP have to
chose their local policies. As mentioned before, an RP may decide that it want
to continue validating using the two suites until EOL, but that is not required.
>
>
>> ---
>> 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."
>
(Roque) s/MAY/MAY NOT
So, you MAY create the Suite C products (i.e. provisioning protocol support)
and you MAY publish them.
>> ---
>> 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.
>>
>
(Roque) The sentence only says that if you decide to validate a product set
using Suite C and that product validates, it is valid. But you should not
consider that the Suite C repository is complete. I do not see the collision.
>
>> ---
>> 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:
>
>
(Roque)
This text is on the first paragraph:
"In this section, we describe the RP behavior when validating instances of the
same signed product but signed with different algorithm suites."
We use also the definition of two different files for the same object:
"During Phase 1 two (corresponding) files for an object MAY be available for
each signed product, one signed under Algorithm Suite A and one under Algorithm
Suite B."
The idea of "same signed product" includes the resources, when relevant to this
object. We kept the text more general as there are a variety of signed objects.
>>
>> "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."
>
(Roque) I do not see the conflict.
>
>>
>> ---
>> 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."
>
(Roque) If the child CA does not do that, your CA stops complying with the
requirement that MUST publish all objects using both algorithm suites.
However, you raised the point that we need to add an exception for key
roll-overs as we are mentioning in the following section that the processes are
independent.
>
>> ---
>> 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."
>>
>
(Roque) That is exactly what we are saying. If a CA does not comply with the
process, there is a risk of ending up with a smaller RPKI. IF the CA complies
with the process, this will not happen.
>>
>> ===============================================
>> 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."
>
(Roque) ok.
>
>> ---
>> 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
>
(Roque) ok.
>> ---
>> 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):
>
(Roque) Can you provide the text?
>
>>
>> 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/
>
(Roque) ok.
>
>>
>> ---
>> 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."
>>
>
(Roque) ok.
>
>> ---
>> S 4.2:
>>
>> s/certificate.(X.509/certificate. (X.509/
>
(Roque) ok
>
>>
>> s/RPs might be ready/RPs might not be ready/ ?
(Roque) ok
>>
>> "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/
>>
>
(Roque) ok.
>
>> ---
>> 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/
>
(Roque) ok.
>
>>
>> ---
>> 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)"
>>
>
(Roque) Good catch, one reference is enough.
>
>> ---
>>
>>
>>
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
