Subject: [OAUTH-WG] FW: Salmon signatures proposal

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 9 Feb 2010 09:15:02 -0700

http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html

This is relevant to our discussion about how to apply signatures to HTTP requests.

EHL

---

From: "Paul C. Bryan" <[email-masked]>
Date: Tue, 09 Feb 2010 08:36:34 -0800

> This is relevant to our discussion about how to apply signatures to HTTP requests.

Just to get the ball rolling then, if OAuth were to adopt magic
signatures for its requests, then I think the ramifications would be:

1. Payload would need to be embedded in the data element of the
signature, so we'd be duplicating payload to support digital signatures.

2. Some standardization of signer identifier (in the decoded data
element) would need to be selected.

3. Presumably we would not be using LRDD/XRD to discover the public key
of the signer, but rather use the key that server issues to client?

Paul

> 
> EHL
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Paul C. Bryan" <[email-masked]>
Date: Tue, 09 Feb 2010 08:46:39 -0800

P.S. for #3, I meant to be for the symmetric-key cases.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 9 Feb 2010 09:59:15 -0800

Could you clarify how you think it's relevant?

ISTM that the major parts of the document are:
-- Format for encoding a signature on arbitrary binary data
-- Key discovery process

I don't think it really makes sense to use the magic envelope format  
for signing HTTP requests, mainly because there's no need to replicate  
the data (since TCP guarantees that the recipient gets same sequence  
of bytes that was sent).  The only things in the signature besides the  
data are the encoding/algorithm IDs and the signature, which is a  
small enough, constrained enough set of information that the encoding  
isn't a huge deal.

In particular, the magic signature system doesn't address what parts  
of the HTTP request get signed, and how they get normalized -- the  
hard question of OAuth.  All it really does is raise the idea of just  
blindly signing bytes, which might be a good idea here: Just take the  
whole HTTP request with the OAuth header removed and sign/verify it as  
a sequence of bytes. That sort of signature probably wouldn't survive  
things like proxies, though.

Are you proposing to use the key discovery process?  Even there, it  
doesn't seem like there's a whole lot of utility, given that the other  
major work of this group is defining a key management system.

Just confused,
--Richard

---

From: John Panzer <[email-masked]>
Date: Tue, 9 Feb 2010 10:10:26 -0800

Not arguing pro or con using this for HTTP message signing, but clarifying a
few points:

On Tue, Feb 9, 2010 at 9:59 AM, Richard L. Barnes <[email-masked]> wrote:

> I don't think it really makes sense to use the magic envelope format for
> signing HTTP requests, mainly because there's no need to replicate the data
> (since TCP guarantees that the recipient gets same sequence of bytes that
> was sent).

Only if you consider the 'recipient' and 'sender' to be the actual machines
talking to the raw sockets.  But fewer and fewer people are doing that
today.  Everyone is at least relying on an HTTP library (so the chunked
encoding details are hidden from you), and most everybody is sitting on top
of a stack or embedded within a framework that they can't easily change.
 E.g., by the time a message goes through Apache and to a JSP servlet
container, it may well have already normalized data and converted character
sets (by default you definitely get data converted to UCS-2 of course).

And then of course there are proxies :).

>  The only things in the signature besides the data are the
> encoding/algorithm IDs and the signature, which is a small enough,
> constrained enough set of information that the encoding isn't a huge deal.
>
> In particular, the magic signature system doesn't address what parts of the
> HTTP request get signed, and how they get normalized -- the hard question of
> OAuth.  All it really does is raise the idea of just blindly signing bytes,
> which might be a good idea here: Just take the whole HTTP request with the
> OAuth header removed and sign/verify it as a sequence of bytes. That sort of
> signature probably wouldn't survive things like proxies, though.
>

The Magic Signature spec is unabashedly an enveloping system that takes the
bytes and armors them.  If you are dealing with a system that MUST
understand your signature algorithm, you then don't have any need to send
the original bytes, just the armored ones.  (And do you really want someone
relying on unsigned bytes?)  At which point, if you're doing HTTP requests,
you're effectively tunneling an HTTP request (the important part) inside a
request payload.  It's very, very ugly, and (it seems to me) is basically
replicating SSL but at the wrong layer.

>
> Are you proposing to use the key discovery process?  Even there, it doesn't
> seem like there's a whole lot of utility, given that the other major work of
> this group is defining a key management system.
>

I do hope that the key discovery process (starting from an identifier for an
author/sender identifier) is something that is re-usable and generic.  And
specifically, if I have an OAuth public key signed message, along with an
identifier for the service that signed it, I would very much like to use
this mechanism for discovering public key(s) for the service.  Since we can
represent both services and people as URIs this seems fairly straightforward
and reasonable.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 9 Feb 2010 10:33:44 -0800

Couple of other observations:

> Only if you consider the 'recipient' and 'sender' to be the actual  
> machines talking to the raw sockets.  But fewer and fewer people are  
> doing that today.  Everyone is at least relying on an HTTP library  
> (so the chunked encoding details are hidden from you), and most  
> everybody is sitting on top of a stack or embedded within a  
> framework that they can't easily change.  E.g., by the time a  
> message goes through Apache and to a JSP servlet container, it may  
> well have already normalized data and converted character sets (by  
> default you definitely get data converted to UCS-2 of course).

That's a fair point, and one of the main challenges for figuring out  
what to sign ...

> And then of course there are proxies :).

... this being the other :)

> The Magic Signature spec is unabashedly an enveloping system that  
> takes the bytes and armors them.  If you are dealing with a system  
> that MUST understand your signature algorithm, you then don't have  
> any need to send the original bytes, just the armored ones.  (And do  
> you really want someone relying on unsigned bytes?)  At which point,  
> if you're doing HTTP requests, you're effectively tunneling an HTTP  
> request (the important part) inside a request payload.  It's very,  
> very ugly, and (it seems to me) is basically replicating SSL but at  
> the wrong layer.

Beyond the ugliness, if you send both the armored and unarmored bytes,  
you're introducing a security risk.  Namely, the recipient might  
validate the signature over the armored bytes, then go on to use the  
unarmored request, which could be completely unrelated.

> I do hope that the key discovery process (starting from an  
> identifier for an author/sender identifier) is something that is re- 
> usable and generic.  And specifically, if I have an OAuth public key  
> signed message, along with an identifier for the service that signed  
> it, I would very much like to use this mechanism for discovering  
> public key(s) for the service.  Since we can represent both services  
> and people as URIs this seems fairly straightforward and reasonable.

But it still seems separable from the authentication system.  As  
usual, there's a "find the key for the client" step before the  
verification.  That step is deliberately unspecified in order to allow  
for multiple key management systems to be used with the same  
authentication protocol.

--Richard

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 09 Feb 2010 13:58:36 -0500

Paul C. Bryan wrote:
> ...
Would not just hash of the payload be enough?

Igor

---

From: "Paul C. Bryan" <[email-masked]>
Date: Tue, 09 Feb 2010 12:06:19 -0800

> Would not just hash of the payload be enough?

I guess as long as there were rules on how to normalize the payload
before hashing it.

Paul

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 09 Feb 2010 15:40:25 -0500

But what would be a problem with just running a hash function over the 
payload as is?  Seems to me that this way the recipient could check the 
validity of the signature for this particular payload, right?  Or is 
there some strange case where the payload gets modified in transit 
legitimately?

Igor

---

From: "Paul C. Bryan" <[email-masked]>
Date: Tue, 09 Feb 2010 12:44:52 -0800

> there some strange case where the payload gets modified in transit 

The payload would be: method, URI, protocol, headers and entity.
Intermediaries (e.g. proxies) are known for (legitimately) modifying
various parts of payload in transit, for example
adding/removing/reordering headers.

Paul

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 09 Feb 2010 15:51:28 -0500

I dreaded that this might be the case. Then I agree it is necessary to 
normalize the payload, unless signing the entity only is sufficient.

Igor

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 11 Feb 2010 17:59:05 +1100

John,

I like your choice of base64url as a way to armour binary data and avoid escaping issues.

It might be nicer to sign the bytes that get armoured, instead of the ASCII output of the armouring.
I don't think this compromises the robustness aim of Magic Signatures.
It would mean you sign the binary message, then use base64url armouring to ensure the exact bytes signed make it unaltered to the other end. The armouring applies equally to the data and signature, but isn't actually involved in the crypto.

An extra little advantage is that the code to remove the armour [eg byte[] dearmour(String)] can also skip whitespace. With the current arrangement, a separate step to remove the whitespace is required as you need the base64url encoding without whitespace to verify the signature.

The example used throughout the spec is wrong. It looks like two "-" characters have been accidentally dropped (which is not a good advertisement for the robustness that base64url offers!)
4th line:  change "bWUPHVy" to "bWU-PHVy" (decodes to "me><ur")
10th line: change " bGUU2Fs" to "bGU-U2Fs" (decodes to "le>Sal")

Curiously, there are no "_" characters in the examples (data or sig). Changing the <title> to end with a "?", instead of a "!", would introduce one. Base64url is uncommon so examples using its differences from normal base64 might help catch a few implementation bugs.
[actually I just noticed a "_" in the example modulus, but one in the example data would be even better]

The signature is wrong, but not random so it is misleading.
Decrypting the example signature with the example key produces a 20-byte value -- which happens to the be SHA-1 hash of the empty string (I don't recognize many hash values on sight, but this is one of them!).
It should be the hash of the (armoured) data.
It should be a SHA-256 hash, not SHA-1 as per <me:alg>RSA-SHA256</me:alg>.
It should be wrapped in a DER-encoded DigestInfo structure (basically includes an id for SHA-256).
It should have the PKCS#1 v1.5 "block type 1" prefix (01 FF FF… 00 <DigestInfo>), making the value a similar size to the modulus.

Sorry for being picky ;)

-- 
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 11 Feb 2010 00:13:09 -0700

Feedback specific to the Salmon proposal should go to the Salmon list [1].

EHL

[1] http://groups.google.com/group/salmon-protocol/subscribe

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Manger, James H
> Sent: Wednesday, February 10, 2010 10:59 PM
> To: OAuth WG ([email-masked]); John Panzer
> Subject: Re: [OAUTH-WG] FW: Salmon signatures proposal - base64url
> 
> John,
> 
> It would mean you sign the binary message, then use base64url armouring to
> ensure the exact bytes signed make it unaltered to the other end. The
> armouring applies equally to the data and signature, but isn't actually
> involved in the crypto.
> 
> An extra little advantage is that the code to remove the armour [eg byte[]
> dearmour(String)] can also skip whitespace. With the current arrangement, a
> separate step to remove the whitespace is required as you need the
> base64url encoding without whitespace to verify the signature.
> 
> The example used throughout the spec is wrong. It looks like two "-"
> characters have been accidentally dropped (which is not a good
> advertisement for the robustness that base64url offers!) 4th line:  change
> "bWUPHVy" to "bWU-PHVy" (decodes to "me><ur") 10th line: change "
> bGUU2Fs" to "bGU-U2Fs" (decodes to "le>Sal")
> 
> Curiously, there are no "_" characters in the examples (data or sig). Changing
> the <title> to end with a "?", instead of a "!", would introduce one. Base64url
> is uncommon so examples using its differences from normal base64 might
> help catch a few implementation bugs.
> Decrypting the example signature with the example key produces a 20-byte
> value -- which happens to the be SHA-1 hash of the empty string (I don't
> recognize many hash values on sight, but this is one of them!).
> It should have the PKCS#1 v1.5 "block type 1" prefix (01 FF FF… 00
> <DigestInfo>), making the value a similar size to the modulus.
> 
> Sorry for being picky ;)
> 
> --
> James Manger

---

From: John Panzer <[email-masked]>
Date: Wed, 10 Feb 2010 23:15:55 -0800

Thanks!

-- 
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

---

From: John Panzer <[email-masked]>
Date: Thu, 11 Feb 2010 15:56:50 -0800

James,

Thanks for the feedback.

[email-masked]
bcc:[email-masked] <[email-masked]>

--
John Panzer / Google
[email-masked] / abstractioneer.org <http://www.abstractioneer.org/> /
@jpanzer

On Wed, Feb 10, 2010 at 10:59 PM, Manger, James H <
[email-masked]> wrote:

> separate step to remove the whitespace is required as you need the base64url
> encoding without whitespace to verify the signature.
>
> characters have been accidentally dropped (which is not a good advertisement
> for the robustness that base64url offers!)
> Curiously, there are no "_" characters in the examples (data or sig).
> Changing the <title> to end with a "?", instead of a "!", would introduce
> one. Base64url is uncommon so examples using its differences from normal
> base64 might help catch a few implementation bugs.