Ian,
Ian G wrote:
On 8/1/09 21:12, Eddy Nigg wrote:
On 01/08/2009 09:58 PM, Ben Bucksch:
On 08.01.2009 14:46, Johnathan Nightingale wrote:
- All of this would be better with KCM, which is why I filed this bug
to discuss the possibility.
https://bugzilla.mozilla.org/show_bug.cgi?id=kcm
Thank you! Fantastic proposal, thanks for having the guts to challenge
status quo and seriously suggest that. I hope this is carried forward
and implemented and does not just die out.
Isn't this what Firefox already does? E.g. store the remembered decision
permanently? Besides, I realized that the flag to remember is set by
default on and is easily forgotten (judging from some exceptions I'd
rather have not remembered).
Well, what Firefox does is cert-exception-click-thru-ordeal; whereas
people are asking for key-continuity-management, with perhaps the
emphasis on the last word.
Of course, you do realize that the X.509 and PKIX standards perfectly
allow keys to be changed by an entity in new certificates. In fact, one
entity can have multiple certificates with separate keys, for different
purposes. You can have an LDAPS server with one cert and key, an HTTPS
server with another cert and key, etc. All with the same subject name /
DNS name. And they can all be valid at the same time.
Mote that the certs are not linked to a particular TCP port.
Also, a server farm may use, for whatever reason (one of them, keeping
the key in hardware), different certs and keys on each server of the
server farm, and each of these certs could have the same
subject/DNSname, but different keys .
These are just a couple of examples on the top of my head.
If you are going to implement "key continuity management", that would
imply that you will want firefox to warn in all those cases that are
today perfectly legitimate uses of the X.509 PKI with SSL .
IMO, you cannot define application behavior for the KCM cases unless
there is a clear way for both the users and the browser to determine in
which cases KCM is desired or not desired. Currently the standards say
there is no KCM in X.509 . From what I have read of the discussion so
far, the use case seems to be "because somebody was too cheap to get a
$10 DV cert". This should be a rather exceptional situation, not the
rule, and as such, I think the model of "cert-exception-click" is
perfectly fit.
As for it being an ordeal to trust the cert after establishing the
connection, it should be. I personally I don't even think it's hard
enough. IMO, before trusting any self-signed cert, the browser should
prompt the user for a few bytes of the fingerprint of the server cert,
without showing the server cert's fingerprint, and if it matches, allow
the connection to go through. SSH could be made to work that way too.
Instead of typing "yes" blindly, how about asking for the fingerprint ?
This would allow people who are playing with their self signed certs, or
only trust their keys, to exchange this data out of bounds. And if they
want key continuity, well, they can always set an expiration date 100
years in the future in their cert :) . Why would they want another cert
then ?
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
