Re: [Dcrup] Adam Roach's No Objection on draft-ietf-dcrup-dkim-usage-04: (with COMMENT)

[Brandon Long <[e-mail]>]

On Tue, Oct 24, 2017 at 4:35 PM, Kurt Andersen <[e-mail]> wrote:

> On Tue, Oct 24, 2017 at 8:03 PM, Murray S. Kucherawy <[e-mail]>
> wrote:
>
>> On Tue, Oct 24, 2017 at 12:58 PM, Murray S. Kucherawy <
>> [e-mail]> wrote:
>>
>>> On Thu, Oct 19, 2017 at 3:54 AM, Scott Kitterman <[e-mail]>
>>> wrote:
>>>
>>>> My assumption had been that since there's no valid signature with
>>>> rsa-sha1, there's nothing to even consider putting in an A-R header field.
>>>>
>>>> I think the only result that can go in this case is None.  I hadn't
>>>> thought we'd need to say that, but I guess maybe we do.
>>>>
>>>
>>> I think "policy" is the right way to go.  There's nothing technically
>>> wrong with an rsa-sha1 signature, but you're deciding not to accept it.
>>> It's the same as you deciding you're not going to accept a perfectly valid
>>> rsa-sha256 signature on a message simply because that signature didn't
>>> include the Subject field.
>>>
>>
>> In fact I would claim that by the definitions in Section 2.7.1 of
>> RFC7601, "policy" is the only option.
>>
>
> Are we talking about before or after this group consigns sha1 to the ash
> heap? Perhaps I'm confused about the sequencing of events that we are
> discussing. If the original DKIM spec had allowed rsa-md5 and a previous
> (hypothetical) instance of DCRUP had similarly deprecated MD5, what sort of
> designation would we expect to be recorded today for such usage?
>

This is obviously a bit different, but today google uses policy for keys
under 1024 bits.  I say "different", because prior to the dcrup work being
published, that's our policy choice.  After, it's the standard, so
permerror might be more appropriate.

Brandon