dear WG/Gen-Art, David and I discussed the new text that will improve this description to complete the GenArt review.
Text to be added to section 4: "The following figure shows an example of the structure of signed objects in the repository, indicating the algorithm suites in use, and showing the relationships between three CAs (X, Y, and Z) that form a certification chain. Vertical alignment in the figure indicates objects signed by the same CA using the same private key. The differences in horizontal indentation also represent use of different publication points for objects signed by different CAs. The characters "|->" are used for visualization purposes for both the signing relationship and the publication point change. For example, the objects CA-Y-Certificate-Algorithm-Suite-A, CA-X-CRL-Algorithm-Suite-A and CA-X-Signed-Objects-Algorithm-Suite-A are all signed using the private key corresponding to CA-X-Certificate-Algorithm- Suite-A and published at CA X's corresponding publication point." You will get a new version notification in your inbox. Roque On Jan 8, 2013, at 12:02 PM, Roque Gagliano (rogaglia) <rogag...@cisco.com> wrote: > Hi David, > > I got your point. > > What about this text for that paragraph? > > "The following figure illustrates the format used to describe signed objects > in the repository. It reflects the algorithm suites in use, and shows the > relationship between three CAs (X, Y, and Z) that form a certificate chain. > The vertical alignment in the figure distinguishes between objects signed by > the same CA using the same private key. The vertical alignment also > represents the composition of the different publication points as a component > of the RPKI repository. The characters "|->" are used for visualization > purpose. As an example taken from the figure, the objects > CA-Y-Certificate-Algorithm-Suite-A, CA-X-CRL-Algorithm-Suite-A and > CA-X-Signed-Objects-Algorithm-Suite-A are all signed using the private key > corresponding to CA-X-Certificate-Algorithm-Suite-A and published at that CA > correspondent publication point." > > Roque > > On Jan 7, 2013, at 7:53 PM, "Black, David" <david.bl...@emc.com> wrote: > >> Hi Roque, >> >>> "The vertical alignment in the figure distinguishes between the different >>> publication points and the characters '|->' are used for visualization >>> purpose." >> >> I think there's more going on than just publication point change. >> >> Here's the entire figure, plus the one existing sentence about >> the '|->' notation: >> >> CA X-Certificate-Algorithm-Suite-A (Cert-XA) >> | >> |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) >> |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA) >> |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA) >> |-> CA-Z-Signed-Objects-Algorithm-Suite-A >> |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) >> |-> CA-Y-Signed-Objects-Algorithm-Suite-A >> |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA) >> |-> CA-X-Signed-Objects-Algorithm-Suite-A >> >> Note: Cert-XA represent the certificate for CA X, that is signed >> using the algorithm suite A. >> >> I believe that the private key corresponding to Cert-XA is used to sign >> Cert-YA, e.g., so that Cert-XA is involved in the path validation of >> Cert-YA. It looks like that's part of the relationship represented by >> '|->' and (if so) I would like to see a statement to that effect in >> addition to your proposed text about different publication points. >> >> Thanks, >> --David >> >>> -----Original Message----- >>> From: Roque Gagliano (rogaglia) [mailto:rogag...@cisco.com] >>> Sent: Monday, January 07, 2013 12:52 PM >>> To: Black, David >>> Cc: Roque Gagliano (rogaglia); Stephen Kent; Sean Turner; gen-...@ietf.org; >>> sidr@ietf.org; Stewart Bryant (stbryant) >>> Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 >>> >>> Hi David, >>> >>> On Jan 7, 2013, at 6:16 PM, "Black, David" <david.bl...@emc.com> wrote: >>> >>>> Roque, >>>> >>>> That new version looks good. Could you also take a look at this editorial >>>> suggestion that Steve deferred to you?: >>>> >>> >>> Ok, sorry about that. >>> >>>> Starting near the end of section 4.3, the three characters >>>> |-> are used in figures to represent an RPKI hierarchy relationship; >>>> that relationship should be defined and/or explained before it is used. >>> >>> The idea in the different figures is that the vertical alignment >>> differentiates the different publication points. >>> >>> What about adding the following text? >>> >>> "The vertical alignment in the figure distinguishes between the different >>> publication points and the characters '|->' are used for visualization >>> purpose." >>> >>> >>>> For clarity, I'd suggest swapping the order of the two paragraphs >>>> above that figure in 4.3 and making the following change at the end >>>> of the paragraph that is moved down (addition of the word >>>> "certificate" is the important change): >>> >>> All done and thanks. >>> >>> Roque >>> >>>> OLD >>>> and shows the relationship between three CAs (X, Y, and Z) that form >>>> a chain. >>>> NEW >>>> and shows the relationships among the three CAs (X, Y, and Z) >>>> that participate in a certificate chain. >>>> >>>> Subsequent uses of |-> seemed clear to me. >>>> >>>> Thanks, >>>> --David >>>> >>>>> -----Original Message----- >>>>> From: Roque Gagliano (rogaglia) [mailto:rogag...@cisco.com] >>>>> Sent: Monday, January 07, 2013 12:02 PM >>>>> To: Black, David >>>>> Cc: Stephen Kent; Roque Gagliano (rogaglia); Sean Turner; >>>>> gen-...@ietf.org; >>>>> sidr@ietf.org; Stewart Bryant (stbryant) >>>>> Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 >>>>> >>>>> David, >>>>> >>>>> I just published version 10 of the document with all the agreed changes. >>>>> Thanks again for your review. >>>>> >>>>> Roque >>>>> >>>>> >>>>> On Dec 31, 2012, at 8:57 PM, "Black, David" <david.bl...@emc.com> wrote: >>>>> >>>>>> Steve, >>>>>> >>>>>> This all looks good; thanks for the quick response. >>>>>> >>>>>>>> [*] Section 4.7 changes the meaning of the algorithm suite names (A, B >>>>>>>> and C) from prior sections. >>>>>> >>>>>>> I have deleted all references to Alg Suite C throughout the doc, and >>>>>>> revised the text accordingly. >>>>>> >>>>>> Magnificent - that'll be a significant improvement. >>>>>> >>>>>>>> Starting in Section 4.3.1, there are a number of uses of "will be" >>>>>>>> (future tense) in the milestone and phase descriptions. All of >>>>>>>> these uses of "will be" should be reviewed to determine whether >>>>>>>> "MUST be" is appropriate, e.g., as appears to be the case for >>>>>>>> this sentence in 4.3.1: >>>>>>>> >>>>>>>> Additionally, the new algorithm transition timeline document will be >>>>>>>> published with the following information: >>>>>> >>>>>>> I agree that "will be" needs to be changed to "MUST be" in a few places, >>>>>>> starting on page 5 (Section 2) where the need to update the CP and to >>>>> publish an >>>>>>> alg transition timetable are first mentioned. An examination of the rest >>> of >>>>> the >>>>>>> doc shows that this change need be applied only when the alg transition >>> doc >>>>> is >>>>>>> mentioned. >>>>>> >>>>>> That sounds reasonable. >>>>>> >>>>>>>> Section 3 Definitions: Is there any concern about possible >>>>>>>> confusion of the use of "Suite B" in this draft with NSA Suite B? >>>>>>>> The draft is clear on what Suite B means for RPKI, but I suspect >>>>>>>> that RPKI Suite B and NSA Suite B are unlikely to match, if ever. >>>>>>> >>>>>>> We defined what "Suite B" is in the terminology section, so I >>>>>>> think no further clarification is required here. >>>>>> >>>>>> That's ok with me, but I thought it was worth asking. >>>>>> >>>>>> Thanks, >>>>>> --David >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Stephen Kent [mailto:k...@bbn.com] >>>>>>> Sent: Monday, December 31, 2012 2:35 PM >>>>>>> To: Black, David >>>>>>> Cc: rogag...@cisco.com; Sean Turner; gen-...@ietf.org; sidr@ietf.org; >>>>> Stewart >>>>>>> Bryant >>>>>>> Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 >>>>>>> >>>>>>> David, >>>>>>> >>>>>>>> The draft is generally well-written and clear, but has an unfortunate >>>>>>>> nomenclature change problem that is the primary open issue[*]. >>>>>>>> >>>>>>>> Major issues: >>>>>>>> >>>>>>>> [*] Section 4.7 changes the meaning of the algorithm suite names (A, B >>>>>>>> and C) from prior sections. >>>>>>> >>>>>>> I have deleted all references to Alg Suite C throughout the doc, and >>>>>>> revised the text accordingly. >>>>>>> >>>>>>>> This also affects Sections 6 and 7. >>>>>>>> I have classified this as a major issue as I believe it introduces >>>>>>>> severe lack of clarity (and potential ambiguity) into the following >>>>>>>> two paragraphs in Section 7: >>>>>>>> >>>>>>>> During Phase 1, a CA that revokes a certificate under Suite A SHOULD >>>>>>>> revoke the corresponding certificate under Suite B, if that >>>>>>>> certificate exists. During Phase 4, a CA that revokes a certificate >>>>>>>> under Suite A SHOULD revoke the corresponding certificate under Suite >>>>>>>> C, if that certificate exists. >>>>>>>> >>>>>>>> During Phase 1, a CA may revoke certificates under Suite B without >>>>>>>> revoking them under Suite A, since the Suite B products are for test >>>>>>>> purposes. During Phase 4 a CA may revoke certificates issued under >>>>>>>> Suite C without revoking them under Suite A, since Suite C products >>>>>>>> are being deprecated. >>>>>>> fixed. >>>>>>>> Despite the use of three letters (A, B and C), there are only two >>>>>>>> algorithm suites involved, and different instances of Suite A refer to >>>>>>>> different algorithm suites. In each paragraph, the first instance of >>>>>>>> "Suite A" refers to the same algorithm suite as "Suite C", and the >>>>>>>> second instance of "Suite A" refers to the same algorithm suite >>>>>>>> as "Suite B". >>>>>>>> >>>>>>>> It would be much better and clearer to not change the meaning of the >>>>>>>> algorithm suite names until the EOL date. In addition, this change >>>>>>>> should enable removal of the Suite C concept from this draft. >>>>>>> fixed >>>>>>>> I >>>>>>>> strongly recommend removing the Suite C concept, as the C-A-B >>>>>>>> chronological order of suite introduction dates seems >>>>>>>> counter-intuitive. >>>>>>> Done. >>>>>>>> >>>>>>>> Minor issues: >>>>>>>> >>>>>>>> Starting in Section 4.3.1, there are a number of uses of "will be" >>>>>>>> (future tense) in the milestone and phase descriptions. All of >>>>>>>> these uses of "will be" should be reviewed to determine whether >>>>>>>> "MUST be" is appropriate, e.g., as appears to be the case for >>>>>>>> this sentence in 4.3.1: >>>>>>>> >>>>>>>> Additionally, the new algorithm transition timeline document will be >>>>>>>> published with the following information: >>>>>>> I agree that "will be" needs to be changed to "MUST be" in a few places, >>>>>>> starting on page 5 (Section 2) where the need to update the CP and to >>>>>>> publish an >>>>>>> alg transition timetable are first mentioned. An examination of the rest >>>>>>> of the >>>>>>> doc shows that this change need be applied only when the alg transition >>>>>>> doc is >>>>>>> mentioned. >>>>>>>> When "MUST be" is not appropriate, present tense (i.e., "is") is >>>>>>>> preferable. >>>>>>> fixed. >>>>>>>> >>>>>>>> Nits/editorial: >>>>>>>> >>>>>>>> Abstract: The following two sentences don't quite line up: >>>>>>>> >>>>>>>> The process >>>>>>>> is expected to be completed in a time scale of months or years. >>>>>>>> Consequently, no emergency transition is specified. >>>>>>>> >>>>>>>> Also, section 4.2 indicates that a multi-year transition timeframe >>>>>>>> is expected, which suggests that "months" is not appropriate in >>>>>>>> the abstract. Suggested rephrasing: >>>>>>>> >>>>>>>> The time available to complete the transition process >>>>>>>> is expected to be several years. >>>>>>>> Consequently, no emergency transition process is specified. >>>>>>> fixed. >>>>>>>> Section 2. Introduction: The first sentence in the last paragraph >>>>>>>> mentions a forthcoming BCP on transition timetable. The rest of >>>>>>>> that paragraph implies that the BCP is for a single transition, as >>>>>>>> opposed to being a BCP for transitions in general. It would be >>>>>>>> helpful to clarify that at the start of the paragraph, e.g., >>>>>>>> by adding "For each algorithm transition," to the start of the >>>>>>>> paragraph. >>>>>>> fixed. >>>>>>>> Section 3 Definitions: Is there any concern about possible >>>>>>>> confusion of the use of "Suite B" in this draft with NSA Suite B? >>>>>>>> The draft is clear on what Suite B means for RPKI, but I suspect >>>>>>>> that RPKI Suite B and NSA Suite B are unlikely to match, if ever. >>>>>>> We defined what "Suite B" is in the terminology section, so I >>>>>>> think no further clarification is required here. >>>>>>>> Describing Phase 0 as both the steady state of the RPKI and the first >>>>>>>> phase of transition is confusing (e.g., in 4.3). It would be clearer >>>>>>>> if Phase 0 began with publication of the updated RPKI algorithm >>>>>>>> document (Milestone 1) and that the activities that are unchanged >>>>>>>> from steady state were described as not changing in phase 0. >>>>>>> we need to be able to refer to steady state, separate from the >>>>>>> first milestone in the transition process, but I agree that referring to >>>>>>> it as the first phase of the transition process is confusing. I have >>>>>>> changed the text accordingly. >>>>>>>> Starting near the end of section 4.3, the three characters >>>>>>>> |-> are used in figures to represent an RPKI hierarchy relationship; >>>>>>>> that relationship should be defined and/or explained before it is used. >>>>>>>> For clarity, I'd suggest swapping the order of the two paragraphs >>>>>>>> above that figure in 4.3 and making the following change at the end >>>>>>>> of the paragraph that is moved down (addition of the word >>>>>>>> "certificate" is the important change): >>>>>>>> >>>>>>>> OLD >>>>>>>> and shows the relationship between three CAs (X, Y, and Z) that form >>>>>>>> a chain. >>>>>>>> NEW >>>>>>>> and shows the relationships among the three CAs (X, Y, and Z) >>>>>>>> that participate in a certificate chain. >>>>>>>> >>>>>>>> Subsequent uses of |-> seemed clear to me. >>>>>>> I'll defer to Roque here, as the repository representation is his >>>>>>> design. >>>>>>>> Section 4.5 Phase 2 says that Suite B product SHOULD be stored at >>>>>>>> independent publication points, but does not make it clear that this >>>>>>>> recommendation applies beyond phase 2. I suggest adding text to >>>>>>>> make that clear - a reference to Section 9 (which is clear about >>>>>>>> this) may be useful as part of that text. >>>>>>> I have added a forward pointer to Section 9 here. >>>>>>>> In Section 6, please expand the ROA acronym on first use and consider >>>>>>>> whether it should be defined in Section 3. I'm also assuming that the >>>>>>>> ASN acronym is intended to refer to ASN.1 content; if not, that >>>>>>>> acronym also needs attention. >>>>>>> ASN = Autonomous System Number. I expended the acronym as it appears >>>>>>> only here. I added a ROA definition to Section 3. >>>>>>>> idnits 2.12.13 found a couple of minor nits: >>>>>>>> >>>>>>>> ** There is 1 instance of too long lines in the document, the longest >>>>> one >>>>>>>> being 23 characters in excess of 72. >>>>>>> I'll let Roque address this issue. >>>>>>>> >>>>>>>> == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, >>>>>>> but >>>>>>>> does not include the phrase in its RFC 2119 key words list. >>>>>>> fixed. >>>>>>> >>>>>> >>>>> >>>> >>> >> > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
