Subject: key flags -- what do they mean?

From: Adam Back <[email-masked]>
Date: Mon, 8 Mar 1999 00:05:51 GMT

Ian Brown commented recently on the key flag section of the draft.
This got us wondering about how close the key flag was to an X.509 key
usage flag.

5.2.3.20. Key Flags

   (Octet string)

   This subpacket contains a list of binary flags that hold information
   about a key. It is a string of octets, and an implementation MUST NOT
   assume a fixed size. This is so it can grow over time. If a list is
   shorter than an implementation expects, the unstated flags are
   considered to be zero. The defined flags are:

       First octet:

       0x01 - This key may be used to certify other keys.

       0x02 - This key may be used to sign data.

       0x04 - This key may be used to encrypt communications.

       0x08 - This key may be used to encrypt storage.

[...]

So the question is does this mean that it is possible to say that a
key may not be used for certification?  ie if one has a certificate
from a third party, or from a CA which gives key flag 0x2 and 0x4 only
would this mean that PGP 5.x or 6.x, or other OpenPGP complaint
implementations software might consider that the key is only allowed
to sign and encrypt data and refuse to use it to certify, or that
receiving implementations might consider a certification invalid when
given by a key so marked?

Enciphering minds want your consider opinions and interpretations.

Being technically unable to mark keys as 'not for certification' is a
big win in the government key escrow argument.  Eg. the current Uk
government drive is to legislate that ISPs must (I quote):

> Annex A III: "An applicant will need to demonstrate that the
> certificates it issues have all the following information... an
> unambiguous statement that the certificate must not be used to validate
> a key being used to secure the confidentiality of information"

ie that concept that a CA can restrict your ability to use a signature
key for certification.  Unfortunately this wedge works rather well
against S/MIME the way most vendors implement it.  The clients can't
even certify *anything*, plus the keyUsage flag allows the not for CA
use to be specified, and many of the clients honor this flag.

The other text in RFC2440 below this says:

   Usage notes:

   The flags in this packet may appear in self-signatures or in
   certification signatures. They mean different things depending on who
   is making the statement -- for example, a certification signature
   that has the "sign data" flag is stating that the certification is
   for that use. On the other hand, the "communications encryption" flag
   in a self-signature is stating a preference that a given key be used
   for communications. Note however, that it is a thorny issue to
   determine what is "communications" and what is "storage." This
   decision is left wholly up to the implementation; the authors of this
   document do not claim any special wisdom on the issue, and realize
   that accepted opinion may change.

Adam

---

From: Jon Callas <[email-masked]>
Date: Mon, 08 Mar 1999 16:44:20 -0800

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 <[email-masked]> [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                                  [email-masked]
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)

---

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 08 Mar 1999 22:51:45 -0600

In <[email-masked]>, on 03/08/99 
   at 07:44 PM, Jon Callas <[email-masked]> said:

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

Perhaps I am a little slow here but this does not make sense. My
understanding on an Identity CA like Verisign is to verify and certify the
identity of a keyholder not what he is going to do with the key. If
Verisign signs my key certifying that the holder of public key 0xFFFFFFFF
is William H. Geiger III what difference does it make what I am doing with
that key?? If Verisign want's to sign keys signifying more than that then
they should have a separate signing key to do so (one key to certify
identity, a separate key to certify someone as a CA).

It seems that there is an attempt to push PGP down the same ugly path that
X.509 has gone down. Using the key as a payload for dynamic data opens up
a whole list of problems that PGP does not need to be saddled with.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii
- ---------------------------------------------------------------
 
Tag-O-Matic: Don't be held back by yesterday's DOS!  Try today's OS/2!