Re: signatures vs sf-date

[Julian Reschke <[e-mail]>]

On 02.12.2022 15:25, Justin Richer wrote:
> On Dec 1, 2022, at 12:16 PM, Julian Reschke <[e-mail]> wrote:
>>
>> Hi there.
>>
>> Currently the signatures draft relies on structured fields as defined in
>> RFC 8941 - that is, without the date type we are currently working on.
>>
>> We need to make a few decisions here:
>>
>> 1) Should signatures *use* the date type in the field(s) it defines
>> ("created" TS)?
>
> It could, but I don’t think it’s worth delaying signatures over. There are two timestamp fields (created and expires) with clear semantics, I don’t see a huge value to waiting. I’d like to hear feedback from implementors about how this would affect their code — I know from my part that I rely on structured field libraries (notably yours on the Java side) that would need to be updated for the new format first.

Agreed. (But note I'm already working on the sf-date support).

>> 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?

Best regards, Julian