Re: [sidr] preventing SKI collisions

[Tim Bruijnzeels <[e-mail]>]

Hi,

> On Aug 11, 2015, at 9:12 PM, Richard Hansen <[e-mail]> 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