X.509 and PGP

Pat:
>Only if we specify that the vocabulary actually talks about real 
>locks and keys, not just things that are called 'lock' and 'key' in 
>the vocabulary (which might be pieces of cheese and small blue pills 
>respectively.) The bare MT doesn't provide any attachment of a 
>vocabulary to real things. We need to add that if we want it done.

etc.

I will try to provide a possible grounding; I don't think it grounds the word 
"asserts" as such, nor do I think this should be an exclusive grounding.
The definition of what assertion means practically is found in RDF MT, if RDF 
is asserted then it has the meaning given. But practically there are two 
parties involved (at least).

Now - in the distrusting world of e-commerce and crypto there seem to be two 
main standards for establishing identity: X.509 and PGP digital certificates 
[1], [2], [3[.
An X.509 certificate is issued by a "Certificate Authority" CA such as 
Verisign Inc to legal persons, identified with globally distinguished names 
[4], and is signed by the CA who have gone to some effort to establish the 
legal identity of that legal person; a PGP certifcate in contrast can be 
created by anyone, and then signed by a number of other people who may act as 
CAs. A PGP certificate might give the identity of a person using a picture! 
The two systems have very different philosophies. In X.509 you have to trust 
a, or perhaps all, central CAs (there are a few); in PGP you trust whoever 
you trust, and you may then trust the certificates they have acted as CA for. 
In X.509 certificates are verified in a binary fashion, in PGP its less clear 
cut. See various discussion in [1].

So, my sense of how to get the grounding Pat is after, and the generality that 
others are after is:

1) define 
swp:Authority informally with a description like:
A person or entity who verifies or affirms some RDF.

2) define subclasses swp:X509CertifiedAuthority
as an authority holding an X.509 certificate
and swp:PGPCertifiedAuthority
as an authority holding a PGP Certificate
(for convenience we might want swp:CertifiedAuthority as a superclass).

we could require that these are identified with a URL which retrieves their 
certifcate or we could have a property:

swp:certificate with domain swp:Authority and range xsd:base64EncodedBinary 
(or whatever it is) with that object being a literal representation of the 
certificate as a piece of binary data. I think we should note that some or 
all of the information in the certificate could be expressed as more RDF 
properties, but that we have omitted that due to space requirements (and/or 
effort).

These classes have formal MT in that:
  resources of these classes represnet the holder of a certificate.
  the holder is identified by the certificate.

3) define property
  swp:assertedBy  domain ? Graph range swp:Authority
with informal semantics that subj is a graph is asserted (in the sense of RDF 
MT) by the obj.

4) define properties
  swp:signedBy domain ? Graph range swp:CertifiedAuthority
and
  swp:signature domain ? Graph range xsd:base64EncodedBinary

With formal semantics linking to X.509 and PGP specs. (but see below about 
signature algorithms etc)

5) define swp:signedAndAssertedBy as a subproperty of (3) and (4)

====

Issues with this are:

A) signature algorithm
There are many ways to sign a graph, not many are deployed.
The only deployed method that I am aware of is the foaf: method that DanBri 
mentioned. This involves a copy of the exact bytes of the original RDF/XML 
file + a signature of that. I have a paper describing a class of algorithms, 
an HP colleague has a technical report describing another class.
We either need to explicitly back one such method, or explicitly punt, and say 
one method needs to be chosen, or provide a property swp:signatueMethod, 
which is perhaps has value xsd:anyURI which when you do a fetch gives a 
description in natural language of the signature method. (Obviously a few 
well-known such methods will evolve). [We can't do that with a URIref node 
can we, we need a literal node in order to actually do a Web-GET as part of 
the property semantics?]

B) cardinalities ....
It may be useful for a single authority to have many certificates, and a 
single graph to be signed many times. However we need each triple: (Graph, 
certificate, signature) to be well-defined. Thus we have to create the 
information model that supports both of these. I do not believe we have that 
yet. One possibility might be that a Graph has one authority and one 
signature, and each authority may have only one certificate. We then use 
rdfg:equivalentGraph and swp:samePersonAs (on authoritys) to allow 
multiplicity.

C) ... it's gone, maybe later.

Jeremy
 



[1] contrast between PGP and X.509
http://www.pgpi.org/doc/pgpintro/#p16

[2] formal ref for PGP certificates, see section 5.5, 
and 5.5.1.1 for terminology
http://www.ietf.org/rfc/rfc2440.txt

[3] X.509 ref
ITU-T Recommendation X.509 version 3 (1997). "Information Technology - Open 
Systems Interconnection - The Directory Authentication Framework"  ISO/IEC 
9594-8:1997.  (I've not looked at this)

[4] Distinguished names
http://www.ietf.org/rfc/rfc2253.txt

Received on Wednesday, 17 March 2004 16:17:45 UTC