Start on asymmetric signing protocol sketch

haskell-mafia / zodiac

API request-signing utilities

BSD 3-Clause "New" or "Revised" License

2 stars 2 forks source link

Start on asymmetric signing protocol sketch #3

Closed olorin closed 8 years ago

olorin commented 8 years ago

This is nowhere near complete, it's just a start so I can get some feedback early on.

This isn't intended to be read as a spec, just a description with sufficient detail to uncover any obvious flaws.
No plans for now to support any hash function except SHA256, or any signature algorithm except ed25519. I've specified including their identifiers in the request headers in case this changes later on; happy to either leave as-is or specify that only those algorithms are supported if other people have opinions?
The description of canonical requests will also be used for the symmetric HMAC protocol.

@markhibberd

/cc @erikd-ambiata @thumphries

erikd-ambiata commented 8 years ago

I'm definitely not a crypto guy, but this seems reasonable to me!

thumphries commented 8 years ago

Obviously my opinion on protocol and crypto stuff should be taken with a pound of salt, but

I've specified including their identifiers in the request headers in case this changes

Are those likely to change at any point? I guess they might for speed reasons? Seems harmless to start doing this now, in any case.

Looks good to me, nothing fishy stood out.

olorin commented 8 years ago

Are those likely to change at any point? I guess they might for speed reasons? Seems harmless to start doing this now, in any case.

I'm thinking of the hypothetical unlikely case where SHA2 is discovered to be horribly broken a year from now and we need to switch everything to use a new primitive quickly. This could be handled equally well by just releasing a new version of the protocol I guess, but it seems cleaner to include primitive swappability from the start, especially if we consider releasing the spec for others to use at some point.

erikd-ambiata commented 8 years ago

Yep, you want to explicitly document the algorithms in headers so that if they need to change managing the change is easier,

olorin commented 8 years ago

@thumphries @erikd-ambiata does this look good to merge to you? I'll definitely need @markhibberd to sign off on it at some point, but as this is just a draft anyway I think there's no harm in fleshing it out beforehand.

thumphries commented 8 years ago

Yeah, looked good. I didn't provide a 🍧 because I figured you'd merge on mark's approval.

olorin commented 8 years ago

Yeah, looked good. I didn't provide a :shaved_ice: because I figured you'd merge on mark's approval.

Yeah, that was my initial plan, but now I figure it's probably easier to get Mark to review a somewhat-complete draft rather than bit-by-bit if everyone else is okay with that - I can keep developing this on diverging topic branches, but that gets unwieldy after a while.

erikd-ambiata commented 8 years ago

Yeah, looks good to me too.