Signing and Certs
Singpolyma
(since a CA-based signing method has been chosen). CAcert.org and/or
StartcomSSL should definitely be on such a list, so that everyone can
sign their documents. Unsigned discovery is basically useless for
most interesting things (OpenID, key / contact info discovery, etc)
Blaine Cook
b...@gmail.com, the discovery document served from
https://gmail.com/.well-known/host-meta is authentic as long as the
HTTPS session is verified. If GMail points to a 3rd party site, then
the same must be true there, and so on.
Relying on a custom CA list is frankly a non-starter for me. There's
no way that we're going to have adoption if developers need to (1)
learn how to use some new method for content verification and (2) do
so against a custom list of CAs and manage CRLs and all the related
garbage. It's hard enough to get people to verify that host name = cn
with a bog-standard HTTPS client.
b.
2009/8/14 Singpolyma <singp...@singpolyma.net>:
Eran Hammer-Lahav
EHL
Dirk Balfanz
Technically speaking, it's up the client to decide which CAs they trust.
But there's nothing wrong with informally pointing people in the direction of startcom et al to get cheap certs. (Although, in the case of startcom, do they still issue MD5-based certs? - I haven't checked...)
Dirk.
Dirk Balfanz
I maintain that if I'm doing discovery against, e.g., gmail.com for
b...@gmail.com, the discovery document served from
https://gmail.com/.well-known/host-meta is authentic as long as the
HTTPS session is verified.
Actually, you can't know that. All you know is that it's really gmail.com that's serving out the document. You don't know whether someone broke into gmail.com and placed the document there. That's why we want host-metas signed with a key that's preferably offline so if someone comes in and defaces your web site, they can't point your host-meta to somewhere else and whole-sale hijack all your user accounts.
Dirk.
Dirk Balfanz
I rather we leave trust/security aside for now. Let's focus on the actual value and once we have it locked down, figure out what we want to sign, etc.
Agreed about the value part. I'm getting a bit nervous whenever I hear "let's worry about security later", but I think in this case I agree b/c someone _is_ worrying it - the XRI TC, etc.
Dirk.
Singpolyma
On Aug 14, 2:44 pm, Dirk Balfanz <dirk.balf...@gmail.com> wrote:
> Technically speaking, it's up the client to decide which CAs they trust.
>
> But there's nothing wrong with informally pointing people in the direction
> of startcom et al to get cheap certs.
support, that's why I said there should be "recommendations".
Most people will probably just use their system's local CA, but if the
big players can be convinced to support one of the good CAs, that will
be a huge win for making this tech something that individuals can
deploy. Prices on certs are coming down (Dreamhost offers really
cheap ones now), but many people just won't be able to do it still
unless one of the free ones are widely supported.
Eran Hammer-Lahav
The XRI TC decided to let protocols define their trust profiles and needs, only defining a framework for signing XRD documents. I think we should use what the Google team has been developing for OpenID.
EHL
Will Norris
On Aug 14, 2009, at 3:07 PM, Eran Hammer-Lahav wrote:
> The XRI TC decided to let protocols define their trust profiles and
> needs, only defining a framework for signing XRD documents. I think
> we should use what the Google team has been developing for OpenID.
>
> EHL
I really don't want to get into a heavy discussion about trust
profiles, but I'm not sure what you mean by "use what the Google team
has been developing for OpenID". If you're referring to the use of a
detached signature carried in the HTTP header, you can't. That
specifically violates XRD, as it is written today. If you're
referring to the Subject matching stuff, then that absolutely makes
sense.
Again, I don't want to dive too deeply into this topic, only to make
sure folks don't go too far down a path that leads to nowhere. In any
event, there is plenty of work that can be done without having to
worry too much about the specifics of the document signing.
-will
Will Norris
On Aug 14, 2009, at 3:19 PM, Will Norris wrote:
>
>
> On Aug 14, 2009, at 3:07 PM, Eran Hammer-Lahav wrote:
>
>> The XRI TC decided to let protocols define their trust profiles and
>> needs, only defining a framework for signing XRD documents. I think
>> we should use what the Google team has been developing for OpenID.
>>
>> EHL
>
> I really don't want to get into a heavy discussion about trust
> profiles, but I'm not sure what you mean by "use what the Google team
> has been developing for OpenID". If you're referring to the use of a
> detached signature carried in the HTTP header, you can't. That
> specifically violates XRD, as it is written today. If you're
> referring to the Subject matching stuff, then that absolutely makes
> sense.
not just the subject matching, but also the stuff the Google team is
proposing around NextAuthority (represented by a Link/KeyInfo element
in XRD). That is very useful stuff when talking about trust profiles.
-will