Hal writes that certification is about making assertions that "this
key belongs to this person":
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.
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.
Hal writes:
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.
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