Hiya, On 04/01/17 18:48, Sean Turner wrote: > >> On Jan 4, 2017, at 08:53, Stephen Farrell >> <stephen.farr...@cs.tcd.ie> wrote: >> >> Stephen Farrell has entered the following ballot position for >> draft-ietf-sidr-bgpsec-protocol-21: 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-bgpsec-protocol/ >> >> >> >> ---------------------------------------------------------------------- >> >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> >> >> I have a couple of fairly straightforward things I'd >> like to briefly discuss... >> >> (1) 3.2/Figure 7: A fixed 20 byte SKI being a sha-1 hash of the >> public key is a bad plan, for all the usual reasons. Why is it ok >> for that to be hardcoded here when it could change if/when new alg >> choices are made for the RPKI? If it is not too late then I think >> you should add a length or alg field to that. If it is too late to >> do that, then are we really ok that you will need to rev the >> BGPsec version number in order to get rid of all sha-1 code from >> your implementation? That seems like a bad plan for a new >> protocol. > > Not sure it absolutely needs a length field; if the RPKI does ever > decide to change to another hash algorithm for SKI, e.g., > SHA-256/384/512, or to change to a hash of the SubjectPublicKeyInfo > they could always the procedures from > https://datatracker.ietf.org/doc/rfc7093/ to generate the values for > a 20-byte value.
Something like that could work I guess e.g. if this draft said "if a router cert contains an SKI that's != 20 bytes long, then here's what you do..." that'd be fine. I'm not sure that's identical to what's in 7093 though but it is close and should be fairly obvious and uncontroversial. I do think it very worthwhile though to not so closely couple the code for generating SKIs with that for BGPsec as they will (I guess) tend to be different codebases not evolving in a tightly coupled manner. Cheers, S. > > spt >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
