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