Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-04.txt
Danny McPherson <danny@tcb.net> Fri, 23 December 2011 05:16 UTC
Return-Path: <danny@tcb.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A135E1F0C51 for <sidr@ietfa.amsl.com>; Thu, 22 Dec 2011 21:16:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3rMnfCQc-rr for <sidr@ietfa.amsl.com>; Thu, 22 Dec 2011 21:16:00 -0800 (PST)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDBD1F0C3B for <sidr@ietf.org>; Thu, 22 Dec 2011 21:16:00 -0800 (PST)
Received: by dog.tcb.net (Postfix, from userid 0) id 04CA1268063; Thu, 22 Dec 2011 22:16:00 -0700 (MST)
Received: from new-host-7.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Thu, 22 Dec 2011 22:15:59 -0700 (MST) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=51037; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <20111129171024.13083.74762.idtracker@ietfa.amsl.com>
Date: Fri, 23 Dec 2011 00:15:54 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <0E9A31B3-0BAF-4942-AAC6-486BCF17394B@tcb.net>
References: <20111129171024.13083.74762.idtracker@ietfa.amsl.com>
To: sidr@ietf.org
X-Mailer: Apple Mail (2.1251.1)
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-04.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Dec 2011 05:16:01 -0000
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)" ---
- [sidr] I-D Action: draft-ietf-sidr-algorithm-agil… internet-drafts
- Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-… Danny McPherson
- Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-… Roque Gagliano (rogaglia)