Re: [alto] Redistribution (was: Reprise of REST comments)

["Thomson, Martin" <[e-mail]>]

On 2011-01-06 at 17:32:12, Richard Alimi wrote:
> > I'm not the security guy, but that signature mechanism looks like it
> needs some work.  I like the fact that you have put the signature in
> metadata, but how does a client decide which of the many available
> public keys to use?  There are potentially multiple sources that can
> provide a public key; before redirection comes into play.
> >
> 
> I think Section 8.1.3 should answer the question here. Was it still
> ambiguous after reading this?  If so, we can certainly clarify it.

These comments were based on 8.1.3.1: you present a choice, which is - as I understand it - not always a good thing when you are looking for some security property.
 
> > From an HTTP perspective, I think that you will find that trailers
> are poorly supported.  Current advice indicates that they have to be
> able to be ignored (see [1]), which might interfere with your use case
> - though this is definitely the right way to use trailers.
> 
> That's unfortunate.  I think the requirements here are that an ALTO
> Server should be able to generate and an append a signature even for a
> dynamically-generated response which is streamed (as opposed to
> buffered) to a client.  An alternative was to put the signature as
> some trailing portion of the JSON message (e.g., the last member of
> the outer-most object), but that seemed ugly since it seemed to
> require signing a subset of the JSON message, thus requiring us to
> define some canonical form that would be used for signature
> verification.  Do you know of other alternatives beyond these two?

CMS (formerly S/MIME; RFC 5652 from memory) might work, though I'm certainly not across all the complexities.  By all means avoid enveloped signatures, you really don't want to deal with canonicalization, even if JSON is easier than XML, it's still non-trivial.