Ryan Sleevi writes:
>Mozilla updates every six to eight weeks. And that works. That's all that
>matters for this discussion.
Do all the world's CAs know this?
Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
ht
Ryan Sleevi writes:
>I can't help but feel you're raising concerns that aren't relevant.
CAs issue roots with effectively infinite (20 to 40-year) lifetimes because
it's too painful to do otherwise. You're proposing instead:
require that all CAs must generate (new) roots on some interval (e.
Michael Casadevall via dev-security-policy
writes:
>I learned something new today. I'm about to run out the door right now so I
>can't read the RFCs but do you know off the top of your head why that was
>removed?
>From the PKIX RFC? There was never any coherent reason given, it just got
turned
Jos Purvis (jopurvis) via dev-security-policy
writes:
>One possibility would be to look at the Trust Anchor Management Protocol
>(TAMP - RFC5934).
Note that TAMP is one of PKIX' many, many gedanken experiments that were
created with little, most likely no, real-world evaluation before it was
de
Alex Gaynor via dev-security-policy
writes:
>I'll take the opposite side: let's disallow it before it's use expands :-)
>P-521 isn't great, and there's really no value in proliferation of crypto
>algorithms, as someone told me: "Ciphersuites aren't pokemon, you shouldn't
>try to catch 'em all".
David Adrian via dev-security-policy
writes:
>I'd like to see either a reliable URL to fetch that can be converted to PEM
>(i.e. what Microsoft does), or some API you can hit to the store (e.g. what
>CT does).
PEM. You keep using that word... I do not think it means what you think it
does. Te
Peter Gutmann via dev-security-policy
writes:
>You keep using that word... I do not think it means what you think it does.
"... what you think it means". Dammit.
Peter.
___
dev-security-policy mailing list
dev-security-policy@list
Hanno Böck via dev-security-policy
writes:
>More dotdot-certificates:
Given how widespread (meaning from different CAs) these are, is there some
quirk of a widely-used resolver library that allows them? I've done a bit of
impromptu testing of various tools/bits of code but none of them seem to
Jeremy Rowley via dev-security-policy
writes:
>Today, DigiCert and Symantec announced that DigiCert is acquiring the
>Symantec CA assets, including the infrastructure, personnel, roots, and
>platforms.
I realise this is a bit off-topic for the list but someone has to bring up the
elephant in th
Peter Bowen writes:
>Gerv's email was clear that sale to DigiCert will not impact the plan,
>saying: "any change of control of some or all of Symantec's roots would not
>be grounds for a renegotiation of these dates."
>
>So the sanctions are still intact.
Ah, I phrased my question a bit unclearl
Matthew Hardeman via dev-security-policy
writes:
>One question: the choice of 20 bytes of serial number is an unusual length
>for an integer type. It's not a nice clean power of 2. It doesn't align to
>any native integer data type length on any platform I'm aware of.
It exactly matches the SH
Ryan Sleevi via dev-security-policy
writes:
>>Pragmatically, does anything known break on the extra byte there?
>
>Yes. NSS does. Because NSS properly implements 5280.
I would say that's probably more a flaw in NSS then. Does anyone's
implementation seriously expect things to work, and by exte
Matthew Hardeman via dev-security-policy
writes:
>I merely raise the point that IF the framers of the 20 bytes rule did, in
>fact, simultaneously intend that arbitrary SHA-1 hash results should be able
>to be stuffed into the serial number field AND SIMULTANEOUSLY that the DER
>encoded integer f
ramirommunoz--- via dev-security-policy
writes:
>1) How your CA first became aware of the problem
>Affected certificates
>Serial number:0d dates:15 Nov-2007 to 8-Nov-2032 Name:AC Camerfirma Express
>corporate Server(1)
>Serial number:0d dates:23 Feb-2010 to 20-Feb-2022 Name:AC Camerfirma AAPP(2
mw--- via dev-security-policy writes:
>So they sell multiple roots over to a company that is "the leader in Deep
>Packet Inspection (DPI) and we've got a lot going on in that space" and
>enable them to issue trusted certificates and mitm all encrypted connections
>with that? That is a good hallow
Rob Stradling via dev-security-policy
writes:
>CAs / Responder URLs that are in scope for, but violate, the BR prohibition
>on returning a signed a "Good" response for a random serial number
Isn't that perfectly valid? Despite the misleading name, OCSP's "Good" just
means "not revoked", and a
Tim Shirley via dev-security-policy
writes:
>But regardless of which (or neither) is true, the very fact that EV certs are
>rarely (never?) used on phishing sites
There's no need:
https://info.phishlabs.com/blog/quarter-phishing-attacks-hosted-https-domains
In particular, "the rate at which p
Matthew Hardeman via dev-security-policy
writes:
>In principle, I support Mr. Sleevi's position, practically I lean toward Mr.
>Thayer's and Mr. Hollebeek's position.
I probably support at least one of those, if I can figure out who's been
quoted as saying what.
>Sitting on my desk are not les
101 - 118 of 118 matches
Mail list logo
