-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This discussion raises another concern I've had regarding new flags.
The description (in draft 7, anyway) reads:
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.
...
In fact, the list of flags can grow *without* increasing the length.
we're contemplating adding new flags to the first octet.
I think it's inappropriate to change the meaning of an old signature
by adding flags to the specification.
Here, we're considering adding exactly one bit:
0x20 - This key may be used for authentication.
An old signature didn't contemplate the meaning of this bit.
The key might be intended for authentication; it might not.
New software that looks at this bit can't tell whether: the
signer explicitly chose not to allow authentication; or, the
signer was using an old revision of the specification.
But, new flags can be structured to disambiguate new revisions
from old. For example, here we can add two bits:
0x20 - This key may be used for authentication.
0x40 - (Bit 0x20 is explicitly set.)
Old signatures would have a zero in 0x40, so a new application
can apply its own default (rather than having one imposed by
the specification). New signatures that actively decide on the
value for the 0x20 bit must set 0x40. (A new signer could also
choose to accept the viewer's default by leaving 0x40 zero.)
I don't know whether this is the right time to start adopting this
sort of policy for new flags -- do implementations make use of
the existing key flags already? If they do, then I strongly
encourage including disambiguation for new flags.
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3
iQA/AwUBPuyWWOc3iHYL8FknEQJvRwCfQjcFuBDOGOeEX86hqtsXSea1pbsAoJH5
I/n8ZbzEHQnJpqme/AKOwVMo
=XT3/
-----END PGP SIGNATURE-----