Re: Binary WebID Profiles

On 12 Apr 2011, at 22:22, Kingsley Idehen wrote:

> On 4/12/11 3:20 PM, Henry Story wrote:
>> 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?
> 
> Peter can write the spec. We'll deliver an implementation.
> 
>> 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 have an instance that produces WebIDs and supports more than 10K users, so we can easily test this against our live system etc..
>> We need real drivers otherwise we can invent something that will then require completely
>> reworking as soon as someone with many users implements this.
> 
> What we need is a usage pattern that delivers a WebID vector. This is what both Peter and I seek, fundamentally. We are aware of a massive corporate realm that interacts with the InterWeb from the inside out -- not just Intranets behind firewalls, but native OS applications that read and write data to and from Addresses. The browser doesn't define the InterWeb experience solely, and it's a tricky route to a WebID vector for a variety of reasons already covered in many prior conversations re. browsers and their SSL/TLS interaction inadequacies.

Completely agree Kinglsey. I'd just like to see other people put their hands up, and vote 
and agree to discuss the implementations, the language of the text and so on. I'd be happy to
implement this if we have some text.

But who else?

> 
> An iTunes angle is required to aid bootstrap, no different to Twitter bootstrap via native apps (even though Twitter thinks it all happened via Web pages).
> 
> Kingsley
>> 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.
>> +1
>> 
>> Where is the definition of x-x509-ca-cert? Which RFC does it relate to?
>> 
>> Looking around for that I found the following:
>> 
>>  http://karmak.org/archive/2004/04/ssl_ca.html
>> 
>> 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
>> Certificate:
>>     Data:
>>         Version: 3 (0x2)
>>         Serial Number:
>>             2f:df:bc:f6:ae:91:52:6d:0f:9a:a3:df:40:34:3e:9a
>>         Signature Algorithm: sha1WithRSAEncryption
>>         Issuer: C=ZA, O=Thawte Consulting (Pty) Ltd., CN=Thawte SGC CA
>>         Validity
>>             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)
>>                 Modulus:
>>                     00:e8:f9:86:0f:90:fa:86:d7:df:bd:72:26:b6:d7:
>>                     44:02:83:78:73:d9:02:28:ef:88:45:39:fb:10:e8:
>>                     7c:ae:a9:38:d5:75:c6:38:eb:0a:15:07:9b:83:e8:
>>                     cd:82:d5:e3:f7:15:68:45:a1:0b:19:85:bc:e2:ef:
>>                     84:e7:dd:f2:d7:b8:98:c2:a1:bb:b5:c1:51:df:d4:
>>                     83:02:a7:3d:06:42:5b:e1:22:c3:de:6b:85:5f:1c:
>>                     d6:da:4e:8b:d3:9b:ee:b9:67:22:2a:1d:11:ef:79:
>>                     a4:b3:37:8a:f4:fe:18:fd:bc:f9:46:23:50:97:f3:
>>                     ac:fc:24:46:2b:5c:3b:b7:45
>>                 Exponent: 65537 (0x10001)
>>         X509v3 extensions:
>>             X509v3 Basic Constraints: critical
>>                 CA:FALSE
>>             X509v3 CRL Distribution Points:
>> 
>>                 Full Name:
>>                   URI:http://crl.thawte.com/ThawteSGCCA.crl
>> 
>>             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
>>         9f:43:cf:5b:c4:50:29:b1:bf:e2:b0:9a:ff:6a:21:1d:2d:12:
>>         c3:2c:4e:5a:f9:12:e2:ce:b9:82:52:2d:e7:1d:7e:1a:76:96:
>>         90:79:d1:24:52:38:79:bb:63:8d:80:97:7c:23:20:0f:91:4d:
>>         16:b9:ea:ee:f4:6d:89:ca:c6:bd:cc:24:68:d6:43:5b:ce:2a:
>>         58:bf:3c:18:e0:e0:3c:62:cf:96:02:2d:28:47:50:34:e1:27:
>>         ba:cf:99:d1:50:ff:29:25:c0:36:36:15:33:52:70:be:31:8f:
>>         9f:e8:7f:e7:11:0c:8d:bf:84:a0:42:1a:80:89:b0:31:58:41:
>>         07:5f
>> 
>> 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
>> 
>> BINARY STUFF
>> 
>> 
>> 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
>> 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
http://bblfish.net/

Received on Tuesday, 12 April 2011 20:31:15 UTC