OpenPGP Authentication Protocol?

[Melvin Carvalho]

On 23 December 2012 23:17, Daniel Kahn Gillmor <dkg at fifthhorseman.net>wrote:

> 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.
>

+1

We came to a similar conclusion with the WebID [1], where in fact, I do
actually use my GPG master key as my X.509 and WebID key.  You may be
interested in looking at WebID for client server interactions, currently
there are working demos over TLS, tho many people say that the UI for
certificates in browsers make them unusable.

That three concepts should be considered as topics in their own right:  A)
identification, B) authentication and C) authorization.

Which (B) and (C) are often separated, (A) and (B) are often coupled
together.  After about 5 years of work, WebID is being rewritten into new
specs which contain solutions to A,B,C separately.

[1] http://webid.info


>
> Regards,
>
>         --dkg
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20121223/8a25c82c/attachment-0001.htm>