W3C home > Mailing lists > Public > public-xg-webid@w3.org > January 2012

RE: Certificate Triplify Challenge

From: Peter Williams <home_pw@msn.com>
Date: Wed, 4 Jan 2012 10:25:17 -0800
Message-ID: <SNT143-W2975C37CD7505A40401F9292970@phx.gbl>
CC: "public-xg-webid@w3.org" <public-xg-webid@w3.org>

Changing the encoding of the cert format on the wire makes no difference. You can spit it out in long RDF strings if you want. ASN.1 doesnt care whether you use DER, BER, PER, or XML. ISO defined the mappings onto XML, and compilers now spit out bytes - in binary XMl or long XML. One can define a spitter for RDF in any of tis encodings, if one wants. Any undergrad can do this (its just 1980s abstract/concrete type theory). But, Henry is right, that this makes NO difference. Its still an ASN.1 cert, with particular set of type theory formalisms, that REALLY DO NOT WORK well with RDF/EAV (which is very pure). The semantics are abstract, and are not tied to the encoding. The esmantics for the cert AS A TYPE (not a blog) are also very much tied to the art of public key distribution on an internet sclae - whose PRACTICAL  security requires a particular way of relying on naming and addressing, and binding, and asserting, and validating, and (all the other things folks discuss here). The cert is just the lynch pin of that doctrine set (which is why folks discuss it endless, often in rant form). its why it gets the "evil' label (becuase it SO good at actualy doing what folks would LIKE to do, when replacing it). yes its getting old, as its tied to internet 1 (which is getting on in age). In my R&D work, I put triple and sparql expression in the cert in the form of test of encoded into URIs), and avoid the whole SAN URI semantic wars. I thus describe identity the webby way from the outset, using the cert now NOT as above (but as a means to end, so https libs work). Its just a signed text stream, then, retaining some legacy key management controls so actual SSL is not compromised, too badly.  Back in 2007, the topics that looked interesting included: http://yorkporc.wordpress.com/2007/09/30/copy-of-httpdarq-sourceforge-net-federated-queries-with-sparql/ http://yorkporc.wordpress.com/2007/09/23/email-post-on-using-deriving-sparql-queries-from-foaf-knows-relations-to-assure-pubkeys/ But, its takes SO LONG to do anthing, in semweb land, that I hardly remember even knowing what I knew then. Kingsley is reminding me, though.            
 > From: henry.story@bblfish.net
> Date: Wed, 4 Jan 2012 19:04:48 +0100
> CC: j.jakobitsch@semantic-web.at; public-xg-webid@w3.org
> To: mo.mcroberts@bbc.co.uk
> Subject: Re: Certificate Triplify Challenge
> On 4 Jan 2012, at 16:05, Mo McRoberts wrote:
> > 
> > On 4 Jan 2012, at 13:50, Henry Story wrote:
> > 
> >> As soon as you put things this way you realise that it is wrong in fact. Because the above fails to make the point that it is the Certificate that is making the agent claims. What is really needed there is to use N3 to express what is going on:
> > 
> > Hmm, are you sure? Is it not that the certificate *carries* the claims made by the issuer?
> A certificate is a document that is signed by an issuer. It is exactly the type of thing that has a semantics. In fact one could even say that a document is defined by its having a semantics. ( Btw. log:semantics is explained in more detail here http://www.w3.org/2000/10/swap/doc/Reach )
> So let say I speak of a certificate <http://example.com/cert> here in this e-mail, then I can say what type of thing it is, when it was made etc... I can make statements about that document. 
> But I can't speak about the contents of that certificate without asserting those contents themselves here. And anything or anyone reading what I am writing here would not know how to distinguish between what I am saying and what the certificate is saying, unless you use graphs or if you wanted to make your life really complicated reification. Ie one needs a quotation mechanism. In N3 you do this with {...}.
> There is one particularly interesting exception I think and that is if the document <http://example.com/cert> were to return also an RDF representation, and this would then be written something like 
> <> a cert:Certificate ;
>    foaf:primaryTopic _:agent ;
>    cert:issuer <http://example.com/ca#cert> ;
>    cert:serialNumber 1 ;
>    cert:notBefore "2012-01-01T14:00:00Z"^^xsd:dateTime ;
>    cert:notAfter "2012-12-31T13:59:59Z"^^xsd:dateTime ;
>    cert:extension [
> 		a cert:basicConstraints ;
> 		cert:extensionValue [
> 			cert:ca "false"^^xsd:boolean ;
> 			cert:pathLengthConstraint 0 ;
> 		] ;
> 	] ;
>     cert:signatureAlgorithm cert:sha1WithRSAEncryption ;
>     cert:signature "00010203040506070809...."^^xsd:hexBinary .
>     _:agent cert:distinguishedName [
> 		a cert:DistinguishedName ;
> 		x520:countryName "GB" ;
> 		x520:localityName "London" ;
> 		x520:organizationName "British Broadcasting Corporation" ;
> 		x520:organizationalUnitName "Research and Development" ;
> 		x520:commonName "Test Certificate" ;	
>        ] ;
>             cert:key [ a cert:RSAPublicKey ;
> 		…
> 	     ] ;
>              owl:sameAs <http://example.com/me#person> .
> ( Well the only problem is that the signature would have to be outside the document, in another document presumably, because signing a document with an internal signature is a complicated trick. One would need a signature algorithm that removes certain triples - the signature tripes - before signing. And this may have many issues I don't know about )
> Here the document is speaking about itself and its contained statements, so it is clear what the signature is about, and also what it is that the certificate in ASN.1 is saying. We have essentially a sketch of an RDF view on the X509 document here.
> > 
> > If the purpose of the ontology is to allow round-tripping (which it must, IMO, so that you can verify the signature on the content — otherwise you might as well just have a lump of arbitrary signed RDF and forget about bothering with X.509's structure), then you have to be careful about how far you diverge from it, and that includes additional statements (which from a processor's perspective are just unsigned additional junk, like a comment header field in a PEM-formatted blob).
> > 
> >> then one realises that the MUST understand stamens are statements about grammar changes: they are saying that you cannot believe anything else about what you see in the document unless you understand one statement: i.e., that statement could possibly change the meaning of the other statements seen up to then. 
> > 
> > Yes… the criticality aspect of extensions falls into this category, although in X.509-land the rules assume that you do know how to process “an extension” in general and where to find the criticality field at a minimum — so with an RDF equivalent you could work on the same basis (i.e., you recognise cert:critical, and if it's set and you don't understand one of the classes associated with the extension, fail).
> > 
> > M.
> > 
> > -- 
> > Mo McRoberts - Technical Lead - The Space,
> > 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
> > Project Office: Room 7083, BBC Television Centre, London W12 7RJ
> > 
> > 
> > 
> > http://www.bbc.co.uk/
> > This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
> > If you have received it in error, please delete it from your system.
> > Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
> > Please note that the BBC monitors e-mails sent or received.
> > Further communication will signify your consent to this.
> > 					
> Social Web Architect
> http://bblfish.net/
Received on Wednesday, 4 January 2012 18:25:47 UTC

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