Hi, >> The security argument itself seems very weak. There is no evidence yet that >> the alternative strategy that Google proposes, namely letting them control >> the CRL list (and thus another part of the internet infrastructure), is any >> safer for the user in the long run. > > The point is that using this mechanism means Chrome always has an > up-to-date revocation list - as it is now, revocation checking can be > blocked and Chrome will allow revoked certs as a result.
What is the point in disabling OCSP, then? Chrome could always use its
own revocation database as a primary reference, and use OCSP
additionally if there is no hit. I like that Chrome pulls revocations
via the update mechanism, but this does not sound very scalable - where
do you draw the line? Do you have data how many CRL entries come with a
reason (those are preferred by Chrome). How do you make sure no false
reason is given by CAs as a consequence - i.e. they always just put fake
entries there saying "cert renewed" even though it may actually have
been a compromise.
So, yes, Chrome does raise the barriers a bit, but I fail to see how
this could be a long-term solution and how it could extend to anything
but a small selected subset of the Web.
>> Certainly the privacy concern that Google expresses "because the CA learns
>> the IP address of users and which sites they're visiting" does not extend to
>> Google itself, which already has much more detailed information about its
>> users.
>
> Since it is a push mechanism, Google does not get which sites the user
> is visiting.
I think Markus' point is: it is not an advance in privacy for the user.
Many people just type a keyword into the omnibox to land on the desired
page ("facebook"). Thus, Google already knows what they do; they do not
need the information from online revocation checking.
--
Dipl.-Inform. Ralph Holz
I8: Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
