Subject: [openpgp] marking subkeys as constrained for specific use -- new key usage flags?

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 05 Mar 2013 04:41:58 -0500

Hi good OpenPGP people--

I use both OpenPGP and OTR.  my OTR implementation has its own public key.

I can see a use case for indicating my OTR public key directly as a
subkey on my main OpenPGP key, so that anyone who knows me via the
OpenPGP web of trust could have their tools automatically authenticate
me (without having to do any of the various OTR authentication
handshakes explicitly).

I also think i would like this subkey to be unambiguously identified as
an OTR public key, so that it is not accepted for use in any other
context (e.g. it would be bad if someone who was able to compromise my
OTR client and steal my OTR key was able to use the secret key material
to impersonate me over SSH).

How could i indicate such a clear constraint?

I have a couple of ideas, and would be happy to hear people's thoughts:

A) allocate 0x40 of the usage flags [0] to mean "use in OTR".

  What kind of work needs to be done to get a new bit allocated there?
  Is allocating a new bit reasonable?

B) use the "authentication" usage flag with a critical notation.

   Since the OTR subkey is clearly used for authentication purposes,
   perhaps the right way to go is to mark the key as authentication-
   capable in the usage flags, but also add a critical notation that
   indicating that the scope of use is limited to otr.  Does such a
   thing already exist?

Option A seems cleaner to me (since no existing implementations would
mistake such a marked subkey as useful for anything else), but i worry
about how it would scale in the bigger picture -- how many such bits are
we going to need to allocate if keys can be useful elsewhere?

OTOH, maybe that's not a big deal.  And option B seems risky in the near
term -- how many OpenPGP implementations will actually respect the
critical bit and reject that subkey binding signature if they know that
they are not in the OTR context?

Suggestions?  Is there some other way i should approach this?

	--dkg

[0] https://tools.ietf.org/html/rfc4880#section-5.2.3.21

---

From: Jon Callas <[email-masked]>
Date: Tue, 5 Mar 2013 06:59:19 -0800

Notations are specifically designed for open-ended additions to whatever.

	Jon

---

From: David Shaw <[email-masked]>
Date: Tue, 5 Mar 2013 10:19:12 -0500

> they are not in the OTR context?

I'd do this with a notation (option B, which can be marked as critical if you desire).  The Usage flags are helpful but I don't think they have the ability to carry enough information to really state what you are trying to say.  Usage is more "this key can may be used for authentication", and it sounds like what you're looking for is "this key may be used for authentication, but only in the context of OTR".

I can't speak for all OpenPGP implementations, but GPG will correctly reject a subkey binding signature if it has a critical notation that GPG doesn't know about.  I'm not sure if that helps or hurts your plan, though, as without adding code to GPG to understand your notation, you won't easily be able to show a connection from your OpenPGP key to the OTR subkey.

David

---

From: Werner Koch <[email-masked]>
Date: Tue, 05 Mar 2013 16:55:17 +0100

On Tue,  5 Mar 2013 16:19, [email-masked] said:

> plan, though, as without adding code to GPG to understand your
> notation, you won't easily be able to show a connection from your
> OpenPGP key to the OTR subkey.

Actually this would be an argument in favor of key flags - the changes to
the code would be much easier.

RFC4880 says about key flags:

   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 as follows:

Thus back in 1997/98 we must have assumed that key flags are a useful
thing.  I agree that we should not add new key flags without a strong
reason.  XMPP, however, is evolving to a very useful protocol and OTR is
the preferred way of securing it in the real world (much like PGP was
used instead of X.509).  A discussion right now at cryptography@
stresses the importance of OTR over the originally designed Jabber
security features.

Given that OTR is a different use case than data storage or mail
encryption, I think adding a new key flags for OTR is justified.  Maybe
we could come up with a more generic term, but to me OTR would be fine
('o' is not yet used as letter describing a key capability ;-).

While we are at it: What about using 0x40 of the first octet to indicate
that the private component of the key is stored on offline medium?  That
"offline key" would nicely go with "split key" (0x10) and "group key"
(0x80).  OTR may then go into the second octet.

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Jon Callas <[email-masked]>
Date: Tue, 5 Mar 2013 08:10:30 -0800

> I'd do this with a notation (option B, which can be marked as critical if you desire).  The Usage flags are helpful but I don't think they have the ability to carry enough information to really sta…

Usage flags are there for broad declarations. For example, so that you use an RSA key for encryption but not signing, or a signing key for authentication-based signing, but not documents.

If you're really going to put protocol-specific notes in, then notations are the way to go.

> I can't speak for all OpenPGP implementations, but GPG will correctly reject a subkey binding signature if it has a critical notation that GPG doesn't know about.  I'm not sure if that helps or hur…

There's a problem with criticality as a concept in general, and that is that if you really do private development, it can cause things to explode in ways that are not useful.

In this case, we have an authentication-only subkey that's intended to be used for OTR. If you mark it as authentication-only, it's not going to be used for document signing, which is really what you want. It's possible that some other authentication protocol could grab it, but is that really a problem?

This brings us to the problem with criticality. It's supposed to keep some item from being used in an unknown way. But it can also fail in unexpected ways. I've seen criticality flags cause all sorts of weird issues in other systems, and the usual fix is not to make it critical.

	Jon

---

From: David Shaw <[email-masked]>
Date: Tue, 5 Mar 2013 11:30:54 -0500

> (0x80).  OTR may then go into the second octet.

Can you give an example why would someone want to publish that their private key is offline?  I'm not sure I see a use for that.

David

---

From: Werner Koch <[email-masked]>
Date: Tue, 05 Mar 2013 17:53:51 +0100

> Can you give an example why would someone want to publish that their private key is offline?  I'm not sure I see a use for that.

I have two encryption keys but only one marked as offline.  If someone
wants to send a quick message he would encrypt to the non-offline key.
If he has to tell me something really secret, he would select the
offline key, assuming that I will move the message to a non-networked
box where the offline key is stored.

I am not sure whether this is really useful for most users, but split
and group keys are also somewhat esoteric and not even defined in
OpenPGP.

Salam-Shalom,

   Werner

---

From: David Shaw <[email-masked]>
Date: Tue, 5 Mar 2013 19:26:37 -0500

> box where the offline key is stored.

Ah, that's a good point.  It's still up to the sender which key to use, but you can choose to give a hint.

> and group keys are also somewhat esoteric and not even defined in

Yes.  I've wondered about the split key bit in the past.  The group key bit seems fairly straightforward: if the bit it set, then the verifier of a signature is effectively being told the sender isn't a person, but a group, so the verifier can't expect that a single person was responsible (and similar logic for encryption).  Of course, there is nothing forcing the owners of a group key to set the bit, but if they want to, it's there.

David

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 07 Mar 2013 08:45:03 -0500

> In this case, we have an authentication-only subkey that's intended to be used for OTR. If you mark it as authentication-only, it's not going to be used for document signing, which is really what y…

well, yes, this was my original concern.

i wrote:
>>  (e.g. it would be bad if someone who was able to compromise my

We already have systems in place (e.g. monkeysphere) that permit the use
of authentication-capable subkeys for ssh systems.  so if i was to mark
my OTR key as authentication-capable, and critical notations were not
widely respected, that wouldn't turn out very well.

> This brings us to the problem with criticality. It's supposed to keep some item from being used in an unknown way. But it can also fail in unexpected ways. I've seen criticality flags cause all sor…

If criticality is fraught with problems, doesn't that suggest extending
the usage flags is a more responsible way to go?

or should i create a subkey with all usage flags set to 0, and then
include a notation to indicate the use?  that way, the subkey wouldn't
be used by any existing system except the ones willing to parse and
interpret the notation, regardless of its criticality.

	--dkg

---

From: Jon Callas <[email-masked]>
Date: Thu, 7 Mar 2013 10:59:20 -0800

> the usage flags is a more responsible way to go?

No, because either you want *that* to be critical, too, which has the same criticality issue, or criticality is not important in which case the notation works too.

My comment was one about criticality in general. We have criticality because there were people in the late '90s who thought it was a good idea. It *is* a good idea, but it is such a subtle idea that it's Shannon information, kolmogorov complexity, etc. is more than one bit.

> interpret the notation, regardless of its criticality.

Well, if you did that, you wouldn't not be RFC 4880 compliant. There is a way to do this within the standard -- the notation.

The whole reason that we have notations is so that if you want to do something on your own, there's a supported way to do that. What's wrong with using the supported way, as opposed to violating the standard with hacks? (I'm not above violating standards with hacks, but I expect to have to answer that question, myself.)

If my cynical beliefs about criticality scared you away from doing the right thing, then I apologize. I never intended to do that. I was merely pointing out that if you put the critical flag on it, then it possibly would have unintended failure modes and meta-failures.

The correct thing to do is a notation. Put the critical flag on it. Please.

	Jon