rfc: verify-ssh

[Daniel Kahn Gillmor]

On 01/28/2012 08:09 AM, Nikos Mavrogiannopoulos wrote:
> Hello,
>  I've added two new functions gnutls_verify_stored_pubkey() and
> gnutls_store_pubkey() [0], that allow for an SSH-style authentication.
> That is they allow to trust public keys from certificates associated
> with a hostname and a service, based on whether they have been seen before.
> 
> This by itself is not really much, but using it in a hybrid model where
> certificates are verified using the trusted certificate list _and_ the
> known public keys, it would increase security overall, as a compromise
> of a CA would not be enough to perform man-in-the-middle.

sounds like this is potentially a good toolkit for implementing public
key pinning, which is currently being discussed on websec:

 https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

Is this the intent?  If so, should we consider including expiration
dates in the format in question, or having a way to store a digest in
place of the raw pubkey, if we haven't seen the pubkey itself yet?

Can you explain the difference between the intended use of "application"
and "service" parameters in gnutls_store_pubkey, find_stored_pubkey, and
gnutls_verify_stored_pubkey ?

The linear file storage mechanism probably won't scale well for
implementations that deal with many many such keys over time (e.g. a web
browser).  Any thoughts about how to offer such a mechanism in a way
that scales better?

Thanks for working on this, i think it's an important piece of the puzzle.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20120131/53f0cb77/attachment.pgp>