Hi, > On Aug 11, 2015, at 9:12 PM, Richard Hansen <[email protected]> wrote: > >> On topic #3: >> >> Assuming we are willing to bite off generating KIs RPKI-wide, can we >> do as Tim suggested in his email >> (https://mailarchive.ietf.org/arch/msg/sidr/3H8Q7zT4t06lZXHx_iD3N188U2I) >> knowing that we’ve got an example method from RFC-7093 that is >> 160-bit in length? Here’s a train of thought: >> >> RFC 6497 says this in s4: >> >> Where a field value is specified >> here, this value MUST be used in conforming resource certificates. >> >> and s7.2 has this: >> >> 3. The certificate contains all fields that MUST be present, as >> defined by this specification, and contains values for >> selected fields that are defined as allowable values by this >> specification. >> >> and s9 has the following: >> >> If the resource certificate profile is changed in the future, e.g., >> by adding a new extension or changing the allowed set of name >> attributes or encoding of these attributes, ... >> >> followed by a bunch of procedures. >> >> This train of thought makes me sad. >> >> So without trying to sugar coat this at all: can we make a change >> akin to what Tim suggested without having to invoke all of the >> procedures in s9? > > Unfortunately no, with the disclaimer that I haven't really thought > about it in depth. Because of the challenge of accomplishing topic #3, > I would like start with the much simpler topic #1. Note that I'm not > opposed to tackling #3, but the amount of work involved means that I'd > like to get topic #1, and possibly topic #2, out of the way first. > > -Richard
Perfectly fine with me. I admit I was confused about the three different topics being discussed here. Thank you Sean for clearing that up! And as I said, I am not convinced that #3 is necessary: I can see advantages in terms of consistency, and possibly some day the availability of SHA-1 support in libraries, but I don't see a strict need at the moment. Add to that that this affects existing deployment and it's not trivial. I am not convinced there is a case. In short I agree with Richard that it would be better to park tackling #3. At least until #1 and #2 are resolved or there is a more convincing argument to abandon SHA-1 here. Tim _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
