[Openid-specs-fapi] Signed HTTP in IETF

[Anders Rundgren]

On 2020-04-20 02:02, Stuart Low via Openid-specs-fapi wrote:
> Hi Anders,

Hi Stuart,

> 
>> Cavage HTTP Signatures appears to have become an HTTP-bis item:
>> https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/
> 
> Interesting. I note the intention of this spec is to facilitate message
> integrity within an SSL border. This seems like a valuable addition.

I may have read the I-D too quickly but I couldn't find anything special regarding TLS except that TLS sometimes is not enough due to end-point termination.


>> Even if it becomes an IETF standard, I will most likely stick to my
>> current https://cyberphone.github.io/doc/web/yasmin.html scheme
>> because using HTTP headers for carrying data of such importance that
>> it must be signed seems like a not entirely recommendable solution
>> since such data may not survive proxies etc.  The "predecessor"
>> WS-Security did (AFAICT) not depend on such features either.
> 
> Creating islands of standards by declaring you will stick with your own
> spec only creates more work for adopters. 

The current alternatives would require a complete redesign, far beyond "syntax".  I guess the non-standard JSON-based cryptographic constructs [1,2] may indeed cause some additional work.  OTOH, they are very much the reason to why the system looks so cool :-)  The foundation for those [3] will be published as an (ISE) RFC later this year.

BTW, FAPI has its own "signature standard" and switching to a future IETF ditto will not be easy since the draft (currently) does not build on the JOSE stack.
Related: https://mailarchive.ietf.org/arch/msg/jose/t5pBMO6YfKvIWYZBSW0bFNjcJbQ/

Conclusion: there will probably never be a true standard for signed HTTP.


> Regarding the reference to
> proxies, if I read the introduction to the httpbis spec correctly, this
> isn't a use case that is intended as it appears to be primarily focused
> on transiting infrastructure owned by a single or cooperating set of
> parties.

 From what I have understood, one of the reasons to why for example the JOSE WG didn't consider such a work-item was the difficult handling of headers by for example reverse proxies.


>> In addition, counter-signing which is great way simplifying system
>> design, also becomes a breeze if you stick to HTTP bodies:
>> https://cyberphone.github.io/doc/saturn/bank2bank-payment.html#6
> 
> Except restricting the method to bodies only also precludes all other
> HTTP methods beyond POST.

Right, I'm a true heretic and and have even been excommunicated by the REST cult :-) Seriously, what does REST bring for information-rich messaging of the kind used in Saturn? Self-contained strongly typed message-objects seemed like a better idea.

Only the [for Saturn crucial] discovery services use REST-looking unauthenticated GET operations:
https://mobilepki.org/webpay-payeebank/payees/86344

> 
>> However, putting an explicit "recepientUrl" in message requests is
>> though logical since it is useful information for both parties (where
>> did I send it? am I the proper receiver?):
>> https://cyberphone.github.io/doc/saturn/bank2bank-payment.html#4
> 
> The httpbis spec seems to be focused on a more generalised signature
> method as opposed to being implementation specific (ie. the header names
> are more generalised such as keyId, signature etc).

Yes, it is media-independent as well.

Anders

1] https://cyberphone.github.io/doc/security/jsf.html
2] https://cyberphone.github.io/doc/security/jef.html
3] https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-17


> 
> Stuart
> 
> 
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>