Then there's the question of checking to see if the data in the
envelope is consistent with data outside the envelope. A good way
to do this is to ignore the data outside the envelope and only use
the verified, enveloped data.
This is precisely the problem. But think about what "only usin
Ah ok, I misread your field names as field values :).
Of course recipients can always choose to ignore the result of verifying
signatures (or not verify them at all) no matter what scheme you use.
Note that Magic Signatures is unabashedly an envelope, and well written
libraries make it hard to sh
On Fri, Sep 24, 2010 at 9:06 AM, Eran Hammer-Lahav wrote:
> Validating the signed data delivered with the request is as much magic as
> the current 1.0 approach. Go write the validation rules and see.
>
Done that (for the specific case of Salmon). The only trick is to write the
code so that if t
Maybe I've misunderstood the Magic Signatures proposal. I thought
that the MagicSig blob actually contained the data that was signed, so
that step (3) below would be unnecessary. (Note that the object in
Step 2 has only field *names*, not *values*.) Including the data is
the part of that
Richard,
I'm a bit confused because the made-up example you give below is,
essentially, what Magic Signatures does. The algorithm you present is
basically the correct one IMHO. Are you assuming that the recipient is
_also_ using the HTTP-level method and URL path for some important security
dec
Validating the signed data delivered with the request is as much magic as the
current 1.0 approach. Go write the validation rules and see.
I'm getting really tired of this argument because it is not grounded in
reality. Any attempt to compare the HTTP request to what was signed, whether it
is s
Yes, there is certainly a risk if someone just checks the signature
and
does not verify the content of the message. This is a bad
implementation
of an authorization system, to be sure, and it's an issue that people
need to be aware of. But simply signing metadata doesn't completely
solve the p
> > I think that any signature method that we end up using needs to rely
> > less on magic and anecdote and more on explicit declaration.
>
> This is certainly correct ...
>
>
> > I think
> > that Brian Eaton's approach of sending the bare string that was
> > signed,
> > which was also a JSON
I think that any signature method that we end up using needs to rely
less on magic and anecdote and more on explicit declaration.
This is certainly correct ...
I think
that Brian Eaton's approach of sending the bare string that was
signed,
which was also a JSON element that could be parsed
> If it wasn’t clear, the reason why I am back at fighting for this
> after taking a break for a few months, is based on the recent positive
> experience from the Twitter migration. To me, it completely voids the
> arguments that normalization on the client side is too hard.
I wholeheartedly disag
Thanks Richard.
FWIW, RFC 5849 was stuck in IESG discuss until I the language regarding the use
of HTTPS with plaintext secrets was changed from SHOULD to MUST. Before the
change, the security consideration section clearly highlighted the danger in
not using HTTPS. OAuth 2.0 adds support for sh
I also agree with the observation about consensus being based on
individual voices.
I don't think it's accurate to say that signatures are a generic
security mechanism. As I would think we learned from OAuth 1.0[a], it
can actually be pretty subtle to define how signatures are used in a
I agree with your point that consensus is based on individual voices.
I agree with Eric's points that signatures are a generic security mechanism and
that signatures should be in a separate spec.
-- Dick
On 2010-09-23, at 6:11 PM, Eran Hammer-Lahav wrote:
> It is pretty clear from the recent
>> I believe that an OAuth 1.0a style signature
How about we start with exactly an OAuth 1.0a style signature? It may be
tricky, but there are still client libraries and some web-services that
handle them.
Like Tony, I also have not heard requests for a new signature approach, but
one of the reas
that it will
proceed as a separate item.
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Thursday, September 23, 2010 6:12 PM
To: Eric Sachs; OAuth WG
Subject: Re: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec
It is pretty
It is pretty clear from the recent public response that a core specification
without signatures is going to be viewed as weak and insecure. This has been my
position for over a year, and if it wasn't clear, I am going to continue
expressing it.
We have enough interest to get a basic signature s
-boun...@ietf.org] On Behalf Of Eric
Sachs
Sent: Thursday, September 23, 2010 5:30 PM
To: OAuth WG
Subject: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec
Google wanted to re-state our long standing opinions on HTTP signature
mechanisms in the OAuth2 spec. The short version is
Google wanted to re-state our long standing opinions on HTTP signature
mechanisms in the OAuth2 spec. The short version is that standards for
signing parts of an HTTP request have value in use-cases other than OAuth2,
and thus they should be defined outside the spec, and just referenced from
the s
18 matches
Mail list logo
