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

Re: Binary WebID Profiles

From: Henry Story <henry.story@bblfish.net>
Date: Tue, 12 Apr 2011 21:20:24 +0200
Cc: peter williams <home_pw@msn.com>, 'WebID XG' <public-xg-webid@w3.org>
Message-Id: <D7727E7B-322F-4311-9DB2-812E242DAE93@bblfish.net>
To: Kingsley Idehen <kidehen@openlinksw.com>
Btw. Who is interested in pursuing this apart from OpenLink who said they were? I mean
with real code, real implementations and real spec material? There are a lot of issues
to work on here, (though not that many). Especially interesting would be a site with more than
1 thousand users that could use this for real. 

We need real drivers otherwise we can invent something that will then require completely 
reworking as soon as someone with many users implements this.

On 12 Apr 2011, at 20:25, Kingsley Idehen wrote:

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


Where is the definition of x-x509-ca-cert? Which RFC does it relate to?

Looking around for that I found the following:


in the section "Installing CA certificate in browsers"

"The CA certificate will need to be installed in browsers which will access servers using server certificates signed by the Certificate Authority. Installing a CA certificate in a browser is somewhat dangerous unless you trust that certificate and the security of the Certificate Authority. Once installed, the browser accepts any certificate signed by that authority."

This is an issue we have not looked at yet: is it easy to public CA certificates and have people mistakenly add them to their browser in one click?

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

Interesting. I found one like this:

$ openssl s_client -showcerts -connect google.com:443

Then I copied the first pem to a file and used open file.pem in OSX (double click it)

That had a section "Certificate Authority Information Access ( 1 3 6 1 5 5 7 1 1 )"
With CA Issuers ( 1 3 6 1 5 5 7 48 2 )

# openssl x509 -in cert.pem -inform pem -text
        Version: 3 (0x2)
        Serial Number:
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=ZA, O=Thawte Consulting (Pty) Ltd., CN=Thawte SGC CA
            Not Before: Dec 18 00:00:00 2009 GMT
            Not After : Dec 18 23:59:59 2011 GMT
        Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=www.google.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
            X509v3 CRL Distribution Points: 

                Full Name:

            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication, Netscape Server Gated Crypto
            Authority Information Access: 
                OCSP - URI:http://ocsp.thawte.com
                CA Issuers - URI:http://www.thawte.com/repository/Thawte_SGC_CA.crt

    Signature Algorithm: sha1WithRSAEncryption

And indeed 

$ curl -I http://www.thawte.com/repository/Thawte_SGC_CA.crt
HTTP/1.1 200 OK
Date: Tue, 12 Apr 2011 19:07:31 GMT
Server: Apache
Set-Cookie: v1st=C172E27B49896468; path=/; expires=Wed, 19 Feb 2020 14:28:00 GMT; domain=.thawte.com
Last-Modified: Wed, 19 Jan 2011 20:38:35 GMT
ETag: "2e387c4-327-49a39004248c0"
Accept-Ranges: bytes
Content-Length: 807
Content-Type: application/x-x509-ca-cert


Is binary stuff really something that is going to make people feel comfortable on the web?
PEM sounds better.... 

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

Ah you want the easy life :-)

All I want is a spec and people who want to implement this, and especially if people have
a lot of users. Then we are really speaking.

Otherwise why bother? We have Openlink Virtuosos, but we need a few more organisations right?? A single implementation does not a standard make. Is there anybody else on the list who is interested?

> 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

Social Web Architect
Received on Tuesday, 12 April 2011 19:21:00 UTC

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