I've been loosely following this group, probably not as closely as I should
have. I'll put it in my queue to do a review of the current doc as a way of
getting back in the fray.
--Richard
On Aug 8, 2011, at 1:59 AM, Eran Hammer-Lahav wrote:
> Thanks.
>
> But this still puzzles me. After t
As promised in the OAuth meeting at IETF 83, I have don a review of
draft-ietf-oauth-v2-http-mac-01. I have sent detailed comments to the
authors, which are summarized below.
This document is in pretty good shape. The definition of the
authentication scheme itself, and the OAuth mechanism fo
t; I wouldn't use it for multiple signatures - I'd use
> http://tools.ietf.org/html/draft-jones-json-web-signature-json-serialization-02
> or similar for that.
>
> -- Mike
>
> -Original Message-
> From: Richard L. Barnes [mailto:rba
Gold star to the first person to add support for ASCII art output.
On Jul 30, 2010, at 10:45 AM, Peter Saint-Andre wrote:
As referred to in the tutorial just now:
http://plantuml.sourceforge.net/
Peter
--
Peter Saint-Andre
https://stpeter.im/
__
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
Basically, this argument comes down to which validation pattern you
prefer.
OPTION 1:
0. Input = object + signature
1. Verify match between object data and HTTP fields
2. Verify signature over the object
OPTION 2:
0. Input = signature
1. Construct object data from HTTP fields
2. Verify signatu
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
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
rewalls etc. are not aware of signatures, so I don't
see this as a distinction.)
--
John Panzer / Google
jpan...@google.com / abstractioneer.org / @jpanzer
On Fri, Sep 24, 2010 at 8:26 AM, Richard L. Barnes
wrote:
Yes, there is certainly a risk if someone just checks the signature
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
I think it's more robust to verify than to generate. In option 2,
you have to "guess" what the signer actually signed. To be fair, you
have pretty good signals, like the HTTP request line, the Host:
header, etc., but in the end, you don't _know_ that the signer
really saw the same thing whe
I would say that the security considerations should be based on a model
of OAuth. Start with a model of the protocol and the guarantees you
want, then explain how to use security mechanisms to achieve those
guarantees.
I promised Hannes today to do a review of the current document (which I
a
gt;
--Richard
On 11/10/10 2:03 PM, Anthony Nadalin wrote:
Issue here is that guarantees (and what you want as a guarantee may not be what
somebody else wants) can vary depending on scenario and deployment.
-Original Message-
From: Richard L. Barnes [mailto:rbar...@bbn.com]
Sent: Tuesday,
As such, I can't see how *not* requiring SSL for unsigned requests
could pass muster at an IETF security review.
Speaking as someone who does IETF security reviews ... :)
If I were reviewing a document that defines an optional insecure mode
of operation (in this case, operating without TLS),
ature").
>
> On this basis, it's reasonable to argue for MUST for implementing
TLS (with no weasel words about "or equivalent", since this isn't a
testable protocol clause), for the broad ecosystem benefits.
>
> Eve
>
> On 15 Jan 2010, at 8:06
second peer doesn't like any of the
advertised algorithms, then it says so, and the negotiation fails.
--Richard
On Jan 15, 2010, at 2:21 PM, John Panzer wrote:
On Fri, Jan 15, 2010 at 10:41 AM, Richard L. Barnes
wrote:
I would think not; it's a matter of the client's pol
I'm in the "1.5" camp -- "Use Token with HMAC-SHA256". There's no
point to specifying acceptable tokens, since from the perspective of
the authentication protocol, the token is an opaque string. But it
would be a good idea to specify what the parameters for the
authentication should be.
a server to issue a token with
multiple algorithm and then letting individual resources narrow it
down.
EHL
-----Original Message-
From: Richard L. Barnes [mailto:rbar...@bbn.com]
Sent: Wednesday, January 27, 2010 8:55 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [
It's not clear that XML is always crazy. If you're integrating this
into an XMPP client, it's already used to using XML (i.e., it's
already got a parser/generator), and might not have JSON machinery.
I would suggest pinning down a data model that gets serialized to
different formats depend
ut construction, not parsing. So
technically, no lib is really needed in either case (but can be useful
for data type encoding).
EHL
On Jan 28, 2010, at 7:30, "Richard L. Barnes" wrote:
It's not clear that XML is always crazy. If you're integrating this
into an XMPP client,
his change your mind? If we use
JSON, I expect many existing libraries that produce JSON objects to
fail because of the differences in how they add whitespace.
EHL
-Original Message-
From: Richard L. Barnes [mailto:rbar...@bbn.com]
Sent: Thursday, January 28, 2010 11:32 AM
To: Eran
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
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 ther
23 matches
Mail list logo
