Right. It is then.
It says private keys can only be stored with permission of the subscriber and
encryption must always be used to transfer them. And of course the certificate
must be revoked if/when it becomes known that a private key has gotten to the
wrong person.
Well... NOT my private key
On 29/03/17 20:42, Jakob Bohm wrote:
> That goal would be equally (in fact better) served by new market
> entrants getting cross-signed by incumbents, like Let's encrypt did.
Google will be issuing from Google-branded intermediates under the
ex-GlobalSign roots. So the chains would be basically th
On 29/03/17 20:46, Peter Kurrasch wrote:
> It's not inconsequential for Google to say: "From now on, nobody can
> trust what you see in the root certificate, even if some of it
> appears in the browser UI. The only way you can actually establish
> trust is to do frequent, possibly complicated resea
On Wed, Mar 29, 2017 at 7:30 AM, Hector Martin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> We actually have *five* levels of trust here:
>
> 1. HTTP
> 2. HTTPS with no validation (self-signed or anonymous ciphersuite)
> 3. HTTPS with DV
> 4. HTTPS with OV
> 5. HTTPS w
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf
Section 6.1.2
On Wed, Mar 29, 2017 at 3:22 AM, okaphone.elektronika--- via
dev-security-policy wrote:
> Weird.
>
> I expect there are no requirements for a CA to keep other people's private
> keys safe. After all handling tho
> Not for those sorts of differences. There are in an IDN context:
> http://unicode.org/reports/tr39/
wasn't aware of that TS, thanks!
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-secur
On Wednesday, March 29, 2017 at 2:00:05 PM UTC-7, Jeremy Rowley wrote:
> ...
> An extension on this could be to have CAs annually file an updated mapping
> with their WebTrust audit. That way it's a reminder that the CA needs to
> notify Mozilla of changes in their process and keeps the CAs thinkin
On 29/03/2017 20:52, Alex Gaynor wrote:
I don't think it's a good idea to design our system around the idea of
"What would a user be looking for if they read the cert chain manually".
For example, in the US, if such a government agency chose to use a
Government CA (as a user might reasonably expe
Hi Kathleen,
This is a good idea, and I like the phased-in approach. The mapping exercise
is similar to how other communities evaluate inclusion requests and makes it
more apparent how the CA is complying with the various Mozilla requirements.
An extension on this could be to have CAs annually fi
I don't think it's a good idea to design our system around the idea of
"What would a user be looking for if they read the cert chain manually".
For example, in the US, if such a government agency chose to use a
Government CA (as a user might reasonably expect!), their users would all
get cert warni
I'm not so sure I want to optimize the system in that way, but I am concerned
about the (un)intended consequences of rapidly changing root ownership on the
global PKI.
It's not inconsequential for Google to say: "From now on, nobody can trust what
you see in the root certificate, even if some o
On 29/03/2017 16:47, Gervase Markham wrote:
On 29/03/17 15:35, Peter Kurrasch wrote:
In other words, what used to be a trust anchor is now no better at
establishing trust than the end-entity cert one is trying to validate or
investigate (for example, in a forensic context) in the first place. I
All,
As mentioned in the GDCA discussion[1], I would like to add a step to Mozilla's
CA Inclusion/Update Request Process[2] in which the CA performs a
self-assessment about their compliance with the CA/Browser Forum's Baseline
Requirements.
A draft of this new step is here:
https://wiki.mozill
All,
This request is to include the "GDCA TrustAUTH R5 ROOT" certificate, turn on
the Websites trust bit, and enabled EV treatment.
In order to help get this discussion moving again, I asked GDCA to provide a
side-by-side comparison of the latest version of the BRs with their CP/CPS
documents.
On 29/03/17 15:35, Peter Kurrasch wrote:
> In other words, what used to be a trust anchor is now no better at
> establishing trust than the end-entity cert one is trying to validate or
> investigate (for example, in a forensic context) in the first place. I
> hardly think this redefinition of trust
(Renaming the thread to fork this particular discussion from any others on this transaction.)You raise a fair point, Ryan‎: I'm not well versed in how Let's Encrypt went about establishing their roots. I thought I
* Nick Lamb via dev-security-policy:
> In order for Symantec to reveal anybody's private keys they'd first
> need to have those keys, which is already, IIRC forbidden in the
> BRs.
I think this requirement was dropped because it makes it unnecessarily
difficult to report key compromises. There u
On 28/03/17 08:23, Peter Gutmann via dev-security-policy wrote:
Martin Heaps via dev-security-policy
writes:
This topic is frustrating in that there seems to be a wide attempt by people
to use one form of authentication (DV TLS) to verify another form of
authentication (EV TLS).
The overall
Weird.
I expect there are no requirements for a CA to keep other people's private keys
safe. After all handling those is definitely not part of being a CA. ;-)
CU Hans
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://l
19 matches
Mail list logo
