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

Akbar Hossain akkiehossain at gmail.com
Fri Aug 13 01:13:04 CEST 2010


I wasn't thinking about smart interactions up and down the stack per
se. Although very interesting indeed.
Joe Presbrey created an apache mod to implement the foaf+ssl authnetication [1].
Perhaps a modification to the mod_ssl would make for more tighter
integration with regards to error raising - maybe not.
The separate layers communicating errors/interacting with each other
up/down the stack in a strucutred manner would be very cool indeed.

The PHP implementations tend to work the way mentioned in terms a
clear separation of the stack and limited error messaging.
A lack of a client certificate maybe as sophisticated as it will get
at the moment.

There maybe value in enumerate the error states within the stack and
trying to encourage verifying agent to send an appropriate HTTP status
code. If only to help the understanding amongst implementors.

A rough list would probably include

TLS connection error
No client certificate supplied
No URI found in the SAN
Unable to dereference a URI in the SAN
Public Key in the Client Certificate doesnt match the RSA Public Key in WebId
Authorised

I am sure there are other obvious errors.

[1] http://lists.foaf-project.org/pipermail/foaf-protocols/2009-April/000539.html

On Thu, Aug 12, 2010 at 11:39 PM, Henry Story <henry.story at gmail.com> wrote:
>
> On 13 Aug 2010, at 00:24, Dave Longley wrote:
>
>> On 08/12/2010 04:05 PM, Akbar Hossain wrote:
>>> Hi,
>>>
>>> Wondering if it makes sense to specify/standardise the possible HTTP
>>> status codes the resource you are trying to access should try to
>>> respond with.
>>>
>>> http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
>>>
>>> Curious how/if TLS errors/failures should be communicated back to the
>>> identifying agent.
>>>
>>> http://tools.ietf.org/html/rfc5246#section-7.2.2
>>>
>>> Maybe of less importance to browser usage but of value when
>>> considering services trying to access resources.
>>>
>>> Thoughts?
>>> _______________________________________________
>>> foaf-protocols mailing list
>>> foaf-protocols at lists.foaf-project.org
>>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>>>
>>
>> As far as I know, dereferencing the Web ID and confirming identity, etc.
>> happens after the TLS handshake, not during. I assume this is the
>> process that would be generating the errors you're talking about.
>>
>> It would require a lot more work and modifications to servers to do it
>> differently. My understanding is that Web ID can be implemented fairly
>> easily on an Apache php server by getting the client-side certificate
>> from a global var (which is populated by setting a configuration option
>> in Apache) and then checking its public key against one that is
>> retrieved from the Web ID url. This is all done post-TLS-handshake. If
>> I'm wrong about this hopefully someone will correct me.
>
> That is indeed the most obvious way to implement it.
>
> Recently Reto tried something different in Clerezza. He put the handshake
> in the TLS session. Here is the Scala code
>
> http://svn.apache.org/repos/asf/incubator/clerezza/trunk/org.apache.clerezza.parent/org.apache.clerezza.platform.security.foafssl/core/src/main/scala/org/apache/clerezza/foafssl/ssl/X509TrustManagerWrapperService.scala
>
> or http://bit.ly/9w1pXp
>
> We are playing with this to see what advantages or disadvantages it brings.
> One advantage is that one could if WebId auth fails, try normal CA auth.
>
> So if people have ideas of things we can explore in this space, let us know...
>
>>
>> That isn't to say that we shouldn't necessarily standardize on error
>> conditions that can be sent back to the identifying agent. I would just
>> expect them to be sent over HTTP, not within the TLS protocol as alerts.
>> There may also be timing attacks and other implications should the Web
>> ID url deferencing+public key checking happen within the TLS handshake
>> -- and we would just want to avoid dealing with that entirely.
>>
>> Again, perhaps an idea worth exploring, but I recommend that it be
>> outside of the TLS protocol.
>>
>> --
>> Dave Longley
>> CTO
>> Digital Bazaar, Inc.
>> Phone: 540-961-4469
>>
>> _______________________________________________
>> 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