On 2010-12-07 16:54, Peter Saint-Andre wrote: > On 12/7/10 3:48 PM, Stef Walter wrote: >> So I imagine we should keep the terminology separate if 'pinning' a >> certificate already has a distinct meaning. > > To be clear, a self-signed certificate isn't a fit subject for checking > the certificate path (there is none), the revocation status (there's no > one to revoke it), etc. In the spec I've pointed you to, we don't > discuss self-signed certificates at all (and that's by design). However, > I think you could use the term "pinning" with regard both to CA-issued > certs that trigger identity mismatches and to self-signed certs.
I like the term pinning. It describes well what's going on. I'll consider using it in the various function names and object names. We need to come up with a general consensus on the behavior when: * An expired certificate is pinned. * An invalid self-signed certificate is pinned. In no case can a pinned certificate change after the fact. Such pinning or 'certificate exceptions' as I was calling them must always use either the full DER value of the certificate (or a cryptographically strong hash) to identify the certificate. So the questions I have are: * Should the user be allowed to 'pin' a inherently invalid certificate: (not yet valid, already expired, bad signature) * If an already pinned certificate expires, is it still considered pinned? May seem like nitpicking but that's important with security. Do you know of any previous discussion about this? Cheers, Stef _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
