Web Signature Directory v0

omz13

Some initial thoughts on WSD v0:

As WSD was based on WKD, it would really help if it was similarly structured (and that will also mean the missing IANA considerations will be apparent).

I much prefer when examples are inline with the section that they apply to, instead of as an appendix... it makes it easier to see what's going on, especially with a new spec when things tend to be in flux.

WSD. Does this operate like direct vs advanced mode? It seems to be only direct mode... but then in A.2 the concept of a WSD Service Provider appears (and I'd expect that to be more like advanced mode, which isn't supported).

2.1.1. "To allow the mapping of incoming HTTP requests directly to the file system" ... that is a big assumption (mapping requests to storage in a file system)

2.1.1. what are the limits (minima and maxima) for size (length) of "local-part"?

"Service providers may require additional authentication methods that may necessitate the use of JavaScript" ... if authentication is required, the endpoint should return 401/403 and WWW-Authenticate headers as a clue for what to do

3.1. "newline-separate value" ... all header: value things are newline separated, so that is superfluous.

3.1 why does you need a "timestamp" header? what purpose does it serve? (if you do need it, better named as "wsd-timestamp" than just "timestamp"

3.1 "the upload MUST be aborted and return" => "the upload MUST return" (2 instances)

"WSD servers SHOULD NOT index the WSD well-known directory." there is better phrasing in §5 of WKD for this.

yarmo

Thanks for taking the time to provide feedback on WSD v0!

omz13 As WSD was based on WKD, it would really help if it was similarly structured (and that will also mean the missing IANA considerations will be apparent).

I tried to make the structure as similar as possible. This is my first foray in specs so if there's something obvious I'm doing wrong, do let me know.

As for IANA considerations, I wanted to include that as soon as the WSD seems mature enough to publish it on IETF. Again, I do not know the IETF procedures yet, but I imagine IANA won't just accept any request, right? Wouldn't they prefer an IETF-published spec?

If you think IANA considerations can be made outside IETF or more "official" spec channels, I will add it right away.

omz13 I much prefer when examples are inline with the section that they apply to, instead of as an appendix... it makes it easier to see what's going on, especially with a new spec when things tend to be in flux.

I think I would prefer that too. Again, in my attempt of modelling it after the already-successful WKD, I copied their structure. Do you have an example RFC with good inline examples? I'll go look.

omz13 WSD. Does this operate like direct vs advanced mode? It seems to be only direct mode... but then in A.2 the concept of a WSD Service Provider appears (and I'd expect that to be more like advanced mode, which isn't supported).

Since the identifier is an URI, I figured direct/advanced mode doesn't apply here. In WKD, it's necessary because the key-hosting domain may not be the same as the email-hosting domain. Here, the URI contains the key-hosting domain, so it will always be "direct mode".

In my reasoning, WSD Service Providers can still work with "direct" mode, the URI follows the same pattern: wsd:domain:arbitrary_identifier

omz13 2.1.1. "To allow the mapping of incoming HTTP requests directly to the file system" ... that is a big assumption (mapping requests to storage in a file system)

The spec doesn't per se recommend it, but this way of doing it does allow the hoster to just map to a directory in the file system. I think that's a good solution for people with static sites and simple reverse proxy configurations. What would be the issue in your opinion?

omz13 2.1.1. what are the limits (minima and maxima) for size (length) of "local-part"?

Very good point that I had not yet considered! To me, 1 char can be the minimum. We could set a maximum of 40 chars to allow the identifier to be the fingerprint of an OpenPGP key, not sure if there are longer strings we would like to support. UUIDs perhaps? They are 36 chars.

omz13 "Service providers may require additional authentication methods that may necessitate the use of JavaScript" ... if authentication is required, the endpoint should return 401/403 and WWW-Authenticate headers as a clue for what to do

That makes sense!

omz13 3.1. "newline-separate value" ... all header: value things are newline separated, so that is superfluous.

That is not entirely what I meant, so: 1) my explanation was bad and 2) it would be great to find a simpler solution to this issue.

Here's the body of one of the example requests (separated over multiple lines to make it easier to read):

message=And+the+clocks+were+striking+twelve.

&signature=untrusted+comment%3A+signature+from+minisign+secret+key%0D%0ARUQV3WT6S7EM6ysa2O%2FHz7NW3XOQxQQOso5YkOUFFOPc7bjHoLM3Av1UenznN5eFg5lLz%2FoCkWTnQUI6rtwUkBy%2BRewH%2FpC88wk%3D%0D%0Atrusted+comment%3A+timestamp%3A1669125390%09file%3Amessage.txt%09hashed%0D%0A7dA7CDa4mNvxarvpnsnSCSaXPLLvbvLHMRU0puqfGwtbJxTEBNwGNlDyDKlUA9hj4yaylNHURAEEfPR0OvleDQ%3D%3D

&header=timestamp%3A+1669125390

&header-signature=untrusted+comment%3A+signature+from+minisign+secret+key%0D%0ARUQV3WT6S7EM68firzxIKT4bh1lMwDmXEPfSnjLRzwJdyzudqBKUCpD0I68u2mulPUkz4dyR9Qn3Uq0BDknidfLR9ZbCT7F51wU%3D%0D%0Atrusted+comment%3A+timestamp%3A1669125430%09file%3Aheader.txt%09hashed%0D%0ATKPyKTEbtx8fUhCtCLYjpudlgjUnXE9ZaZWsW42J%2BpOX2mAJa4JRi%2FRF53ws2MLzYHUKTTe0KFOKzqDvor9OCw%3D%3D

I need to sign the request with a timestamp to create a pseudo-TOTP to prevent resubmission at a later moment of an intercepted request. I took inspiration from the ActivityPub HTTP signatures.

I did not want to use actual HTTP headers because I tried to make the whole process compatible with JS-less HTML forms. Thus, I created two fields: header (by lack of a better term) and header-signature in the body. I now think this needlessly complicates the story. It would be sad not to support JS-less forms but using the Date header makes more sense than putting the date inside a header field inside the body of the request.

omz13 3.1 why does you need a "timestamp" header? what purpose does it serve? (if you do need it, better named as "wsd-timestamp" than just "timestamp"

See response above.

omz13 3.1 "the upload MUST be aborted and return" => "the upload MUST return" (2 instances)

Will fix.

omz13 "WSD servers SHOULD NOT index the WSD well-known directory." there is better phrasing in §5 of WKD for this.

Will fix.

omz13

I tried to make the structure as similar as possible. This is my first foray in specs so if there's something obvious I'm doing wrong, do let me know.

FWIW, as you use markdown, there is a nice flow from markdown -> xml2rfc (using mmark)-> rfc (using xml2rfc)

(If you need help with this ask and I can sen

For the IANA stuff, the quick version is that you have to have a spec somewhere, some use, then ask them to add pointers to the spec into the appropriate registry. It is generally a good idea to, even if you don't pursue formal IANA registration, to keep a note anyway of where you may need to formalise things.

good inline examples

Take a look at IndieAuth for a non-RFC example of the top of my head.

The spec doesn't per se recommend it...

That is not how it reads to me.

but this way of doing it does allow the hoster to just map to a directory in the file system. I think that's a good solution for people with static sites and simple reverse proxy configurations. What would be the issue in your opinion?

You're being a bit prescriptive here, assuming how it would be implemented.

Very good point that I had not yet considered! To me, 1 char can be the minimum. We could set a maximum of 40 chars to allow the identifier to be the fingerprint of an OpenPGP key, not sure if there are longer strings we would like to support. UUIDs perhaps? They are 36 chars.

1 char minimum is too low. You want something a bit longer because somebody will try to harvest what's available. I'd guess minimum 10 or better yet 20 characters. Yes, a UUID would be a good basis (and is trivial to implement).

To add to §3, probably want to have a limit on the size of the payload that can be uploaded.

I need to sign the request with a timestamp to create a pseudo-TOTP to prevent resubmission at a later moment of an intercepted request ... It would be sad not to support JS-less forms but using the Date header makes more sense than putting the date inside a header field inside the body of the request.

Another method to guard for replay is for the server to generate the form with a hidden field containing a OTC/nonce/whatever, then when it is submitted it checks that the OTC/nonce/whatever hasn't been used already... clearly this involves more work on the server side, but it is fairly easy to implement.

Also, looking at the examples, would it not be better if these were actual signed proofs instead of contrived messages?

yarmo

omz13 FWIW, as you use markdown, there is a nice flow from markdown -> xml2rfc (using mmark)-> rfc (using xml2rfc)

Cool, thanks for the links! So this is how I convert markdown to the rfc format? And then what I can use to publish an Internet-Draft?

omz13 For the IANA stuff, the quick version is that you have to have a spec somewhere

Good, will add then!

omz13 That is not how it reads to me.

It only says "to allow", this has no imperative meaning to me. But we can change the phrasing to make it more optional sounding.

omz13 You're being a bit prescriptive here, assuming how it would be implemented.

Not my intention. I am absolutely fine removing any mention of the file system, it provides context but that doesn't specify anything itself. This consideration too was inspired by WKD, as I quote from section 3.1.:

Although URIs are able to encode all kind of characters, straightforward implementations of a key directory may want to store the local-part of a mail address directly in the file system. This forbids the use of certain characters in the local-part. To allow for such an implementation method the URI uses an encoded form of the local-part which can be directly mapped to a file name.

omz13 1 char minimum is too low. You want something a bit longer because somebody will try to harvest what's available.

Smart! Would you make that SHOULD or MUST? I feel like people should have a choice on their own servers. If they want to name a signature "sig" and they understand the implications, who am I to make a WSD client that refuses to fetch this signature because the name is too short? But for WSD service providers, yes, they should absolutely be mindful of the names they give to signatures.

In other words, if you want to make a minimum amount of chars mandatory, why not mandate that signature identifiers are UUIDs? Then there's no more confusion on naming policies

omz13 To add to §3, probably want to have a limit on the size of the payload that can be uploaded.

Smart, will add.

omz13 Another method to guard for replay is for the server to generate the form with a hidden field containing a OTC/nonce/whatever, then when it is submitted it checks that the OTC/nonce/whatever hasn't been used already... clearly this involves more work on the server side, but it is fairly easy to implement.

I was trying to allow for stateless implementations of the server by using timestamps instead of nonces. Storing nonces also may leave a log of what signature is being uploaded when.

omz13 Also, looking at the examples, would it not be better if these were actual signed proofs instead of contrived messages?

I guess I could add a proof signature but it's important to me that this spec is for generic cryptographic signatures, not just for Keyoxide-related signatures.

omz13

yarmo Cool, thanks for the links! So this is how I convert markdown to the rfc format? And then what I can use to publish an Internet-Draft?

Yes. You write in markdown. You then use mmark to convert to xml format, which is what you need when submitting to rfc-editor; to preview how it will render in various formats xml2rfc

Would you make that SHOULD or MUST

Refer to the RFC2119 for the precise meanings.

why not mandate that signature identifiers are UUIDs? Then there's no more confusion on naming policies

If going down the UUID route you also have to specify which UUID (normally v4)... and as this is something people get wrong too easily, sometimes its easier to simply say 20 random letters and numbers. YMMV.

I guess I could add a proof signature but it's important to me that this spec is for generic cryptographic signatures, not just for Keyoxide-related signatures.

What I'm missing is the big picture how this fits in with everything else in the Ariadne/keyoxide world... a user case and an end-to-end example would really help.