Re: draft-ietf-httpbis-retrofit and signatures

Henry,

Yes, that’s pretty much what I did here:

https://github.com/bspk/httpsigpy/blob/main/httpsig/__init__.py#L29


And here:

https://github.com/bspk/httpsig-java/blob/bbfca4be8998d16ba79d8fb5c3b01819d1177b66/src/main/java/io/bspk/httpsig/ComponentProvider.java#L116


We would refer to the retrofit draft non-normatively, or the field in the IANA table that the retrofit draft creates, if those were available at the time of publication.

 — Justin

On Nov 20, 2022, at 10:40 AM, Henry Story <henry.story@bblfish.net<mailto:henry.story@bblfish.net>> wrote:

Hi,

 I wanted to add a number of existing headers for signatures
to my software library with the right defaults set, so as to
make it easier to use correctly.

Doing that I stumbled on
https://greenbytes.de/tech/webdav/draft-ietf-httpbis-retrofit-latest.html


Then I realised that the `sf` parameter attached to the  document does
*not* speciy that the `sf` flag means the field should be interpreted as
a dictionary, as I had assumed, because all the examples in the spec do that,
but instead it speaks about an agreement being reached on how to intepret
that header:

"and the expected type of the structured field is known, …” [1]

So I guess that this is the kind of agreement provided
by draft-ietf-httpbis-retrofit for the "compatible fields"…

I could use that list to decide when to interpret a component with
an sf field as a dictionary, a list or an item...
Would I be on the right path?

I guess that is not mentioned in the spec, because draft retrofit is not
an RFC yet.

Henry

[1] draft-ietf-httpbis-message-signatures-14


On 17. Nov 2022, at 14:15, Henry Story <henry.story@bblfish.net> wrote:

Hi,

As I am implementing [Signing HTTP Messages](https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html)

The test suite in the doc is pretty good, but more may be better here…
One could perhaps collect a lot more corner cases by putting together a test
suite.

Such a suite could consist of a set of data in some format each consisting of

* server context data (port, optional name, https or http)
* a (request response) pair, max one of them being optional
* a `Signature-Input` description
* the resulting signature base
* a signature, using one of the keys
* whether the signature is valid, and if not why not (eg. the date specified is
semantically invalid)

Then one could discuss all kinds of corner cases, and come up with new test cases.
That would allow one to collect difficult cases, with explanations as to why that
is the correct result when it is not easy to see.

It would also be good if there were a channel to discuss these cases, such as perhaps the IETF [Zulip Http Signature](https://zulip.ietf.org/#narrow/stream/225-httpbis/topic/Signing.20HTTP.20Messages) stream? If we can publicize it for implementors we may get some interesting feedback that way, without needing to bother the whole mailing list here.

Here is a little question I have for example. The spec says in §2.2.5 that for a request

```HTTP
CONNECT www.example.com:80 HTTP/1.1
Host: www.example.com
```

the  `@request-target` attribute should have as value the content of the string "www.example.com:80" . Is that specific
to `CONNECT`? What should the value be for?

```HTTP
GET http://example.com:80/hello HTTP/1.1
```

should it be "http://example.com:80/hello" or "http://example.com/hello" because the 80 is the default port for `http`.

If I am asking myself questions here, I guess many other implementors will too, and they may come to different conclusions.

It could also be useful to have a forum or DB where people can explain problems with intermediaries that comes with experience deploying this, so that people building specs on this could make informed choices of headers to sign.


Henry Story

PS. I have mostly completed my update with tests here:
https://github.com/bblfish/httpSig/pull/12



https://co-operating.systems

WhatsApp, Signal, Tel: +33 6 38 32 69 84‬
Twitter: @bblfish


Henry Story

https://co-operating.systems

WhatsApp, Signal, Tel: +33 6 38 32 69 84‬
Twitter: @bblfish