Cert pinning

Hal Murray hmurray at megapathdsl.net
Mon Apr 1 22:46:59 UTC 2019

[Argh.  Sorry for the duplicate.  I forgot to cc the list.]

> Sad.  Seems we've been around this May Pole way too many times already... You
> have nothing new to say below, and my answers are also not new. 

Richard's summary matches my understanding.

> Agreed, sort of.  This assumes fixes that do not exist.  So "assuming a
> canopener".  It also assumes that less than perfect security is no security.

The problem with pseudo security is that people might think it really is 

If it's not (real) secure, I think we should make a lot of noise about using 

> Part of the rationale for NTS is that since the cookies change every request,
> then the user can not be tracked. "noval" does not remove that feature, or
> some other goodness. 

Why are you bringing up tracking?  Is it related to security?  To pinning?

> Agreed, sort of.  The "ca", which is an "assumed can opener", does not solve
> many very similar cases. 

My plan is to implement the per-server "ca" as soon as I can.  The API I want 
isn't available, but I think I see a reasonable way to implement it.

That will solve the problem of self-certified certificates.  How many of your 
"many very similar" cases are interesting?

> Personally, I'd rather have DANE type pinning before "ca".  And once "ca" is
> implemented would like to do both. 

Are you trying to use DANE as a substitute for normal certificate checking or 
as a supplement?

I don't fully understand DANE yet.  A good example might help.  Is there a 
HOWTO type web page telling me how to set things up?  ...

Is it widely deployed?  Does my browser use it?

These are my opinions.  I hate spam.

More information about the devel mailing list