Hi Sandra, >>> Hi Roque, >>> >>> This draft seems very complete. I have just a few questions and comments: >>> >>> 1. Section 2. "A failure to comply with this process during an algorithm >>> transition MUST be considered as non-compliance with ... >>> I-D.ietf-sidr-cp". I can't detect in the CP where failing to comply with >>> this process would be result in non-compliance. It would be hopeful to more >>> specific here. >> >> (Roque) This is good feedback but I think we cannot delay the publication of >> the CP document. The idea is that the Algorithm Suites definition are part >> of the CP, consequently, the process to modify these suites should also be >> consider as a global RPKI requirement and thus tied to the CP. >> > > You seem to be saying that the alg transition mechanism is an addition to > the global cert policy - an addendum/update of the CP (RSN an) RFC. > > True? >
We could ask the CP or the Alg. document authors to add a reference during the AUTH48 process. That would be an easy fix. Roque. > If so, that should be noted. > > --Sandy, speaking as wg chair, ceremonial vestments and badges donned > > >>> >>> 2. Section 3. The definition of a "Non-Leaf CA" is "A CA that issues >>> certificates to entities not under its administrative control." I believe >>> this effectively means "CAs that have children", and if that's the >>> intended meaning perhaps that's a better statement. The present definition >>> could apply to a CA cross-certifying another CA and other non-child >>> certificate signing. Even if those situations don't expect to be possible >>> within the RPKI, it would be helpful to clarify the definition. Also, it's >>> not clear to me that a child CA is "under its administrative control" in >>> the sense that the child CA (e.g., ISP) might not be administered by the >>> parent (e.g., RIR). >> >> (Roque) These are the "CA that have children and with whom the signaling is >> carried out through the provisioning protocol". >> >> What about changing the definition to" >> >> Non-Leaf CA: A CA that issues certificates to external entities by using the >> provisioning protocol described in [PROV.]. >> >>> >>> 3. Section 4.2. "The only milestone that affects both CAs and RPs, at the >>> same moment is the EOL date.". But the "Process for RPKI CAs" figure shows >>> that two milestones are aligned: (5) and (6). How do these reconcile? >> >> (Roque) >> I will change that, however, the milestone 5 (Twilight Date) is the date >> where the NEW becomes CURRENT and the CURRENT becomes OLD. If the RP and the >> CA did their part of the work, they should both be ready at that time to >> issue/revoke and validate certificates with both algorithms, so there is no >> "action" that should be taken at >> >>> >>> 4. Section 4.3. The alignment errors that Arturo mentioned don't seem to be >>> fixed in -01. Did you mean to adjust them? Also, it might be worth stating >>> explicitly in the Note following this first example that the indentation >>> mean "signed by". >> >> (Roque) >> Thanks. I will correct and do better "quality control". >> >>> >>> 5. Section 4.5. "During this phase all signed product sets MUST be >>> available using both Algorithm Suite A and Algorithm Suite B." It isn't >>> clear to me what "During this phase" means in Phase 2. Does it mean "By the >>> end of this phase"? Or does it mean "Before the start of Phase 3", which is >>> not the same moment in time according to the figures in Section 4.2. I'm >>> inclined to think it means "Before the start of Phase 3", because by Phase >>> 3 "all product sets are available". Although again, Section 4.6 uses the >>> phrase "During this phrase" so that also isn't clear and I would recommend >>> being more precise here too. >> >> (Roque) "During this phase" means since start to end of these phase (i.e. >> after "CA Go Algorithm B date"). In Phase 2 all products are available using >> both algorithms but not all RP MUST validate them both, that only happens in >> Phase 3 (after "RP Ready Algorithm B Date") >> >> >>> 6. Section 4.5. "An RP that validates all signed product sets using both >>> Algorithm Suite A or Algorithm Suite B, SHOULD expect the same results." >>> The text added to this paragraph in -01 clarifies how to resolve >>> certificate validation results that differ, but I think it would be helpful >>> to include references to both Sections 6 and 7 here which cover issues when >>> on there are differences in validation more thoroughly. >> >> (Roque) ok. will add. >> >>> 7. (nit) The references for I-D.ietf-sidr-cp didn't get updated to -17. I >>> didn't check other references. >> >> (Roque) ok. >> >> Thanks again, >> >> Roque >> >>> >>> Thanks, >>> Brian >>> >>> On Jul 8, 2011, at 9:14 AM, Roque Gagliano wrote: >>> >>>> In this new version we included the changes from the review by Arturo and >>>> several editorial nits. >>>> >>>> Please take a look at the document and send your comments. >>>> >>>> Roque. >>> >>> -- >>> Brian Weis >>> Security Standards and Technology, SRTG, Cisco Systems >>> Telephone: +1 408 526 4796 >>> Email: [email protected] >>> >>> >>> >>> >>> >> >>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
