Re: X.509 and PGP

On Mar 17, 2004, at 23:15, ext Jeremy Carroll wrote:

>
> 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).

Yes. This is exactly in line with what I was thinking.

>
> 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).

I much prefer the swp:certificate property rather than forcing
the URI denoting the authority to resolve to the certificate.

>
> 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

I think it's useful to leave the domain unspecified so that the
same property can be used to qualify e.g. rdf:Statement's
(one could infer that if some authority asserts a graph, it also
asserts each statement in the graph, etc.)

But if you strongly feel the domain should be explicitly defined
as an rdfg:Graph, I'm OK with that.

> range swp:Authority
> with informal semantics that subj is a graph is asserted (in the sense 
> of RDF
> MT) by the obj.

We may want to posit some superclass of both rdfg:Graph and 
rdf:Statement
which fits the MT specifically but leaves a little bit of flexibility
as to whether we're talking about a set of statements or just one (or
some other similar thing).

>
> 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)

OK.

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

Would we not rather be able to infer

   ?graph swp:signedBy ?authority .

from

   ?graph swp:authority ?authority .
   ?authority rdf:type swp:PGPCertifiedAuthority .

???

I.e., if someone is a PGP CA they they are always the CA
for graphs which they verify/sign.

This allows us to avoid the extra property. If the graph is
signed with an X509 signature, then you have to specify the
CA explicitly, otherwise it's the same as the value of
either swp:authority or swp:assertedBy.

Yes?

>
> ====
>
> 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,

I think at this time that we should explicitly punt, because the 
signature
machinery is disjunct from the functional significance of the signature
in the trust model -- i.e. it's out of scope for what we are focusing on
(or what I *think* we are focusing on ;-)

> 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?]

I'd prefer to use subclasses of swp:Signature which are instances of
rdfs:Datatype to model the different types of signatures.

Thus, actual values of swp:signature would be typed literals.

>
> 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.

I think it's reasonable to limit each graph to a single 
authority/signature,
but it's OK if a given authority has many certificates, all that 
matters is that
at least one of those certificates successfully authenticates the 
authority,
such that the signature (and graph) can be verified.


Patrick


>
> 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
>
>
>
>
>
>

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Thursday, 18 March 2004 02:56:54 UTC