Werner Koch wrote:
Hi!
I know that we are short of releasing a new RFC and bis-08 looks
really good. Due to the project I am currently working on I'd like to
suggest a small enhancement:
5.2.3.21. Key Flags
[...]
0x20 - This key may be used for authentication.
Usage notes are not necessary and it should be left to an
implementation on how to handle this key flag.
There are drafts and actual implementations to use OpenPGP keys with
TLS and ssh. Thus, having a subkey specially for this purpose seems
to be a good idea. A key with key flag 0x02 (sign data) could be used
for authentication too but this has the problem than there would be no
easy way to select the appropriate subkey for data signing or
authentication purposes. As a workaround an implementation could use
notation data but this would be implementation dependend and a kind of
hack.
What do you think?
Not that I disagree with you, but I'd like to point out
alternative practice.
We (Systemics/Ricardo/SOX/WebFunds) have been using PGP keys
for authentication purposes for years (8, if anyone's counting,
with a couple of years gap where we got blindsided into
x.509). (Something betwee 100k and a million transactions.)
To identify keys and their roles, we stick the following
into the keyId textual tag:
[role]
where role could be one of certification, operator, server,
contract, ...
This appears to be much more flexible than looking for bits
in the key, as it allows lots of roles. When one gets into
bigger protocols, one ends up with dozens of different keys
at different places in the PKI. And they all need to have
their roles and characteristics encoded in them.
So, whilst I wouldn't necessarily disagree with the bit
being there, I'm not sure I see the need.
(And, thinking about it some more, I can see that the issue
you might have there is that once you have your authentication
bit in place, how do you show that the key is to be used for
SSH authentication and not TLS?)
Just some thoughts!
--
iang