Re: signatures vs sf-date

[Julian Reschke <[e-mail]>]

On 02.12.2022 21:58, Justin Richer wrote:
>>
>>>> 2) When signing parts of a SF shaped field, should it support RFC
>>>> 8941bis in some way?
>>>
>>> That should “just work”. If you’re doing SF fields using the SF-bit or anything else that uses strict serialization rules, and your system needs and supports the SFbis definitions, then it should just work. Otherwise if someone sends you something that you can’t parse, well, then you need to figure out how to parse it, right?
>>>
>>> I don’t think there’s any change that needs to be made for that. If SFbis gets out the door first (or even has an RFC number first), we can change the reference and call it a day. Or a @DATE. :)
>>
>> Hmm.
>>
>> If the sender sends something with an sf-date and signs that part,
>> signature validation will fail on the recipient unless it also has SFBIS
>> support, right?
>>
>> So, rephrasing this in a more generic way: once SFBIS is out, do we
>> expect everybody to update their libraries? And if so, what does this
>> man for what we say in the signatures spec?
>>
>
> I think this is going to be the problem with any upgrade that adds any new features to any system, isn’t it? If the signer is sending something in sf-date but the verifier can’t process sf-date … then that field value isn’t going to be processed correctly anyway, is it? Since the receiver wouldn’t be able to handle the sf-date field.
>
> You have to upgrade your libraries and code to support new features. That is unsurprising and hardly unique to this current situation.
>
> The question is what we should do about it here — and I’d argue we shouldn’t do anything about it in particular.

It's a common problem, yes.

But in this case we don't have a version signal *and* timing of the
specs would allow us to be more specific.

(I'm not sure what the right answer is, but it should be a conscious
decision of the WG,  not something that "just happened that way").

Best regards, Julian