On Tue, 5 Mar 2013 16:19, dshaw(_at_)jabberwocky(_dot_)com 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.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp