On Mon, 11 Jul 2011, Roque Gagliano wrote:
Hi Brian,
Thank you very much for your review.
Please see my comments inline.
Roque
On Jul 8, 2011, at 9:08 PM, Brian Weis wrote:
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?
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]
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
