Matthew Hardeman wrote:
> On Wednesday, December 13, 2017 at 5:52:16 PM UTC-6, Peter Gutmann wrote:
>> In all of these cases, the device is going to be a safer place to generate
>> keys than the CA, in particular because (a) the CA is another embedded
>> controller somewhere so probably no better t
Peter Gutmann wrote:
> Ryan Sleevi writes:
>
>> What is the goal of the root program? Should there be a higher bar for
>> removing CAs than adding them? Does trust increase or decrease over time?
>
> Another thing I'd like to bring up is the absolute silence of the CAB forum
> over all this. Ap
Gervase Markham wrote:
> On 07/10/16 04:21, Peter Gutmann wrote:
>> That still doesn't necessarily answer the question, Google have their CRLSets
>> but they're more ineffective than effective in dealing with revocations
>> (according to GRC, they're 98% ineffective,
>> https://www.grc.com/revocati
Dean Coclin wrote:
> First Data's customers don't use browsers so Firefox can disable SHA-1
> tomorrow
> and not affect them.
So why to have your CA certificate trusted in Firefox's cert DB?
> First Data has asked for a reasonable extension which doesn't affect browsers.
If it does not "affect
Peter Gutmann wrote:
> Rob Stradling writes:
>
>> Easy. It doesn't make a sound. Unrevoked certificates don't make sounds
>> either.
>
> What I was really asking, in a tongue-in-cheek way, was whether there was any
> indication of how successfully the information could be propagated to
> brows
Hanno Böck wrote:
> On Mon, 29 Feb 2016 10:18:01 +0100
> Jürgen Brauckmann wrote:
>
>> Using private PKIs for such stuff isn't risk-free, as software
>> vendors are confused about the security properties of their root
>> store.
>
> Actually I also thought while reading this thread that I disagre
Peter Gutmann wrote:
> AnilG writes:
>
>> This is really big picture here: I've looked up and suddenly seen Firefox
>> market share trajectory looking like we need some steering input fast. This
>> is a 3 to 6 year picture of decline so it will take as long to correct.
>
> Oh dear, this is reall
Peter Bowen wrote:
On Sun, Mar 22, 2015 at 4:18 PM, Kathleen Wilson wrote:
admin@domain
administrator@domain
webmaster@domain
hostmaster@domain
postmaster@domain
What do you all think?
(Note this is also in Baseline Requirements section 11.1.1)
It is hard to know wh
Ryan Sleevi wrote:
> Given that sites in consideration already have multiple existing ways to
> mitigate these threats (among them, Certificate Transparency, Public Key
> Pinning, and CAA),
Any clients which already make use of CAA RRs in DNS?
Or did you mean something else with the acronym CAA?
Phillip Hallam-Baker wrote:
> Going back to this thread because nobody seems to have addressed the
> real issue - usability.
And no one addressed another real issue:
Bad software quality - especially regarding error handling.
If something goes wrong at TLS level (maybe with or without client cert
Gervase Markham wrote:
> A question which occurred to me, and I thought I'd put before an
> audience of the wise:
>
> * What advantages, if any, do client certs have over number-sequence
> widgets such as e.g. the HSBC Secure Key, used with SSL?
>
> http://www.hsbc.co.uk/1/2/customer-support/on
John Nagle wrote:
> Did anyone go back and check to see if the people responsible for
> removing that feature from Mozilla were induced to do so by
> the NSA?
>
> That feature was removed before the Snowden disclosures.
> It's time to look at this again.
Especially OCSP is a privacy night
Erwann Abalea wrote:
> In the list, some root certificates belong to active certificate issuers
> (but with different roots), so there's little security risks (I believe an
> active issuer protects all its keys the same way).
Erwann, I think the opposite is true:
Given the fact that there were a b
Brian Smith wrote:
> I always thought that the CRL requirement was in there because long of go
> we expected that we'd eventually start fetching CRLs at some point, and
> then it was left in there due to inertia, mostly.
>
> Keep in mind that S/MIME and TLS have different requirements.
I really w
Kathleen Wilson wrote:
> In the case of EV certs, Mozilla is still checking the CRL when the OCSP URI
> is not provided.
Which CRL? Where does it come from?
> Though, I believe the plan is to stop checking CRL in the
> future...
> https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c34
> "Instead
Kathleen Wilson wrote:
>> And since CRL support was dropped in recent Firefox/Seamonkey
>> releases there's
>> no revocation checking mechanism for those certs at all.
>
> That's not technically accurate for EV certificates. The user interface to
> manually import CRLs was dropped, but CRLs are st
Kaspar Brand wrote:
> Another 10 days have passed without any apparent sign of Mozilla's
> willingness to address the case of the non-existence of an OCSP
> responder for the Cybertrust SureServer EV CA.
And since CRL support was dropped in recent Firefox/Seamonkey releases there's
no revocation c
17 matches
Mail list logo
