W3C home > Mailing lists > Public > www-archive@w3.org > March 2004

Re: X.509 and PGP

From: Chris Bizer <chris@bizer.de>
Date: Thu, 18 Mar 2004 10:43:57 +0100
Message-ID: <002501c40ccd$8c5cd6a0$1f12fea9@named4gc1asnuj>
To: "Patrick Stickler" <patrick.stickler@nokia.com>, "ext Jeremy Carroll" <jjc@hpl.hp.com>
Cc: <phayes@ihmc.us>, <www-archive@w3.org>, <jjc@hplb.hpl.hp.com>

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

Absolutely. I think it should be general practice that the URI identifing an
authority refers to a graph with a self description of the authority (name,
address, affiliation, roles in different application domains, certificates
.... using the vocabularies of choice). Another solution would be using
rdf:seeAlso in a graph to link to this self description.



G2 (G1 swp:assertedBy ex:chris.

       ex:chris rdf:seeAlso <http:www.bizer.de/selfdescription.trix>)



The interesting point about self descriptions is that they can contain
information which can be used for role-based trust policies like "Prefer
product descriptions published by the manufacturer to descriptions published
by a vendor" or "Distrust everything a vendor says about its competitor."



I think we should derive our vocabulary for expression signatures and
certificates from the W3C "XML Encryption Syntax and Processing" and
"XML-Signature Syntax and Processing" specifications
http://www.w3c.org/Signature/  and the W3C key management work
http://www.w3c.org/2001/XKMS/, rather than inventing our own vocabulary. A
guy called Garret Wilson started this, but didn't get too far. See:

http://lists.w3.org/Archives/Public/www-rdf-interest/2003Dec/att-0140/crypto
-draft-20031224.html



If we want to go this way, I could derive the necessary vocabulary from the
specs next week.


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

No. I think a link to the CA is encoded in the X509 certificate. Thus it is
enough that an authority signing a graph has a certificate property in its
self description. An agent who wants to verify the signature can decode the
certification chain from the certificates. Or we should have a look how
certification chains are handled in the "XML Key Management Specification"
and use their vocabulary.


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

Yes. It is there and it is working, so we should just refer to it.

If we need vocabulary for our examples, we should used stuff derived from
XML Signature ... using an appropriate namespace external to swp: (we are
ending up with lots of namespaces :-)



Chris


>
> > 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 05:43:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:32:25 UTC