Re: Binary WebID Profiles

On 4/12/11 2:14 PM, peter williams wrote:
> The mime type is the existing IETF mime type for cert files, not that there
> is any real need for it in a HTTP request presenting the blob to a custom
> endpoint. If one is formal, then yes, the input request body type is the
> MIME type application/x-x509-ca-cert (or user-cert).

Have to be formal for sake of longevity, comprehension, adoption, and 
defensibility.

>   Look at any modern, well issued cert for an EE, and note that it points to
> its parent cert using an URI, of form https://foo.com/foo.crt. That .crt
> file is of resource type application/x-x509-ca-cert (If I remember right,
> from years ago). In windows, if a client present a EE cert with that URI,
> the server will go collect the foo.crt file so as to form a linked chain up
> to a local root (very trivial linked data space discovery, no!) If foo.crt
> has a further back pointer, that resource file can be collected too.... etc.
>
>
> If you want multiple certs in a file, don't use PEM.  (it's a mess.) Use the
> PKCS7 mime type, properly design for ordering and relating cert in a linked
> graph.
> But, I don't recommend we go there. We want foaf to take charge of
> linking certs/pubkeys together. Otherwise, this project becomes a minor
> webservice wrapper, around existing PKIX standards for chain
> discovery/validation.
>
> So, let's NOT reinvent what IETF already did - remote services for chain
> checking, etc. Let's not even re-invent OCSP (a service for single cert
> status data recovery).
>
> If one wants to mandate that only binary DER of the cert is sent to the
> webservice instead of the (PEM variable) ascii armoring, I don't mind... I
> was trying to be webby, by posting around that which exists. SSL delivers
> the binary, though what various platforms to do that in ascii armoring when
> delivered through CGI APIs is a different matter!
>
> All I want to do is remote the sparql queries, to someone does the
> sparql/querying work for me.

Which the service we'll produce will do.

>   Ive done that already for our client cert with
> one URI in a SAN field, courtesy of uriburner.

And URIBurner will just expose a service URL for those that prefer a 
more canned service over their own SPARQL etc..

>   Now with the change of
> spec/workflow concerning multiple URIs (work I found excellent, since its
> focused on hard semantics), I realize my (remoted) query doesn't fit the
> bill, under the revised validation rules. This compels me to even MORE
> strongly call for offloading the (yet more complex) query(s). I want even
> less to have this done in my enforcement logic. I want it in its own
> strongly typed, well evaluated black box, executed by a trusted process.

I'm not bothered either way, so no comment :-)


Kingsley
>
>
>
>
>
>
> -----Original Message-----
> From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
> On Behalf Of Henry Story
> Sent: Tuesday, April 12, 2011 10:22 AM
> To: WebID XG
> Subject: Binary WebID Profiles
>
>> On 4/12/11 1:00 PM, peter williams wrote:
>>> Yes, it's time for a restful web service (supported by https client
>>> authn and SSL session management) that takes a base64 encode cert as
>>> input, and returns YES/NO
>> Yes.
> How do you make multiple PEM's in that file possible (so someone can have
> multiple files) What is the mime type one should use?
> How does one link to another file? (after all it's the hyperdata we are
> after)
>
> Those are not questions meant to put a stop to this exploration. Just it
> would be good to come up with some ideas there.
>
> Perhaps you can write a small proposal on how to do this.
>
>>> The input parser should assume the worst: strange CRLF or LR or CR,
> random header text, variable number of dashes, missing final EOL, UTF header
> bytes, web friendly char sets or ascii - so as to deal with the realty of
> "PEM encoding"
>> Yes.
>>
>>> Another variant would take a cert sha1 fingerprint, rather than the cert.
>> Yes.
> Again what format?
>
>> Scheduled :-)
>
>
> Social Web Architect
> http://bblfish.net/
>
>
>
>
>


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Tuesday, 12 April 2011 18:25:32 UTC