On Aug 10, 2007, at 12:46 PM, Stephen Farrell wrote:
Santosh Chokhani wrote:
What is X.509 specific?
The term certificate or certification path or both.
Yes. For me anyway, particularly the latter term.
> Will PGP and others
not have a chain of keys/certificates?
Who knows? (Can't recall off the top of my head what the
PGP things are called - not keyrings was it?)
They're called "certificates." The process where by one certificate
certifies another one is something we call "certification."
I know that sounds flippant, but it isn't. More below. I wasn't going
to send this note at all until we got into discussions of what format
certificates TAM ought to address.
Are not these concepts generic and is this not time to separate
concepts
from X.509 format?
That would be a worthwhile activity. But not one that it'd be wise
to build in as a precondition on this proposed activity. So I'd rather
see a definition use more neutral terms.
An historical note first. The term "key" for "certificate" in the way
that it is colloquially used in OpenPGP was coined by Whit Diffie.
People like it. It's short, friendly, and has a nice provenance.
However, it isn't accurate. A certificate contains a key, but a
certificate is not a key.
Worse, an OpenPGP certificate typically contains at least two public
keys, along with a number of certifications. (It is possible to have
a one-key OpenPGP certificate, but that can only be used for signing.
If you want to encrypt something, you need a signing key and an
encryption key in your certificate. Right now, we're moving to a use
model that has at least three keys -- where the top level signing key
is merely a certification key, and there's an encryption and signing
subkey. This is particularly popular in Europe.)
What this means is that if you say "OpenPGP Key" and want to talk
about its components, you're using the word "key" far too many times.
I have tried to apply rigor to the terminology, but people like using
the word "key" for "certificate" and refused to play along. So I
merely get precise when I need to.
X.509 has a much more atomic model of certificates, but you can
create the same structures of an OpenPGP certificate with a handful
of X.509 certificates. Likewise, you can take a "certificate set" or
"certificate family" of X.509 certificates and create an OpenPGP
certificate out of them.
(Note that I'm simplifying here. I don't have time to write, nor you
to read the constraints and further explanations I want to write.)
There is a *syntactic* isomorphism between OpenPGP and X.509. The
differences are in the semantics, but you can express those semantics
with either syntax. I sometimes think of this in a graph-theoretic
way, and in that mode of thought, the primary X.509 object is a node
+edge pair, from which you then make up graphs, and the OpenPGP
object is a small graph, which contains nodes and edges. Another
metaphor is that X.509 starts with quarks and builds up atoms, while
OpenPGP starts with atoms that contain quarks. I like this one
because in physics, atoms are not atomic, and they are not atomic for
historical reasons.
Now where the OpenPGP and X.509 (particularly PKIX) models diverge is
an attitude about issuers and roots. In OpenPGP, every user is a
potential CA. Every certificate is a potential root. This makes for
some semantic differences, as well as attitude differences.
Every so often, a PKIX/X.509 discussion comes up about using the same
public key in more than one certificate. One thing that always comes
out of that discussion is noting that if you did it, you'd need a way
to revoke a public key as well as a certificate, and no such thing
exists. Well, OpenPGP effectively does this by having both a
signature revocation and a "key" revocation mechanism. Note that in
*this* case, the OpenPGP colloquialism of "key" actually means a key!
(If Alice and Bob each certify my "key," that corresponds to my
having three X.509 certificates, each with the same public key. My
"key" is three certs, one issued by Alice, one issued by Bob, and one
that is self-signed. If I revoke my self-signed certificate, that
implies revoking the other two. Yes, I know all the things you're
thinking now.)
So let me get to keyrings, and then back to TAM. There's no such
thing as a keyring. More precisely, it is not well-defined. That file
you have for PGP or GnuPG is a sequential file of OpenPGP
certificates, nothing more. However, a "keyring" could also be an SQL
database containing same. So if you permit me to contradict myself, a
"keyring" is nothing more than a certificate database with a warm,
fuzzy, Diffie-coined word for it, and is often implemented as a flat
file.
OpenPGP makes a show of explicitly not defining how to express trust.
This is because when the OpenPGP working group was formed, we were
told we couldn't be a PKI, and that meant we couldn't standardize
trust. So while there is a "trust packet" in OpenPGP, it's officially
implementation-dependent. As it turns out by some happy coincidence,
we all base our trust structures on what went before, and we can
(usually) directly import these from one implementation to another.
And this is why TAM would be useful to OpenPGP, and why you'll find
slightly tepid comments from some people. Historically, we've solved
these problems among ourselves, and typically it all works just fine.
In other words, TAM gives X.509 ways to do things that OpenPGP has
done for a long time.
However, I know there are rough edges, and TAM would be a fine way to
iron them out. For my company, PGP Corporation, we work in PKIs that
are imaged into X.509 syntax and OpenPGP syntax. We need to maintain
parallel structures, and TAM is a fine way to do it.
If TAM becomes PKIX-only, then I'm going to have to make a TAM
extension to handle certs in different formats. I can think now of a
way to do it:
I go look at whatever TAM decides, and go directly to where the ASN.1
says "certificate goes here." And then I just put there instead of
the certificate a type-constant (an OID?) and then the certificate.
Then poof, Alice is your auntie, and we're all done.
Is it *that* hard to make this part of TAM, and have type constants
for PKIX, X.509, SPKI, DNSsec, SAML, XML-whatever, DKIM, etc.?
Jon
--
Jon Callas
CTO, CSO
PGP Corporation Tel: +1 (650) 319-9016
3460 West Bayshore Fax: +1 (650) 319-9001
Palo Alto, CA 94303 PGP: ed15 5bdf cd41 adfc 00f3
USA 28b6 52bf 5a46 bc98 e63d
