Re: [TLS] TLS-OBC proposal

[Dirk Balfanz <[e-mail]>]

On Tue, Aug 23, 2011 at 4:25 PM, Chris Richardson <[e-mail]>wrote:

> I think the draft is inconsistent with respect to the
> certificate_authorities list.
>
> From section 3.3: "[if both sides include the extension], client and
> server are considered to have negotiated origin-bound client
> certificates for the session."
>
> No problem there.
>
> From section 3.4: "the server MAY use an empty "certificate_authorities"
> list"
>
> Should that be a MUST, or at least a SHOULD?  If OBC has been
> negotiated, why would a CA-signed cert be used?
>

Agreed. I'll fix it. Probably a SHOULD, just in case some servers find it
hard to turn off their standard list of CAs?


>
> From section 3.4: [the client] MUST ignore the "certificate_authorities"
> list
>
> No problem there, but it again makes me think the server SHOULD/MUST
> send an empty list.
>
> Section 3.5: If the "certificate_authorities" list in the Certificate
> Request is empty, that certificate SHOULD be an origin-bound
> certificate, and it should be selected by the client without any
> assistance or approval by the end-user. If the
> "certificate_authorities" list in the Certificate Request is not
> empty, the client MAY select a regular certificate for inclusion in
> the Client Certificate message, and MAY involve the end-user in the
> certificate selection process."
>
> The client MUST ignore the list, but MAY take action based upon the
> content of the list?
>

Good catch - you're seeing a bad merge of two different versions of this
section. The one I meant to be in there is the one where the client MUST
ignore the list (long story...:-).

I'll collect more comments for now (instead of fixing it right away), but I
will make sure that gets fixed in the next draft.

Dirk.



>
> Chris
>
>
> On Mon, Aug 22, 2011 at 1:53 PM, Dirk Balfanz <[e-mail]> wrote:
> >
> > Dear TLS-WG,
> > I few weeks ago I presented a proposal for an "origin-bound certificates"
> TLS extension at IETF 81. It's much easier to understand what this extension
> is trying to accomplish when presented in a broader context of web
> authentication (which I tried to give in Quebec), so I put together a little
> web site that is supposed to do just that for those who couldn't be at the
> IETF meeting: http://browserauth.net (This took me a little while, hence
> the delay in sending out the I-D).
> > Anyway, here is the I-D:
> http://tools.ietf.org/html/draft-balfanz-tls-obc, which I submit for your
> comments/feedback. (Again, remember to read http://browserauth.net for
> some context.)
> > All feedback is welcome, of course, but if you can't think of anything to
> comment on, I have a couple particular questions:
> > - in Section 2.1.1 we currently stipulate that the client include the
> origin of the origin-bound cert as part of the OBC X.509 extension. When we
> implemented this, we didn't really know what to do with that data on the
> server side. If the client also uses TLS-SNI, then we could imagine
> comparing the SNI and OBC origins in some manner on the server side, but
> there isn't really a vehicle to signal an error back to the client saying
> "your SNI and OBC origins don't match". Similarly, we could perhaps at some
> higher layer compare the HTTP "Host" header with the OBC origin, but then
> again - what do you do when they don't match? Respond with a 400 at the HTTP
> layer? An alternative to the current language in the I-D would be to simply
> mark the cert as origin-bound, but without putting the origin itself into
> the cert. Any thoughts?
> > - What do you think of the privacy-enhancing power of using per-origin
> certs? The idea there is that different domains see different "identities"
> (public keys) for the same client. Of course, if two domains choose to
> collaborate, they can probably find a way to correlate the two identities
> they see for the same client. This is similar to cookies, where normally
> "identities" (cookies) for one domain are not revealed to another domain
> unless, of course, they choose to collaborate. How much privacy would we
> really lose if we just used one certificate for all origins? It would
> certainly make the design and implementation simpler. (I tend to favor
> per-origin certs, but I'm curious as to what other people think.)
> > Thanks for your consideration!
> > Dirk.
> >
> > _______________________________________________
> > TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
> >
>