On Monday, November 7, 2016 at 4:38:53 PM UTC-8, Santhan Raj wrote:
> May be I'm missing it, but I don't see 8.7 (or at least the lines quoted
> above) requiring TCSC to be compliant with BR. I read it as TCSCs must adhere
> to the Issuing CA's CP and their own (TCSC's) CPS, adhereance towards wh
> Certificates that are capable of being used to issue new certificates MUST
> either be Technically Constrained in line with section 7.1.5 and audited in
> line with section 8.7 only, or Unconstrained and fully audited in line with
> all remaining requirements from this section
>
> Section 8.7
On Monday, October 24, 2016 at 6:09:50 PM UTC-7, Kathleen Wilson wrote:
> The security blog about Distrusting New WoSign and StartCom Certificates has
> been published:
>
> https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/
>
> Chinese translations of
On Monday, November 7, 2016 at 6:09:39 AM UTC-8, Gervase Markham wrote:
> Hi everyone,
>
> We would like to reinvigorate the process of developing the next version
> of Mozilla's root policy. Kathleen has been wrestling with it for some
> time now, but her time is limited and her tasks are many. O
On 7 November 2016 at 11:25, Ryan Sleevi wrote:
> On Monday, November 7, 2016 at 9:02:37 AM UTC-8, Gervase Markham wrote:
>> As in, their dishonesty would be carefully targetted and so not exposed
>> by this sort of coarse checking?
>
> (Continuing with Google/Chrome hat on, since I didn't make th
On Monday, November 7, 2016 at 9:02:37 AM UTC-8, Gervase Markham wrote:
> As in, their dishonesty would be carefully targetted and so not exposed
> by this sort of coarse checking?
(Continuing with Google/Chrome hat on, since I didn't make the previous reply
explicit)
Yes. An 'evil log' can prov
On Monday, 7 November 2016 13:53:31 UTC, Gervase Markham wrote:
> You mean EKU-constrained (e.g. to email, or OCSP only)?
I was thinking also of a pathlen constraint. Suppose I am able to cause an
automated system to issue me arbitrary SHA-1 signed certificates from a
particular CA, at least on
On 07/11/16 16:13, Ryan Sleevi wrote:
> Yes, particularly for logs that may be compelled to be dishonest for
> geopolitical reasons.
As in, their dishonesty would be carefully targetted and so not exposed
by this sort of coarse checking?
Gerv
___
dev-s
On Monday, November 7, 2016 at 1:59:31 AM UTC-8, Gervase Markham wrote:
> It is correct that there is not yet a plan for when Firefox might
> implement inclusion proof fetching.
>
> One thing I have been pondering is checking the honesty of logs via
> geographically distributed checks done by infr
On 07/11/16 15:34, Doug Beattie wrote:
> I'd prefer a requirement for long serial numbers over a total ban on
> SHA-1 Sub CAs. The BRs state 112 bits of entropy, so I'd recommend
> using that for non BR certificates (assuming client applications
> don't have issues with that).
Can you list some of
I'd prefer a requirement for long serial numbers over a total ban on SHA-1 Sub
CAs. The BRs state 112 bits of entropy, so I'd recommend using that for non BR
certificates (assuming client applications don't have issues with that).
Doug
-Original Message-
From: dev-security-policy
[mai
On 07/11/16 14:34, Kurt Roeckx wrote:
> In my experience, pointing to a specific section of the BRs causes
> problems because things are moved, renumbered and so on. Other changes
> in the document also point to specific sections.
The BRs now follow RFC 3647, which AIUI specifies the title and
num
On 2016-11-07 15:08, Gervase Markham wrote:
https://github.com/mozilla/pkipolicy/compare/2.2...master
So one of the changes is that you now have:
-issuing certificates), as described in [CA/Browser Forum
-Baseline Requirement
-\#12;](http://www.cabforum.org/documents.htm
On Monday, 7 November 2016 13:11:50 UTC, Phillip Hallam-Baker wrote:
> None of the current browser versions support SHA-1. Yes, people could in
> theory turn it back on for some browsers but that isn't an argument because
> the same people can edit their root store themselves as well. Yes people
>
Hi everyone,
We would like to reinvigorate the process of developing the next version
of Mozilla's root policy. Kathleen has been wrestling with it for some
time now, but her time is limited and her tasks are many. Other
obstructions include the "big bang" model of change we were using, the
lack o
On 07/11/16 13:11, Phillip Hallam-Baker wrote:
> Not long after I was sitting in a conference at NIST listening to a talk on
> how shutting down DigiNotar had shut down the port of Amsterdam and left
> meat rotting on the quays etc. Ooops.
Sounds like someone got a lesson in single points of failu
On 07/11/16 10:52, Nick Lamb wrote:
> Where we don't have another way forward, I think one option is for
> CAs to replace an existing unconstrained intermediate with a newer
> one that is suitably constrained, and revoke the old one. This is
> subject to all the usual caveats about revocation and o
Remember the DigiNotar incident? At the time, I thought that pulling the
DigiNotar roots was exactly the right thing to do. I didn't say so as it
isn't proper for people to be suggesting putting their competitors out of
business. But I thought it the right thing to do.
Not long after I was sitting
On Monday, November 7, 2016 at 10:46:32 AM UTC+2, Rami Kogan wrote:
> Just came across the following Phishing site which is using a StartCom cert:
>
> serviices-intl[.]com
Did you contact them, if you did, what was their reply? It's better to contact
the CA first, and only if issues arouse then
On Monday, 7 November 2016 09:53:37 UTC, Gervase Markham wrote:
> One option would be to say that there should be no signing of SHA-1
> hashes in any circumstances within the hierarchies which chain up to
> Mozilla-trusted roots. However, it's possible that such a total ban
> would have disproport
On 05/11/16 13:49, Ryan Sleevi wrote:
> As noted elsewhere, the issuance of SHA-1 allows for an attacker to
> pivot the contents of the certificates, and the only mitigation is
> the EKU on the sub-CA.
>
> Are you suggesting this is GA because it wasn't clear enough to CA
> members at the time thi
On 05/11/16 19:33, Ryan Sleevi wrote:
> My understanding was that Mozilla's implementation status was similar
> to Chrome's a year ago - that is, that it doesn't implement inclusion
> proof fetching (in the background) and that work hadn't been
> scheduled/slated yet. In that case, it's a question
It has been noted that currently, Mozilla's SHA-1 ban is implemented via
the ban in the BRs, which we require all CAs to adhere to. At the
moment, Mozilla policy simply says:
"We consider the following algorithms and key sizes to be acceptable and
supported in Mozilla products:
SHA-1 (until a
Just came across the following Phishing site which is using a StartCom cert:
hXXps://serviices-intl.com/webapps/6fa9b/websrc
On 11/2/16, 6:32 PM, "dev-security-policy on behalf of Itzhak Daniel"
wrote:
>On Wednesday, November 2, 2016 at 5:22:30 PM UTC+2, Gervase Markham wrote:
>> Hi Dani
24 matches
Mail list logo
