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

Henry Story henry.story at gmail.com
Sat Aug 14 22:37:10 CEST 2010


Perhaps these points should be added to the wiki, or put together on a page and then presented to the HTTP and TLS working groups at some point.

Henry


On 14 Aug 2010, at 22:30, Joe Presbrey wrote:

> 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
>> 
> _______________________________________________
> 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