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:05:19 UTC