[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Draft Charter
At 2:47 PM -0700 8/13/07, Jon Callas wrote:
...
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.
I believe the term "certificate" was coined in an MIT bachelor's
thesis by Kornfelder in 1978. (Ron Rivest was the thesis advisor.).
The original D-H paper in 1976 had no concept of a cert; instead it
talked about making public keys available in a phone book like manner.
However, it isn't accurate. A certificate contains a key, but a
certificate is not a key.
right.
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.)
this recursive definition of a cert may be a good example of why it
may be hard to develop a protocol that uses a consistent set of
terminology and embraces both OPGP and X.509/PKIX.
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.
on this list you probably should assume the need to be precise :-).
...
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!
There are a lot of reasons why it is preferable to not reuse a public
key in multiple certs. The semantics of X.509 deal with cert
revocation because a CA's job is to vouch for the binding of the
attributes in a cert and the public key in that cert. Revocaton of
the cert breaks the binding, which is both necessary and sufficient
for the semantic model. There is not need to add an ability to
revoke keys, because a CA does not attest to the security of the key
in any larger sense.
(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.)
I'd try to avoid that last phrase as it may strike some as both
presumptuous and, at least in my case, usually wrong :-).
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.
a clear definition for a key ring would not require any mention of
the type of database by which the set of certs is maintained, so,
hopefully, there is a better reason that the term is not defined in
any documents, right?
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.
This is a very odd characterization. Despite the blatant overuse of
the term, especially in marketing literature and poorly written
papers, both the syntax and semantics of X.509 can be described w/o
reference to the word "trust." (Even the term "trust anchor" need not
be defined using the word trust, as the candidate definitions bandied
about on this list have shown.)
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.
Is this another set of things that OPGP does but which is not
documented in any IETF publication?
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.?
Syntax is not the hard part here.
For example, when one defines the language needed to characterize the
constraints ompised on TAAs, and the constraints expressible via a TA
data structure, one probably has to be cognizant of the semantics of
the certs being managed, else there will be no way to ensure that the
language has enough richness to meet the requirements of the target
user community (whoever we decide that to be). For example, in the
X.509 context, it seems likely that we need the ability to express
name constraints, maybe policy constraints, certainly RFC 3779
constraints, etc.
Also, what is SAML doing in your list? It is not a PKI mechanism,
not a public key format, ...
Steve