On 03/05/2013 11:10 AM, Jon Callas wrote:
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?
well, yes, this was my original concern.
i wrote:
(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).
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 sorts of weird issues in other
systems, and the usual fix is not to make it critical.
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
signature.asc
Description: OpenPGP digital signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp