W3C home > Mailing lists > Public > public-xg-webid@w3.org > April 2011

RE: Binary WebID Profiles

From: peter williams <home_pw@msn.com>
Date: Tue, 12 Apr 2011 11:14:00 -0700
Message-ID: <SNT143-ds144D4EDA84FAC3A0F5AA2492AB0@phx.gbl>
To: "'Henry Story'" <henry.story@bblfish.net>, "'WebID XG'" <public-xg-webid@w3.org>
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).

 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

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. Ive done that already for our client cert with
one URI in a SAN field, courtesy of uriburner. 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.

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

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
Received on Tuesday, 12 April 2011 18:14:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:44 UTC