add RFC for Flux security signatures #391
Conversation
garlick
force-pushed
the
rfc39
branch
4 times, most recently
from
b4cd722
to
69ee401
Compare
garlick
changed the title
|
This is ready for a review when someone has a moment. |
| Signing SHALL consist of the following steps: | ||
|
|
||
| #. Set the signature component to the string ``none``. | ||
|
|
There was a problem hiding this comment.
For the curious, include how header and payload are constructed for sign-type=none?
There was a problem hiding this comment.
The header and payload are the same regardless of mechanism and can be read or written in a mechanism independent manner. Maybe I'd better call that out explicitly!
Well that statement is almost true - the header can optionally contain mechanism specific values, although for none and munge it does not.
There was a problem hiding this comment.
Oh duh, sorry you do explicitly state that above but it may be helpful to re-state it in the 'none' section. Sorry!
| #. Check that the signature component is the string ``none``. | ||
|
|
||
| #. Check that the real user id matches the header userid. | ||
|
|
There was a problem hiding this comment.
Include how payload is extracted?
There was a problem hiding this comment.
Sorry, you do state that the payload is always base64 encoded, my bad!
| The header is not encrypted. | ||
|
|
||
| - The *payload* is an arbitrary sequence of zero or more bytes that | ||
| SHALL be base64 encoded. The payload is not encrypted. |
There was a problem hiding this comment.
Do you want to specify a particular variant of base64?
There was a problem hiding this comment.
Great point. Looks like we're using rfc4648 "standard base64". I'll call that out.
In flux-security, we use libsodium SODIUM_BASE64_VARIANT_ORIGINAL
In flux-core we use ccan base64_maps_rfc4648.
|
|
||
| The header SHALL contain the following keys: | ||
|
|
||
| version (integer) |
There was a problem hiding this comment.
How are integers encoded? UTF-8 string? binary values of a certain length? MSBF? etc.
There was a problem hiding this comment.
This is defined in RFC 38.
| version (integer) | ||
| The Flux Security Signature version (currently must be set to 1). | ||
|
|
||
| mechanism (string) |
There was a problem hiding this comment.
How is this string encoded? NUL terminated?
Or are integer and string encodings defined in another RFC?
spec_39.rst
Outdated
| #. Compute the SHA-256 hash digest over HEADER.PAYLOAD | ||
|
|
||
| #. Construct a MUNGE payload by concatenating a single byte *hash type* field | ||
| of *1* (indicating SHA-256) and the SHA-256 hash digest. |
There was a problem hiding this comment.
How is the 1 represented? Is this the ASCII character 1? Or a single byte signed or unsigned int?
How is the SHA-256 hash digest represented? As a 64-character string? NUL terminated? Or a 32-byte binary encoding?
Would a delimiter between hash type and hash digest be helpful? If they're both in ASCII, a 65-character string of [0-9A-F] might cause confusion at some point. If they're both in binary, it probably doesn't matter.
There was a problem hiding this comment.
The 1 is a single byte and the SHA-256 digest is the binary encoding. I'll try to make those more clear.
If they're both in binary, it probably doesn't matter.
This. Although looking back, I'm not sure why it didn't go in the structured HEADER portion.
Problem: Flux-security signatures are undocumented. Add RFC 39.
|
Thanks for the excellent comments @dun - just pushed some tweaks to address them. |
Problem: flux security signature format is undocumented.
This is a work in progress RFC that attempts to document the format.