Re: signatures vs sf-date

[Justin Richer <[e-mail]>]

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.

> 
> 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. :)

 — Justin