Re: Certificate Triplify Challenge

On 4 Jan 2012, at 14:10, Mo McRoberts wrote:

> 
> On 4 Jan 2012, at 11:44, Jürgen Jakobitsch wrote:
> 
>> hi,
>> 
>> the topic of using CN from the certificate came up quite often lately.
>> wouldn't it be a good idea to extend the cert ontology [1] somehow to provide
>> official classes and predicates for the contents of a certificate besides the keys.
>> 
>> since a WebIDPrincipal [2] is more or less a graph, i could add these certificate-triples
>> to the WebID and users of the WebIDRealm can display whatever they want to display :
>> foaf:names, cert:issuedTo ?x => ?x cert:commonName...
> 
> As I understand it, the intention is for the cert ontology to eventually be able to express a complete certificate, not just the keys from it — it’s just that the means of doing this hasn’t yet been defined.

yes, that is an interesting topic.

> 
> It would be nice if when it does, the vocabulary for DN attributes joins the dots somehow with the OIDs for those attributes (perhaps via owl:sameAs <oid:x.y.z> ? [3])
> 
> Technically a DN is an ordered list, so there are probably some *minor* headaches involved there.
> 
> Probably the biggest headache is that you can take an cert:RSAPublicKey instance and construct a PKCS#1 RSA key structure from the values it contains, and you'd want to be able to do the same (with original signature intact and still verifiable) with a cert.
> 
> In a pinch, you'd want something like…
> 
> Classes:
> 
> cert:Certificate
> cert:DistinguishedName
> cert:Extension
> 
> Properties on cert:Certificate:
> 
> cert:subject (cert:DistinguishedName)
> cert:issuer (a resource, pointing at a cert:Certificate instance containing at a minimum a cert:subject, but also a cert:key if you want to be able to verify the signature)
> cert:key (as already defined)
> cert:serialNumber (literal, datatype xsd:integer)
> cert:notBefore (literal, datatype xsd:dateTime)
> cert:notAfter (literal, datatype xsd:dateTime)
> cert:issuerUniqueID (literal, datatype xsd:hexBinary)
> cert:subjectUniqueID (literal, datatype xsd:hexBinary)
> cert:signatureAlgorithm (resource, hopefully with some reference to signature algorithm OIDs)
> cert:signature (literal, datatype xsd:hexBinary)
> cert:extension (any instance of cert:Extension)
> cert:extensionValue (any value)
> 
> Then RDN (literal) properties, presumably in a different namespace?, e.g.:
> 
> x520:countryName, x520:localityName, x520:stateOrProvinceName, x520:organizationName, x520:organizationalUnitName, x520:commonName
> 
> e.g (some extra extension stuff thrown in for good measure):


> http://example.com/me#myCert a cert:Certificate ;
> 	cert:subject [
> 		a cert:DistinguishedName ;
> 		x520:countryName "GB" ;
> 		x520:localityName "London" ;
> 		x520:organizationName "British Broadcasting Corporation" ;
> 		x520:organizationalUnitName "Research and Development" ;
> 		x520:commonName "Test Certificate" ;
> 	] ;
> 	cert:issuer <http://example.com/ca#cert> ;
> 	cert:key [
> 		a cert:RSAPublicKey ;
> 		…
> 	] ;
> 	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:subjectAlternativeName ;
> 		cert:extensionValue <http://example.com/me#person> ;
> 	] ;
> 	cert:extension [
> 		a cert:basicConstraints ;
> 		cert:extensionValue [
> 			cert:ca "false"^^xsd:boolean ;
> 			cert:pathLengthConstraint 0 ;
> 		] ;
> 	] ;
> 	cert:signatureAlgorithm cert:sha1WithRSAEncryption ;
> 	cert:signature "00010203040506070809...."^^xsd:hexBinary .


Notice how cert:Certificate is defined as a foaf:Document?
Then you will see that cert:subject is the same as foaf:primaryTopic. Having noticed that you will see that
cert:key relates a foaf:Agent to a key, not a document to a key, so that the way to write this would be then.
One can then wonder if cert:extension for the alternative name  is really needed. All it is making a claim is for owl:sameAs 

I think those mappings are interesting. Worth putting up a wiki page with these ideas too.

<http://example.com/me> 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> .


once you do this mapping you see that foaf and the cert ontology together provide a lot of what is
needed. It is just a matter of separating properties of the certficate/document, and properties of things the
document describes (the user) 

It is then interesting to see what is missing. Notice also that there are issues about what
MUST-Understand extensions mean  at all. In RDF there is no such concept as it is designed to be 
monotonic.

   This is an interesting subject to explore. 

	Henry

> 
> 
> 
>> 
>> [1] http://www.w3.org/ns/auth/cert#
>> [2] http://docs.turnguard.com/webid/2.0/com/turnguard/webid/tomcat/security/WebIDPrincipal.html
> 
> [3] http://tools.ietf.org/id/draft-larmouth-oid-iri-04.txt
> 
>> 
>> --
>> | Jürgen Jakobitsch,
>> | Software Developer
>> | Semantic Web Company GmbH
>> | Mariahilfer Straße 70 / Neubaugasse 1, Top 8
>> | A - 1070 Wien, Austria
>> | Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22
>> 
>> COMPANY INFORMATION
>> | http://www.semantic-web.at/
>> 
>> PERSONAL INFORMATION
>> | web   : http://www.turnguard.com
>> | foaf  : http://www.turnguard.com/turnguard
>> | skype : jakobitsch-punkt
>> 
> 
> 
> -- 
> 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 13:58:39 UTC