Erwann Abalea a écrit :
if Google could come up with an efficient mechanism so that
revocation is really checked, that's cool. The less than 100k is a
challenge, I'd like to see how it will be solved
The more since all those random serial numbers can't be compressed.
I wonder if he wasn't
Erwann Abalea a écrit :
Who will come with a 12-dan black bar UI?
That's a joke on the fact it goes full-cycle at 12-dan and we're back to
a white belt, right ? But double-width, so you *can* tell the difference
with the normal white bar ;-)
--
dev-tech-crypto mailing list
(Rob asked me to clarify this point.)
I would, indeed, like the *total* size of the data to be 100KB. At the moment
it's ~70KB with ~1-1.5KB updates every 12 hours.
Cheers
AGL
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
Le vendredi 10 février 2012 01:32:47 UTC+1, Ondrej Mikle a écrit :
[...]
A quote from Lucky Green
(http://lists.randombit.net/pipermail/cryptography/2011-December/001918.html):
Most (but not all) of the CAs that I worked with over the years did not
have anybody on the operations side full
Le mercredi 8 février 2012 21:57:09 UTC+1, Kai Engert a écrit :
My criticism:
(a)
I don't like it that the amount of CRLs will be a subset of all CRLs.
What about all the revoked certificates that aren't included in the list?
With a dynamic mechanism like OCSP (and in the future OCSP
On 10/02/12 21:40 PM, Erwann Abalea wrote:
Le vendredi 10 février 2012 01:32:47 UTC+1, Ondrej Mikle a écrit :
[...]
A quote from Lucky Green
(http://lists.randombit.net/pipermail/cryptography/2011-December/001918.html):
Most (but not all) of the CAs that I worked with over the years did not
On 02/10/2012 11:40 AM, Erwann Abalea wrote:
Le vendredi 10 février 2012 01:32:47 UTC+1, Ondrej Mikle a écrit :
[...]
A quote from Lucky Green
(http://lists.randombit.net/pipermail/cryptography/2011-December/001918.html):
Most (but not all) of the CAs that I worked with over the years did
On 02/10/2012 01:26 PM, From ianG:
So, any routine compromise or replaced or not-sure or NULL
issues aren't to be in there. Which gets it down to numbers less than
1000 for the entire industry -- ones where the CA knows there is trouble.
From the point of view of a CA (me) it really
Le vendredi 10 février 2012 13:44:20 UTC+1, Ondrej Mikle a écrit :
[...]
UI of TLS clients could be different for specific revocation reasons.
It's really a corner case (just for the sole purpose of an example).
Please, not another UI change.
We have a green bar that's not displayed the same
On 02/10/2012 03:10 PM, Erwann Abalea wrote:
Le vendredi 10 février 2012 13:44:20 UTC+1, Ondrej Mikle a écrit :
[...]
UI of TLS clients could be different for specific revocation reasons.
It's really a corner case (just for the sole purpose of an example).
Please, not another UI change.
I
FYI, Adam Langley told me The hope is that everything is 100KB.
I asked him if I could share that figure here and he just replied No
problem. It's not a strict limit that we set and we'll have to see
how well we do.
We've calculated that there are currently ~53,000 revoked Server
On 09/02/12 12:54, Rob Stradling wrote:
We've calculated that there are currently ~53,000 revoked Server
Authentication certs that were issued by Comodo's CA systems, each with
a serial number of 16 bytes (+ a leading zero byte if required to ensure
it's not treated as a negative number). That
On 09/02/12 13:10, Gervase Markham wrote:
On 09/02/12 12:54, Rob Stradling wrote:
We've calculated that there are currently ~53,000 revoked Server
Authentication certs that were issued by Comodo's CA systems, each with
a serial number of 16 bytes (+ a leading zero byte if required to ensure
On 02/09/2012 01:20 AM, Brian Smith wrote:
I am also concerned about the filtering based on reason codes. Is it
realistic to expect that every site that has a key compromise to publicly
state that fact? Isn't it pretty likely that after a server's EE certificate
has been revoked, that
My criticism:
(a)
I don't like it that the amount of CRLs will be a subset of all CRLs.
What about all the revoked certificates that aren't included in the list?
With a dynamic mechanism like OCSP (and in the future OCSP stapling) you
don't have to make a selection.
(b)
I don't like it
On 02/08/2012 09:58 PM, From Jean-Marc Desperrier:
Whereas the optimal solution would be to download each day a delta
CRL, with only the difference with the previous day, and containing
only the revocation reasons you *really* care about (key compromise).
A certificate can be either valid,
On 02/09/2012 12:18 AM, From Nelson B Bolyard:
Will they really include the CRLs from all of mozilla's trusted CAs?
Won't the union of all those CRLs be huge, even if they strip off
certain reason codes?
BTW, this proposal wouldn't be a problem if it would cover, lets say the
top 500 sites
Eddy Nigg wrote:
On 02/09/2012 12:18 AM, From Nelson B Bolyard:
BTW, this proposal wouldn't be a problem if it would cover, lets say
the top 500 sites and leave the rest to the CAs. There would be
probably also the highest gains.
Effectively, we would be making the most popular servers on the
On 9/02/12 06:58 AM, Jean-Marc Desperrier wrote:
In conclusion I'm 100% in favor of Mozilla adopting this solution,
+1
I haven't looked closely but I'm confident they will do the right thing
in this area.
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
On 02/08/2012 04:20 PM, Brian Smith wrote:
However, I don't think we should reject Google's improvement here because it
isn't perfect. OCSP fetching is frankly a stupid idea, and AFAICT, we're all
doing it mostly because everybody else is doing it and we don't want to look
less secure. In the
On 9/02/12 09:18 AM, Nelson B Bolyard wrote:
On 2012/02/08 12:57 PDT, Kai Engert wrote:
My criticism:
[snip]
Won't the set of CRLs be too big for download?
[snip]
This is my question as well.
Will they really include the CRLs from all of mozilla's trusted CAs?
Won't the union of all those
On 02/09/2012 02:20 AM, From Brian Smith:
Effectively, we would be making the most popular servers on the
internet faster, and giving them a significant competitive advantage
over less popular servers. I am not sure this is compatible with
Mozilla's positions on net neutrality and related
22 matches
Mail list logo
