On Tue, May 17, 2016 at 01:04:28AM +, Charles Reiss wrote:
> On 05/16/16 12:22, Richard Z wrote:
> >On Sun, May 15, 2016 at 05:43:39PM -0700, Peter Bowen wrote:
> >
> >>Some CAs may choose to not issue to sites known to inject malware, but
> >>this outside the scope of the SSL requirements. Th
On Wednesday, 18 May 2016 22:58:54 UTC+1, Kathleen Wilson wrote:
> This request is still under discussion, so please continue to provide your
> input.
Andrew's question remains unanswered as far as I can see. When Symantec's
"technical controls" allow issuance of S/MIME certs "in this CA hierar
On Wed, May 18, 2016 at 03:16:59PM +0100, Gervase Markham wrote:
> > What is meant by "fraudulent use"?
>
> I think the bullet as a whole could mean that we reserve the right to
> not include CAs who happily issue certs to "www.paypalpayments.com" to
> just anyone without any checks or High Risk s
On Wed, May 18, 2016 at 04:35:49PM +, Ben Wilson wrote:
> Looking at the threat from a defense-in-depth/orthogonal perspective,
> doesn't it make sense that everyone -- browsers, ICANN, CAs, etc. -- does
> something to combat malicious websites for the public?
Because the next steps after "
Here is a summary of this discussion so far about Symantec's request to enable
EV treatment for the "VeriSign Class 3 Public Primary Certification Authority -
G4" root certificate that was included via bug #409235, and has all three trust
bits enabled.
1) The "Symantec AATL ECC Intermediate CA
On Wednesday, May 18, 2016 at 7:17:01 AM UTC-7, Rob Stradling wrote:
> The following intermediate certificate is not "technically constrained"
> according to the Policy. It contains id-kp-codeSigning, but does not
> "contain a directoryName permittedSubtrees constraint where each
> permittedSub
I would simply like to state that my views, and the views of Let's Encrypt, are
closely aligned with those already expressed here by Peter Bowen and Eric Mill.
I will add, since I don't think it has been made clear enough here already,
that violations of a CA's subscriber agreement can and shoul
On Wed, May 18, 2016 at 9:35 AM, Ben Wilson wrote:
> Looking at the threat from a defense-in-depth/orthogonal perspective,
> doesn't it make sense that everyone -- browsers, ICANN, CAs, etc. -- does
> something to combat malicious websites for the public?
>
It certainly could, and so far no on
Looking at the threat from a defense-in-depth/orthogonal perspective,
doesn't it make sense that everyone -- browsers, ICANN, CAs, etc. -- does
something to combat malicious websites for the public?
-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=dig
On Wednesday, 18 May 2016 16:22:39 UTC+1, Peter Bowen wrote:
> Given that there is already the ICANN UDRP, shouldn't that be the
> venue to decide who is authorized to have what domain names? Should
> CAs be responsible for making calls on who is authorized for a domain
> name?
The UDRP and the
This intermediate seems technically constrained for SSL and S/MIME
certificates, which are the only type of certs under the current Mozilla
policy. Having extra nameConstraints for this particular intermediate, seems to
be unnecessary, for the Mozilla root program.
DZ.
> On 18 Μαΐ 2016, at
On Wed, May 18, 2016 at 7:16 AM, Gervase Markham wrote:
> I think the bullet as a whole could mean that we reserve the right to
> not include CAs who happily issue certs to "www.paypalpayments.com" to
> just anyone without any checks or High Risk string list or anything.
> Such a cert, unless issu
On 17/05/16 22:41, Kathleen Wilson wrote:
> On Monday, May 16, 2016 at 9:20:56 AM UTC-7, Kathleen Wilson wrote:
>> I am wondering if the BRs need to be updated to:
>> + Define what is meant by "Certificate misuse, or other types of fraud".
>> (e.g. being used for a purpose outside of that containe
The following intermediate certificate is not "technically constrained"
according to the Policy. It contains id-kp-codeSigning, but does not
"contain a directoryName permittedSubtrees constraint where each
permittedSubtree contains the organizationName, localityName (where
relevant), stateOrPr
In the case of a DV certificate it's exactly what it says, validating
the ownership of a domain, and nothing more. While users _may believe_
that TLS is supposed to protect them from malware, hackers, or
'untrustworthy' sites in general _it is not_. TLS exists to encrypt the
connection between a cl
15 matches
Mail list logo
