[foaf-protocols] .crt again; authority relations

Peter Williams home_pw at msn.com
Mon Mar 14 21:49:31 CET 2011

Folks might want to know that windows server comes with a built in CA that is already pretty URI friendly. If one creates a 2 element cert chain, the first is self-signed (the CA cert) and the second is signed by the first (the EE cert).

For an EE (end-entity) cert with an SAN URI, it comes populated also with 2 alternative-identifiers for the CA cert. One is evil ldap, and the other is http.
(the particular http value leverages a wall-garden DNS, that spoofs foaf.me; so dont expect it to resolve using the internet)
Here is the relevant content of the EE cert:

[1]Authority Info Access
Access Method=Certification Authority Issuer (
Alternative Name:
[2]Authority Info Access
Access Method=On-line Certificate Status Protocol (
Alternative Name:
Now, if looks at the CA cert having decoded the .crt value, it does not identity itself as http://3sjchk1.foaf.me/CertEnroll/3SJCHK1.foaf.me_foaf-3SJCHK1-CA.crt in any namefield. That http URI is not in its SAN URI, that is.
However, in some sense, it's child (the EE cert) does so identify its parent - by reference.
Now, in one sense that URI is just a pointer to a resource, where some or other.crt blob got dumped for public access. There are no webid reference semantics that is.
There are some X.509 semantics however.
When verifying the EE cert, one COULD insist that the CA cert be confirmed to be available at that URI; AND that the SKI of the CA cert == the AKI of the EE cert (so one can confirm that its not just any old .crt blob as that location).
As folks start to build graphs of webids, we may want to exploit this property - if one allows this "EE-centric URI identifier for its parent" to be seen as a webid. In this case, it is a property about the _relationship_ between two webids, not a webid itself. Specifically, its an authority relation. But its one that comes with some crypto properties.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20110314/ad4af0e8/attachment.htm 

More information about the foaf-protocols mailing list