[Openid-specs-risc] Unsigned SETs in SSF events

[Phillip Hunt]

Atul,

I remember this conversation at IETF Sec Events WG.  There are a number of layers of security for SETs that can be invoked which you alude to below. And yes, technically SETs can have signature alg=none.  :-)

As I recall it all boils down to the same trade-off for unsigned JWTs.

I myself use unsigned JWTs for lab testing (sig alg none) in point-to-point scenarios.

Implementations should consider that SSEF Events may also be used for historical purposes (trend analysis, audit).  Signed events can be re-authenticated outside the context of the TLS chennel is lost (e.g. over time).  Signatures may also be critical if events are being relayed through SSEF servers acting as “gateways”.

Phillip Hunt
phil.hunt at independentid.com





> On Feb 27, 2023, at 10:00 AM, Atul Tulshibagwale via Openid-specs-risc <openid-specs-risc at lists.openid.net> wrote:
> 
> Hi all,
> 
> In a discussion last week, the issue of perceived complexity of the Shared Signals Framework came up, and one question within that was whether SSF allows SETs to be unsigned. Section 11.1.8.1 of the SSF spec <https://github.com/openid/sharedsignals/blob/main/openid-sharedsignals-framework-1_0.txt> does not specify that the SETs should be signed, and the SET spec <https://www.rfc-editor.org/rfc/rfc8417.html#section-5.1> (section 5.1) also says that "Unless integrity of the JWT is ensured by other means, it MUST be signed using JWS [RFC7515] by an issuer that is trusted to do so for the use case so that the SET can be authenticated and validated by the SET recipient."
> 
> So since the DELIVERYPUSH and DELIVERYPOLL methods offer integrity protection, neither of the specs require SETs to be signed. 
> 
> Is my understanding correct?
> 
> Thanks,
> Atul
> 
> _______________________________________________
> Openid-specs-risc mailing list
> Openid-specs-risc at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-risc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20230227/3a248068/attachment-0001.html>