ietf-openpgp
[Top] [All Lists]

Re: key flags -- what do they mean?

1999-03-08 17:50:02
The key flags are there for a variety of purposes. The two broadest
categories, though, are in self-signatures, and in key certification
signatures.

In self-signatures, they are a statement of what the user wants them to be
used for. For example, there are many people who are old-time PGP users who
have a username that says something like "Joe Blow <joe(_at_)blow(_dot_)com> 
[Document
Signing Key]". Informally, I know (because I'm an intelligent person) that
if I see a certification signature made with that key, I should ignore it.
In effect, Joe is asking the world never to set that key as an introducer.
Secondarily, Joe is asking the world not to encrypt to that key. Note that
there are also the deprecated key types for sign-only RSA and encrypt-only
RSA. These were done by ViaCrypt, for the obvious reasons. However, it's
silly to have three numbers reserved for every general-purpose algorithm we
come up with. It's bad enough that we have two for Elgamal. The proper way
to scope-limit a key is to use flags like this. This is their primary
purpose, for the owner of the certificate to scope-limit any of the keys in
the key bundle.

The other category is that of signing someone else's key -- making a
certification signature. It has been said of PGP (and I'm on of the people
who has said it), that PGP democratizes the CA; anyone can be a CA. In the
mathematical sense of what a CA is, any certification issuer is a CA. In
the legal sense, there's more to it, and I'm not going to go there, quite
yet. Remember that OpenPGP is a format specification, not a law.
Nonetheless, CAs need something that they call in the X.509 world "basic
constraints." These are ways that the CA can describe its certification.
Lutz, for example, needs these for his CA business (and he was the main
advocate of them). The most important one of those flags for a CA is the
certification flag. This is how that CA states that the certification is a
"leaf certificate" and not a sub-CA that can further certify people. Here's
an aside -- the "trust signature" is also a way to designate a sub-CA, and
this is the mechanism that NAI's PGP products use for their
"meta-introducers." Nonetheless, Lutz and other people building PGP CAs
felt very strongly about needing this mechanism for basic constraints.

There is a question, though, about what these third-party statements mean.
I believe that for encrypting and signing, they are nothing more than a way
that the certifier can state whether they want their signature added into a
validity calculation. 

An example is in order. Suppose that I have signed Joe Blow's key with key
flags for encryption, but not signing. You have me as a fully trusted
introducer. If you're going to encrypt a message to Joe, you consider his
key valid, because I have signed it. If you are validating a signature that
key has made, you don't consider it valid because your validity calculation
extends from my certification signature, which doesn't include signatures. 

Note that it is perfectly reasonable for different certifiers to have
different opinions about their certifications. It may be *my* policy that I
never certify a key for both encryption and signatures. That's well and
good, but Joe is free to do what he wants. Some other certifier may have a
different policy, and that's their right. It's an issue on which
gentlepersons can disagree. When I sign a key for encryption but not
signing, I am in effect saying, "I make no warranties about the validity of
a signature made with this key." Someone else may choose to make warranties
(including the key owner).

The certification flag is, of course, a little trickier. OpenPGP is
completely silent on trust model. You can use the traditional PGP model, a
PKIX one, or any other trust model. I'll note that this isn't really
straying from the original PGP philosophy. The PGP philosophy is that
trust, validity, and all of that other stuff is in the eye of the beholder.
It comes from below, from the actual users, rather than being imposed from
above. The no-mandated-model decision merely took that agnosticism one
level higher.

That being said, all of these usage flags are negative-sense. I mean by
that that they only say something if they are off. If they are on, then
it's equivalent to the flags not being there at all. So, if a certifier
turns off that flag, they are saying, "Don't use my certification in any
further validity calculations." And that is all they are saying. Ideally,
that if you set Joe Blow's trust up to fully trusted, and the only validity
path for his key is my certification, nothing further will happen. No keys
in your world will now become valid because Joe signed them. The reason is
that my signature is the only one that makes that key valid. If there are
other paths that make that key valid (like your own signature), that's
different. My signature simply contains in it a limitation of scope.

Another way to think of this is that it is a statement that limits the
certifier's liability. If I certify Joe Blow's key for encryption, and he
uses it for signatures, my hands are clean. That's all it means.


The question that Adam and Ian were bringing up was whether this enables a
repressive government policy -- one in which certifying an encryption key
obligates the certifier to hold a copy of it. There are a number of reasons
why OpenPGP does *not* enable this. First, in OpenPGP, the typical use is
that a certifier only certifies the top-level key. The enhanced key
structure (Chapter 11 of 2440) *only* specifies certifications of the
top-level key. If the top-level key is a signing-only key (e.g. DSA), then
the certifier doesn't get to make any meaningful statements about encryption.

But also, let's suppose I ask you to sign my key. Let's also suppose that
it is illegal for you to sign my key as being valid for encryption unless I
give you my secret key. I'm not going to do that, I'm not daft, so just
sign it as being valid for signing, please. I'm sorry your government is
being stupid (but also secretly releived that for once it isn't mine being
stupid). I understand. Just sign it for what you legally can. If you'd
like, I'll sign yours.

Behind this, though, there is another issue, and that is the issue I
mentioned above about the mathematical and legal definitions of a CA.
Mathematically, a CA is the same things as an issuer. All key signers are
CAs. But legally, there are *policies* that CAs follow, and an issuer is
not a CA simply because they do some funny math. If some government makes
it illegal to be an issuer unless the issuer follow some policies (CA
policies), that's a bad situation, but not a protocol issue.

        Jon



-----
Jon Callas                                  jon(_at_)pgp(_dot_)com
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
(408) 346-5860                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)