Hi Sandy,
On 20/11/2015 4:27 am, "Sandra Murphy" <sa...@tislabs.com> wrote: >A bit of history here. > >After RFC6485 was published, it was discovered that it incorrectly used >the same OID for all RPKI crypto uses, which conflicts with CMS specs and >is inconsistent with known implementations. I am aware of that. > >The wg decided to create RFC6485bis, to correct the OID problem and the >OID problem only, with emphasis on the ³only². Timeline leap is not your friend here. 6485 pre-dates 6916. 6485 is minimalist (and from a point of view, wrong) about algorithm changes. > >The ³SHOULD² language in section 5 is inherited from RFC6485, except for: > > The recommended > procedures to implement such a transition of key sizes and algorithms > is specified in [RFC6916] > >RFC6916, which was published a year after RFC6485, is "Algorithm Agility >Procedure for the Resource Public Key Infrastructure (RPKI)². It >describes the procedure to follow in transitioning from one algorithm/key >size to another. Correct. It was this text that drew me to the section. And since the text pre-dates 6916, which takes a more encompassing view of an algorithm/profile change with a security section that adequately warns of invalidity due to a RP not supporting the new certificate profile, I view 6916 as more 'with the times' (YMMV). > >Does RFC6916 satisfy your concerns about a change of algorithm? It does a better job that allowing a CA or RP to opt out and fracture the RPKI. > >Would you prefer that RFC6485bis remove the inherited ³SHOULD² language >and point only to RFC6916? Yes, That is certainly one way to address this. And I would be OK with that. Cheers Terry > >Sandy > >On Nov 17, 2015, at 9:09 PM, Terry Manderson <terry.mander...@icann.org> >wrote: > >> Terry Manderson has entered the following ballot position for >> draft-ietf-sidr-rfc6485bis-04: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to >>https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I'm not so sure that this will be an easy DISCUSS to work through as I >> view this in light of future sustainability/deployability of RPKI and >>any >> protocol wedded to it (eg BGPSEC). >> >> Section 5 "Additional Requirements" suggests that both CAs and RPs >> "SHOULD" be capable of supporting a transition and thus able to support >> multiple RPKI alg. and key profiles. To me this "SHOULD" seems like it >> invites fragility in any such transition. An immediate example would be >> the root DNSSEC ksk rollover. An rather large amount of work is underway >> to ascertain the impact. By leaving the SHOULDs in place is this walking >> the same path? >> >> Let me ask another way. Under what situations is it actually appropriate >> for a CA or RP to be able to ignore the requirement of being able to >> support a phased introduction/deprecation of new/different RPKI >>algorithm >> and key profiles? And if they ignore such a recommendation does this >>make >> the entire RPKI infrastructure a fractured PKI by algorithm? >> >> >> >> >> _______________________________________________ >> 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
