[foaf-protocols] Webid Spec: HTTP status codes?

Joe Presbrey presbrey at mit.edu
Sat Aug 14 22:30:45 CEST 2010

Increasing exposure of the SSL requirements sounds very useful if
browsers and mod_ssl will agree.

Further, on an HTTP 401 (in a client-cert-optional setup) I think the
browser/server needs to break the SSL session and/or otherwise get the
user to reselect a certificate.

The goal here would be to make the behavior of client authentication
with SSL consistent with that of Basic and Digest (re-popup username
and password).

Joe Presbrey

On Fri, Aug 13, 2010 at 5:21 PM, Bruno Harbulot
<Bruno.Harbulot at manchester.ac.uk> wrote:
> On 13/08/2010 20:33, Joe Presbrey wrote:
>> On Fri, Aug 13, 2010 at 10:21 AM, Bruno Harbulot
>> <Bruno.Harbulot at manchester.ac.uk>  wrote:
>>> What I was suggesting is to complement that (perhaps using some
>>> re-negotiation) with suitable information at the HTTP layer (so a
>>> non-trusted certificate wouldn't be accepted, but simply ignored rather
>>> than terminating the TLS connection).
>> I agree. This should be described as a Best Practice.
>>> This is of course not a trivial thing to do, since it would require some
>>> work on both sides (client and server).
>> We can already do this with modifications to mainstream servers and
>> modules, Apache/mod_ssl, and have demos.  Or I didn't understand what
>> you were describing (sorry).
> I'm describing the fact that, instead of relying on the
> certificate_authorities list in the CertificateRequest TLS message as
> the sole way of giving a hint regarding which certificate to select (or
> error code for what went wrong), we could use a WWW-Authenticate header
> for this.
> For example:
>    WWW-Authenticate: Transport
> layer=TLS;trust_type=PKIX;certificate_authorities=x,y,z
> or (more appropriate for WebID):
>    WWW-Authenticate: Transport layer=TLS;trust_type=WebID
> even maybe:
>    WWW-Authenticate: Transport
> layer=TLS;trust_type=WebID;you_need_to_be_a_friend_of=http://www.example.com/user/#me
> I'm making this up of course and it would need a bit more thinking, but
> the idea would be to shift the task of negotiating which certificate to
> send from the TLS layer to the HTTP layer, thereby giving more
> flexibility (and the ability not to be "rude" to the client by closing
> the connection abruptly if there's something wrong with the certificate
> it send).
> This would also allow for multiple challenges on the same service (as
> it's already possible), e.g. Digest+Transport,
> Basic+Negotiate+Transport, although some of this is partly already
> possible since client-certificate authentication is already orthogonal
> to the others.
> This doesn't require so much work on the server side, perhaps just
> enough to be able to trigger the renegotiation (not actually that easy,
> depending on the type container and the API exposed).
> It's on the client side that this requires more work: the user-agent
> would need to support this, but I think the general certificate
> selection UI would improve if we had that in place.
> On the one hand, I think that's a long term goal. On the other hand, as
> far as I aware, servers could already send this sort of headers, since
> browsers don't seem to complain too much when they don't understand the
> challenge scheme in the WWW-Authenticate header (or when that header is
> simply missing).
>>> Well, HTTP has always treated 'authentication' and 'authorization' quite
>>> ambiguously. In most cases, 'unauthorized' actually means
>>> 'unauthenticated and therefore unauthorized'.
>>> The problem with 401 is in the 'MUST'
>>> <http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2>:
>>>     "The response MUST include a WWW-Authenticate header field (section
>>> 14.47) containing a challenge applicable to the requested resource."
>> Indeed on both counts. For responsible use of 401 in mod_authn_webid,
>> I must reinterpret this text, like I do other old commandments, from
>> within my own post-modern context:
>> "The response MUST include a [HTTP-standards-based] field containing a
>> challenge applicable to the requested resource."
>> Of course for WebID, the "challenge" is the SSL client certificate request.
>> In general, 401 is for not authenticated and 403 is for not authorized
>> (or both).  AFAIK, this spec should be dealing primary with
>> authentication =>  401 unless we want to come up with some higher 40x's
>> to supersede my current 'specify the specific authentication error in
>> the response body' plan.
> The downside of 403, especially once your browser has chosen a
> certificate, is that you can't re-challenge and change the certificate
> easily (or know why it doesn't like the certificate). These problems are
> of course linked to the browsers' certificate selection UI.
> Typically, since I tend to have at least a CA-signed cert and a WebID
> cert in my browser and because we use an empty list of
> certificate_authorities to enable self-signed WebID certs, if the
> browser picks the CA-signed cert to send as a WebID cert (and since it
> doesn't have any URI in the subject alt. name), this could cause 403s
> (this doesn't really happen in the situation where the server expects a
> CA-signed cert, since the browser doesn't suggest the self-signed WebID
> cert in this case).
> I think you've got the right approach by using 401 and an explicit
> message in the response body, considering there's no standard
> WWW-Authenticate scheme to do this, but since browsers don't necessarily
> understand what's going on, they don't necessarily re-offer to send
> another certificate instead.
> Best wishes,
> Bruno.
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

More information about the foaf-protocols mailing list