Subject: Re: key flags -- what do they mean?

From: [email-masked]
Date: Mon, 8 Mar 1999 17:52:28 -0800

My concern is that these key flags carry implications which are
inconsistent with other aspects of the spec.

What does a certification mean?  Let us focus on a certification without
any special flags or subpackets.  It is a simple binding, by the signer,
between key and userid.  It is an assertion that "this key belongs to
this person".

Now with the key flags, we have a new element.  The idea is that the
signer can turn on some flags and turn off others, and request that his
certification be ignored if the key is being used for a purpose not in
the listed set of flags.

In effect, the key flags are an attempt to take away some of the meaning
of the certification.  The signer is trying to say, "I certify that
this key belongs to this person, but I want you to pretend that I never
said any such thing if the key is being used for a purpose not on my
approved list."

Why would I, as a third party who sees his certification, ever want to
discard information in this manner?  He's plainly stated that he has
certified the binding of the key to the user.  If I believe that he is
honest and diligent, then this adds to my belief that the key is valid.
Just because the key may be later used in a manner he would frown on,
that doesn't make it invalid.  The binding between userid and key is
valid independently of use.

This is the problem that I have with this use of the key flags.  There is
no logical connection between how the key signer's hopes for how the key
would be used, and the certification of validity which the signer makes.
By trying to make these completely independent and orthogonal concepts
become dependent on each other, the key flags are not consistent with
the other semantics of our key signatures.

Hal

---

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

In <[email-masked]>, on 03/08/99 
   at 08:52 PM, [email-masked] said:

>become dependent on each other, the key flags are not consistent with the
>other semantics of our key signatures.

Well I have been doing quite a bit of studying/thought on the use of PGP
in an e-comm environment and the more I look at it the more I am convinced
that using the public key as a payload for information is the wrong
approach.

While the WOT is a convenient mechanism for individuals to "certify" a key
and a user's identity it is a poor mechanism for a CA (this expands past
just the simple identity CA's we see today). At most a CA should sign a
key signifying that they have some data relating to the key in their data
base. Any additional information should be retrieved *directly* from the
CA using the public key as a "token" linking the owner of the key to the
records in the database. The problem we have here is trying to attach
dynamic data (data that can change at any time) in a static format
(attached to a public key that the signer may or may not be able to change
when the data changes).

Don't feel bad though the underlying format is good, this is just an
implementation problem (we are much better off than the X.509 crowd <g>).

- -- 
- ---------------------------------------------------------------
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: Program call to load Windows- "Here_piggy_piggy_piggy"

---

From: Adam Back <[email-masked]>
Date: Wed, 10 Mar 1999 00:13:32 GMT

Hal writes that certification is about making assertions that "this

> valid independently of use.

It is in security terms I agree, and security is all certification is
about.

All rfc2440 says is "certification is for that use":

   [...] for example, a certification signature that has the "sign data"
   flag is stating that the certification is for that use.

We have 3 flags (two are just variations on encryption):

1) CA
2) sign
3) encrypt

Working through these with CA first:

1) CA

Jon said just now:

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

I understand Jon to be saying that if key A certifies another key B
with the CA flag enabled, this indicates that A is delegating ability
to certify *on A's behalf*.

This sounds useful.  If I want to do something fancy with my keys,
such as:

- delegate trust from a securely stored key to other keys 
  which are used on a day to day basis
- start a time-stamping service, with extra time-stamping key
- operate a CA with multiple keys for different purposes

etc. I can use the CA flag to designate by sub-signature keys.

I think this means that an implementation SHOULD NOT issue CA
certificates for other peoples keys.  Or in other words the CA flag is
for organisation of ones own keys.

So if we examine Bob's key and it has a signature from Alice's key A2
and Alice's key A2 has a CA signature from Alice's key A1, that means
we can categorise the three identities: A2 and A1 are the same person.
B is someone else who A chose to certify the identity of.

This is useful in that if we trust A1, A1 is telling us to trust A2 to
the same level.

Jon also explained how the trust flag can be used to do something
similar:

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

I am unclear here on what the difference is.  Why have two competing
mechanisms to achieve the same thing?  The trust signature seems to be
the more general mechanism, what is the CA flag adding?

2) Sign

As the key flags on certificates were requested by Lutz for CA use, as
Jon wrote:

| Lutz, for example, needs these for his CA business (and he was the
| main advocate of them).

I will try to speculate what use a CA might have for a sign flag.
Perhaps these flags are for more CA-internal key delegation.

eg. Say the CA has a root key used for delegating roles to it's other
keys.  It delegates the role of certifying client's keys with a
signature with the CA flag.  It delegates the role of document signing
to another key with a siganture with the CA and sign flags.

It would seem that the signature flag would be able to certify
encryption sub-keys directly, so the encryption flag applied to
certificates would be redundant under this speculated semantics.

However key flags applied to certificates seem redundant.  Surely the
same function could be achieved with the trusted signature flag, and
self signatures with the relevant flags.  The trust signature flag
allows one to delegate trust, and the self siganture flags allow the
holder of the private key to define usage preferences.  This would be
better, as Thomas Roessler points out that putting key flags in
certificates restricts the key usage to applying to the userid only.

: Quoting from 5.2.3.2:
: 
:    Subpackets that appear in a certification self-signature apply to
:    the username, and subpackets that appear in the subkey
:    self-signature apply to the subkey. Lastly, subpackets on the
:    direct key signature apply to the entire key.
: 
: This means that a CA could only make a statement about key usage for
: a specific user-id.  Such a statement doesn't make too much sense.

If key flags were intended to be used in the certificates the CA hands
out to it's clients, I would really like to hear Lutz or someone
explain what the CA requirement is for this, and what the semantics of
the result is.  What would the certificates mean in the PGP WoT model
where there is nothing but peer to peer certifcation, and where
everyone is a CA.

> the other semantics of our key signatures.

I agree.  The concept of one WoT user telling another WoT user that a
certificate is to be included in trust calculations for signatures
only and not for encryption is strange:

- Firstly only the signature keys are involved in the WoT anyway as
encryption sub-keys have trust delegated to them by the key owner, so
the "not for encryption" is meaningless if taken literally.  

- However, if one included in the semantics of "not for encryption"
that if the flag were applied to a signature key, the trust
transferred by the signature should be discounted if the key is used
to make a self signature, the signature provider has the ability to
mount a minor denial of service attack in ensuring that he does not
contribute to the ability of third parties to communicate
confidentially with the owner of the certified key.

- Jon already gave a semantics for a CA flag as a way for a CA to
organise it's own keys.  A CA flag can't be both for CA delegation and
for denying users ability to certify, unless one posits that no users
are allowed to certify (which is the X.509 model), which can not be
due to the WoT anyone a CA model.

etc.  

Jon wrote:

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

I think that the trust model can not be quite agnostic.  The two trust
models (CA based, and WoT based) have to after all interoperate, or we
risk fragmenting the interoperability between PGP users.

So I think that the trust model necessarily has to be the WoT model,
with the CA model being included via the definition that a CA is just
another user in the PGP WoT with no special status.

The semantics of the use of signature and encryption key flags in
certificates are bizarre and out of sync with the properties of the
WoT model I think are necessary for interoperability.

Adam

---

From: Jon Callas <[email-masked]>
Date: Tue, 09 Mar 1999 17:33:39 -0800

At 12:13 AM 3/10/99 GMT, Adam Back wrote:
|
|I understand Jon to be saying that if key A certifies another key B
|with the CA flag enabled, this indicates that A is delegating ability
|to certify *on A's behalf*.

I'm sorry I was unclear. I actually meant quite the opposite.

If any of those flags is set, it means exactly the same thing as if the
flags subpacket is not present. That's what I meant by it being a "negative
sense" flag, and by them being limitations of scope. It's assumed that if
no flags are present, the key can be used for any purpose (modulo technical
considerations, of course). Nonetheless, you're right, this allows you to
do fancy things with your keys.

|
|This sounds useful.  If I want to do something fancy with my keys,
|such as:
|
|- delegate trust from a securely stored key to other keys 
|  which are used on a day to day basis
|- start a time-stamping service, with extra time-stamping key
|- operate a CA with multiple keys for different purposes
|
|etc. I can use the CA flag to designate by sub-signature keys.
|
|I think this means that an implementation SHOULD NOT issue CA
|certificates for other peoples keys.  Or in other words the CA flag is
|for organisation of ones own keys.
|
|So if we examine Bob's key and it has a signature from Alice's key A2
|and Alice's key A2 has a CA signature from Alice's key A1, that means
|we can categorise the three identities: A2 and A1 are the same person.
|B is someone else who A chose to certify the identity of.
|
|This is useful in that if we trust A1, A1 is telling us to trust A2 to
|the same level.

Well, there's no such thing as a CA signature. There are "certification
signatures" (types 0x10 through 0x13) and mathematically, the issuer of a
certification signature is a CA. The traditional PGP term for this person,
though is an "introducer."

If the flags subpacket is present in the signature Alice made, the
"certification" flag is interesting only when it is 0. If it is 1, it's the
same thing as Alice not putting it there at all. If it is zero, Alice is
asking you not to propagate trust from her key to Bob's key to some other
key. That's all it means. You're free to ignore Alice. That's the essence
of the PGP model -- the user gets to say "so what?" to a CA.

|
|Jon also explained how the trust flag can be used to do something
|similar:
|
|| 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." 
|
|I am unclear here on what the difference is.  Why have two competing
|mechanisms to achieve the same thing?  The trust signature seems to be
|the more general mechanism, what is the CA flag adding?
|

They aren't the same thing. They are similar, but not at all the same
thing. Again, my apologies for rambling. The "trust signature" subpacket
allows an issuer to delegate validity signatures. Let's suppose that I set
Alice as a fully trusted introducer. Let us suppose that Alice has signed
Bob's key with a "trust signature" subpacket with depth of 1. This means
that I will accept as valid any key Bob as signed. If the depth was 2, then
any key signed by someone signed by Bob. And so on.

I will also note that when issued in pairs (Alice signs Bob and Bob signs
Alice) these function as "cross certification" signatures in X.509. I
discovered this in the course of some long discussions with some Entrust
people. 

|eg. Say the CA has a root key used for delegating roles to it's other
|keys.  It delegates the role of certifying client's keys with a
|signature with the CA flag.  It delegates the role of document signing
|to another key with a siganture with the CA and sign flags.

It should delegate that role by issuing a trust signature subpacket, not
with the flags.

|
|It would seem that the signature flag would be able to certify
|encryption sub-keys directly, so the encryption flag applied to
|certificates would be redundant under this speculated semantics.
|

It might seem that way, but it's not been anyone's intent to do that, and
no one has implemented code to do that. This is why we say that OpenPGP is
"escrow-surly." One certifies only the top-level key, and the keyholder can
play with subkeys to their delight.

|If key flags were intended to be used in the certificates the CA hands
|out to it's clients, I would really like to hear Lutz or someone
|explain what the CA requirement is for this, and what the semantics of
|the result is.  What would the certificates mean in the PGP WoT model
|where there is nothing but peer to peer certifcation, and where
|everyone is a CA.

The requirement, as explained to me, is to have a way to explicitly say, "I
take no responsibility for any certifications this key makes." I'll also
note again that OpenPGP has no trust model. PRZ has agreed to write an
informational RFC describing the WoT, but no one is required to use any
trust model.

|
|I think that the trust model can not be quite agnostic.  The two trust
|models (CA based, and WoT based) have to after all interoperate, or we
|risk fragmenting the interoperability between PGP users.
|
|So I think that the trust model necessarily has to be the WoT model,
|with the CA model being included via the definition that a CA is just
|another user in the PGP WoT with no special status.
|
|The semantics of the use of signature and encryption key flags in
|certificates are bizarre and out of sync with the properties of the
|WoT model I think are necessary for interoperability.
|

I'll write another note on this. I disagree, and I think it deserves its
own discussion. There are existing implementations that do just fine. They
don't implement key flags yet, but they will.

	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: Bill Frantz <[email-masked]>
Date: Tue, 9 Mar 1999 23:44:39 -0700

At 5:13 PM -0700 3/9/99, Adam Back wrote:
>...

Of course, the level of trust is unlikely to be the same.  A daily use key
is more likely to be compromised than a securely stored key.  People may
place more trust in my 1024 bit DSA key than in my 768 bit RSA key, which
are cross signed.  (Or they my put more trust in RSA than in DSA.)

-------------------------------------------------------------------------
Bill Frantz       | Macintosh: Didn't do every-| Periwinkle -- Consulting
(408)356-8506     | thing right, but did know  | 16345 Englewood Ave.
[email-masked] | the century would end.     | Los Gatos, CA 95032, USA

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 10 Mar 1999 09:13:28 +0100

On 1999-03-09 17:33:39 -0800, Jon Callas wrote about CA flags:

> "certification" flag is interesting only when it is 0. If it is 1,
> it's the same thing as Alice not putting it there at all. If it is
> zero, Alice is asking you not to propagate trust from her key to
> Bob's key to some other key.

I don't understand this.  Is it possible that you are confusing
recommendations and "usual" certificates here?

We have well-defined recommendations ("trust signatures") in the
spec. It would thus be silly to assume that a plain (user-id, key)
certification implies any recommendation about the signee.  This
means that the CA flag would just be a no-op on any certificates,
and completely useless for actual CA use.

The only reasonable interpretation would be that the "default" CA
flag (i.e., the meaning of no such sub-packet) should be 0, i.e.,
"don't pass trust".  This is actually consistant with the phrasing
in the spec which says that "missing" flags should default to 0.

To put it short: The key flag spec is seriously flawed.  We may wish
to revise this in a future version.

tlr
-- 
http://home.pages.de/~roessler/

---

From: Jon Callas <[email-masked]>
Date: Wed, 10 Mar 1999 11:31:55 -0800

At 09:13 AM 3/10/99 +0100, Thomas Roessler wrote:
|On 1999-03-09 17:33:39 -0800, Jon Callas wrote about CA flags:

|I don't understand this.  Is it possible that you are confusing
|recommendations and "usual" certificates here?
|

I don't believe that I'm confusing things. What I'm saying is that since a
"normal" PGP key can be used for any purpose, a key that has no key flags
on it obviously is equivalent to these flags being 1. (That byte also
contains some other flags that are obviously zero if not present. If
there's a flaw in the definition, I think it's here.)

|We have well-defined recommendations ("trust signatures") in the
|spec. It would thus be silly to assume that a plain (user-id, key)
|certification implies any recommendation about the signee.  This
|means that the CA flag would just be a no-op on any certificates,
|and completely useless for actual CA use.
|

I disagree. If a CA wants to explicitly state that a signature is a "leaf
certificate" it puts a zero certification flag on its signature. That's
about the only real use for third-party key flags.

|The only reasonable interpretation would be that the "default" CA
|flag (i.e., the meaning of no such sub-packet) should be 0, i.e.,
|"don't pass trust".  This is actually consistant with the phrasing
|in the spec which says that "missing" flags should default to 0.
|

Given that the standard PGP way of dealing with key signatures is that the
user may pass trust any old way they choose (by setting introducers, etc.),
I have to disagree that that's the *only* reasonable interpretation.

Throughout the life of PGP, there has been a grand, unanswered question:
what does it mean to sign someone else's key? Many people have their own
opinions, but there's no agreement on it.

I know people who refuse to sign other people's keys because they believe
that it exposes them to liability. I don't understand this, but hey. One of
the reasons "local" signatures were created was that these people never
signed any keys whatsoever, and it kinda made the web of trust hard to work
with when all the keys someone dealt with were considered invalid.

There are other people who don't mind signing other people's keys, but
don't want their signatures used in further validity calculations. (Alice
is willing to sign Bob's key, but Alice doesn't want to imply that she
thinks Bob is at all competant to sign.) All this flag does is allow Alice
to say that.

|To put it short: The key flag spec is seriously flawed.  We may wish
|to revise this in a future version.

I disagree completely. It's a subtle concept, but it is the solution to a
flaw that exists without it.

	Jon

-----
Jon Callas                                  [email-masked]

---

From: Adam Back <[email-masked]>
Date: Thu, 11 Mar 1999 00:37:17 GMT

Thanks for the clarifications, I think we are getting close to
unambigous now.  My understanding of the semantics now leads me to the
conclusion that the flags are not that useful, or constructive.

To tally we have semantics of the following flags when used in a
certificate signature

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

Jon:
> "certification" flag is interesting only when it is 0. [...] If it is
> zero, Alice is asking you not to propagate trust from her key to Bob's
> key to some other key. 

I'll come back to discussion of this below, but we now have a defined
and clear semantics.

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

Jon:
> 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.
> [...]
> it's not been anyone's intent to do that [use encryption flags on
> certification signatures], and no one has implemented code to do
> that.

So 0x04 and 0x08 are meaningless in the context of certificates.

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

This flag is of limited value also.  If we tabulate the possible
values, we have:

0x8 encrypt storage.	x	x	x	x
0x4 encrypt comms.	x	x	x	x
0x2 sign		0	1	0	1
0x1 certify		0	0	1	1

(encrypt are x = don't care because they have no meaning).

we can see that:

xx00 has no meaning as it is a null certificate (can't sign, can't
certify = no value!)

xx11 is redundant because it is the same as missing off the key flag

xx01 you can use this cert in the calcuation of validity for
certification purposes but not for document signatures; odd because
certifation is generally considered a more security critical operation
than document signature.

xx10 you can sign but not certify.

Now the discussion of the certify flag.

Overall the flags seem to be very CA centric.  The certify flag (when
set to zero) has negative impact on the WoT, though perhaps a CA might
be interested to use them to prevent people who had not paid the CA
for a cetificate having their WoT connectivity strengthened by the
CA's efforts.  As the user of a key so certified, one derives more
security (better WoT connections) by ignoring the fact that the flag
is set to zero).

The sign flag (when set to zero, which only makes sense to do if the
certify flag set to one) is a bit odd.  As the user of a key so
certified, one derives more security (better WoT connections) by
ignoring the fact that the key is set to zero!

So both use of either of these flags seems to detract from the WoT,
and the best thing a client could do from a security perspective is to
ignore both of them.

Comments?

Adam

---

From: Jon Callas <[email-masked]>
Date: Thu, 11 Mar 1999 14:10:11 -0800

At 12:37 AM 3/11/99 GMT, Adam Back wrote:

|xx01 you can use this cert in the calcuation of validity for
|certification purposes but not for document signatures; odd because
|certifation is generally considered a more security critical operation
|than document signature.
|

Not if it's a key to be used for certification only. If someone were to
make a CA, that might be a reasonable thing to do. I just searched
certserver.pgp.com for all keys with the word "certification" in them. It
maxed out and sent me only 48 keys. 

|Overall the flags seem to be very CA centric.  The certify flag (when
|set to zero) has negative impact on the WoT, though perhaps a CA might
|be interested to use them to prevent people who had not paid the CA
|for a cetificate having their WoT connectivity strengthened by the
|CA's efforts.  As the user of a key so certified, one derives more
|security (better WoT connections) by ignoring the fact that the flag
|is set to zero).

There's a reason they are CA-centric. They were requested by people
building CAs.

I'll say it again. There is no web of trust in OpenPGP. There is no
mandated trust model in OpenPGP. The working group EXPLICITLY shot down the
notion that there should be a trust model, and that the semantic mechanisms
be left to the discretion of the implementer.

|
|The sign flag (when set to zero, which only makes sense to do if the
|certify flag set to one) is a bit odd.  As the user of a key so
|certified, one derives more security (better WoT connections) by
|ignoring the fact that the key is set to zero!
|

I agree with you completely that there will be many cases where third-party
statements will be ignored, or even met with derisive laughter. If we look
at Alice making statements about Bob's key, unless I know who Alice is (she
may be just a 64-bit keyid to me), and actually care, I'm not likely to
even look at the contents of her signature, let alone try to interpret it.

I also agree that in the vast majority of cases, third-party statements are
silly. We haven't even discussed the other two defined flags -- the "secret
shared" flag and the "ecrowed" flag. However, there are cases in which
these are useful. Let me give an example:

The Aluminum Bavariati, a secret society of 144,000 members, wants all its
members to use OpenPGP. The AB secret masters will sign each Bavariati
member's keys so that other members will know they're dealing with a fellow
Bavariatus. The Bavariati policy, though, is that they believe the
organization should use single-key RSA keys, and a separate key for comm
encryption, storage encryption, and signatures. They don't want any of
those keys used for key signing. They don't care which keys you use for
what on non-Bavariati business. These flags are exactly what the society
needs. You and I don't need them, but they serve a purpose that can't be
served without them.

	Jon

-----
Jon Callas                                  [email-masked]

---

From: [email-masked] (Lutz Donnerhacke)
Date: 15 Mar 1999 11:22:34 GMT

>| certification.  Lutz, for example, needs these for his CA business

To clear this: CA means 'Certification', such a key is allowed to sign other
keys. 'sign' mean 'Signature creation', such a key is allowed to sign non
key material.

---

From: [email-masked] (Ulf Möller)
Date: Fri, 19 Mar 99 02:18 +0100

Why doesn't RFC 2440 reference the Digital Signature Standard?

---

From: Jon Callas <[email-masked]>
Date: Fri, 19 Mar 1999 14:44:22 -0800

At 02:18 AM 3/19/99 +0100, Ulf Möller wrote:
|Why doesn't RFC 2440 reference the Digital Signature Standard?
|

Because we neglected to do that.

	Jon

-----
Jon Callas                                  [email-masked]

---

From: [email-masked] (Ulf Möller)
Date: Wed, 24 Mar 99 19:26 +0100

According to RFC 2440, if a four-octet length Public Subkey Packet
is bound to a key, the signature is computed over a packet with a
two-octet length field.

In violation of the RFC, both PGP and GnuPG reject such signatures.

(Section 5.2.4: "When a signature is made over a key, the hash data
starts with the octet 0x99, followed by a two-octet length of the key,
and then body of the key packet. (Note that this is an old-style
packet header for a key packet with two-octet length.) A subkey
signature (type 0x18) then hashes the subkey, using the same format as
the main key.").

---

From: [email-masked] (Ulf Möller)
Date: Wed, 24 Mar 99 19:36 +0100

Did it ever occur to anyone that allowing different hash algorithms
with DSA reduces security rather than increasing it?

In DSA signatures, hash algorithm selector is secured only with the
selected hash algorithm itself. So, if SHA-1 is insecure, you can
forge signatures even if the key owner never uses SHA-1. If SHA-1 is
secure, but any other permissible hash algorithm is insecure, you can
also forge signatures. That would not be the case if OpenPGP had
followed the DSS.