OpenPGP Authentication Protocol?

[Daniel Kahn Gillmor]

On 12/23/2012 04:42 PM, Hauke Laging wrote:
> Am So 23.12.2012, 16:31:01 schrieb Daniel Kahn Gillmor:
> 
>> the ssh specification declares the use pgp-style certificates:
>>
>>   https://tools.ietf.org/html/rfc4253#section-6.6
>>
>> but does little to indicate how peers should consider them for
>> authentication purposes.
> 
> Is that different from "pure" SSH keys or even X.509 client certificates? 

The key format is different than "pure" (i would call "raw") SSH keys --
but these OpenPGP certificates still act as a carrier for RSA or DSA key
objects, which are mathematically and conceptually the same beasts as
"raw" SSH keys.  In SSH, the signature each peer provides when offering
an OpenPGP certificate is expected to be an OpenPGP binary signature
format (instead of a stock SSH-formatted RSA signature).  Beyond that,
the rest of the SSH protocol remains the same.

I don't know of any ssh implementations that support the openpgp
certificate format specification, or of anyone who uses it actively.
otoh, as a monkeysphere developer, i can attest to the existence of ssh
peers that use OpenPGP certificates during authentication/authorization
while still handling "raw" SSH keys and signatures on the wire.

With RFC 6091, even the handshake signature data itself is unchanged --
only the certificate format differs, and the rest of the TLS handshake
remains the same.

? Why should a session protocol define which keys a user should trust?

Beware of the term "trust" in this context -- it's a slippery one, and
it is very easy cause confusion with it.  I think you mean "which keys a
peer should consider for authentication and authorization".  For
example, when i ssh to evilhost.example.org, i might verify the host's
identity successfully via an OpenPGP certificate, and i might even go
ahead and connect to it with SSH, but that wouldn't mean i "trust" the
host in any broader or more human sense of the term "trust".

Anyway, I agree with your implication that a session protocol
specification has no business mandating a specific policy for
authorization or authentication.  But many people considering these
challenges assume that authn/z policies should be bundled with the
protocol spec; so i wanted to make that distinction clear.

Regards,

	--dkg