On Wed, Dec 13, 2017 at 4:46 PM, Tim Shirley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> As I understand it, Adam’s argument there was that to get value out of a
> revoked certificate, you need to be between the user and the web server so
> you can direct the traffic
On Wed, Dec 13, 2017 at 4:40 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Tuesday, December 12, 2017 at 3:52:40 PM UTC-6, Ryan Sleevi wrote:
>
> > Yes. This is the foundation and limit of Web Security.
> >
> > http
On Wed, Dec 13, 2017 at 4:28 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Wednesday, December 13, 2017 at 2:46:10 PM UTC-6, Gervase Markham wrote:
>
> > My concern with this argument is that it's susceptible to the criticism
> > that Adam Langle
On Wed, Dec 13, 2017 at 4:14 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Monday, December 11, 2017 at 6:01:25 PM UTC-6, Ryan Sleevi wrote:
>
> > > Not really - what matters is that the user insists they got had via a
&
On Wed, Dec 13, 2017 at 3:50 PM, Tim Shirley wrote:
> I’m not looking for a guarantee. Nothing is ever going to meet that
> standard. What I’m looking for is something that’s going to improve my
> odds. What I see in Ian’s and James’s research is some ways that it’s
> possible to create confus
s in the CA business, so if
> I was “conditioned” it must have been by the outside world. ☺
>
>
>
> *From: *Ryan Sleevi
> *Reply-To: *"r...@sleevi.com"
> *Date: *Wednesday, December 13, 2017 at 1:18 PM
> *To: *Tim Shirley
> *Cc: *Nick Lamb , "dev-security-p
On Wed, Dec 13, 2017 at 1:24 PM, Matthew Hardeman
wrote:
> As I pointed out, it can be demonstrated that quality ECDHE exchanges can
> happen assuming a stateful DPRNG with a decent starting entropy corpus.
>
Agreed - but that's also true for the devices Tim is mentioning.
Which I guess is the
On Wed, Dec 13, 2017 at 1:19 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I would be sorely disappointed
Prepare to be sorely disappointed
> and consider it a security bug
It is not a bug. It is not part of the security boundary of the Web, thus
W
On Wed, Dec 13, 2017 at 12:58 PM, Tim Shirley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> As an employee of a CA, I’m sure many here will dismiss my point of view
> as self-serving. But when I am making trust decisions on the internet, I
> absolutely rely on both the
would be shocked
> if we’ve seen the last major security breach based on poor RSA key
> generation by resource constrained devices.
>
>
>
> Given that there exist IETF approved alternatives that could help with
> that problem, they’re worth considering. I’ve been spending a lot of time
On Wed, Dec 13, 2017 at 11:06 AM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Wayne,
>
> For TLS/SSL certificates, I think PKCS #12 delivery of the key and
> certificate
> at the same time should be allowed, and I have no problem with a
> requirement
>
On Wed, Dec 13, 2017 at 6:29 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> > Yes. This is the foundation and limit of Web Security.
> >
> > https://en.wikipedia.org/wiki/Same-origin_policy
> >
> > This is what is programatically enforced. Anything else e
On Tue, Dec 12, 2017 at 3:44 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> What you are writing below, with far too many words is that you think
> that URLs are the only identities that matter in this world, and
> therefore DV certificates are enough secu
On Tue, Dec 12, 2017 at 1:11 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> The overall thing is that the current thread seems to be a major case of
> throwing the baby out with the bathwater.
>
That is overly reductive and may demonstrate a lack of unde
On Tue, Dec 12, 2017 at 8:36 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 12/12/2017 01:08, Adam Caudill wrote:
>
>> Even if it is, someone filed the paperwork. Court houses have clerks,
> guards, video cameras, etc... It still may present a rea
On Tue, Dec 12, 2017 at 10:18 AM, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> > The implemented controls detected the misconfiguration within 24
> > hours. The incorrect configuration was nevertheless recorded as a
> > security incident. The handling of the
No. It has been prohibited for years in the Baseline Requirements. With an
expectation that CAs monitor such requests in light of DigiNotar
On Mon, Dec 11, 2017 at 8:54 PM Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Rob Stradling via dev-security-policy
On Mon, Dec 11, 2017 at 6:46 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Monday, December 11, 2017 at 5:00:14 PM UTC-6, Ryan Sleevi wrote:
> > > That Kentucky registration for Stripe, Inc. -- Is it completely
> f
On Mon, Dec 11, 2017 at 6:31 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> What I dislike about this particular rationale is that I presupposes we
> should architect web security such as to avoid enhancements which have
> value to anyone the least co
On Monday, December 11, 2017 at 5:47:50 PM UTC-5, Matthew Hardeman wrote:
> While I understand that it may formally be beyond the scope formally to
> consider this in discussion with EV UI handling, I think some consideration
> to ecosystem harm is appropriate here.
>
> If we eliminate EV UI, we h
On Monday, December 11, 2017 at 4:03:41 PM UTC-5, Matthew Hardeman wrote:
> I think it will be a difficult sell to remove EV certificate UI handling,
> as nothing is proposed to replace it.
I think this is flawed. If EV doesn't provide value, and adds confusion, it
absolutely should go, and doesn
On Monday, December 11, 2017 at 4:01:21 PM UTC-5, Paul Wouters wrote:
> On Mon, 11 Dec 2017, Ryan Hurst via dev-security-policy wrote:
>
> > The issues with EV are much larger than UI. It needs to be revisited and a
> > honest and achievable set of goals need to be established and the processes
On Mon, Dec 11, 2017 at 3:43 PM, Matthew Hardeman
wrote:
> I don't denigrate the recent work done. Not at all.
>
> This "exploit" is long known to those in the know.
>
> My key objection is that there needs to be a way to validate that the
> brick and mortar bank you've done business with for ye
On Mon, Dec 11, 2017 at 3:12 PM, Tim Hollebeek
wrote:
>
>
> On the contrary, everything needs to be improved with time. Just because
> it could be made better doesn’t make it useless or bad.
>
>
>
> -Tim
>
I didn't say that its ability to be improved made it bad - merely, its
present state is b
On Mon, Dec 11, 2017 at 3:06 PM, Matthew Hardeman
wrote:
>
> The EV guidelines already encompass this information - the jurisdiction
>> fields, combined with the serialNumber, which is the unique identifying
>> number for that entity within the jurisdictional registry, which is unique
>> per juris
On Mon, Dec 11, 2017 at 2:50 PM, Tim Hollebeek
wrote:
>
>
> Certainly, as you noted, one option is to improve EV beyond simply being
> an assertion of legal existence.
>
Does this mean we're in agreement that EV doesn't provide value to justify
the UI then? ;-)
I say it loaded and facetiously,
ver, that seems
exceptionally user-hostile and to ignore countless research studies, so
another option would be to consider removing the (unqualified) legal
identity from the address bar.
>
> -Original Message-
> From: Jonathan Rudenberg [mailto:jonat...@titanous.com]
> Sent: Mond
On Mon, Dec 11, 2017 at 2:31 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> (Reposting as I accidentally replied directly to OP ).
>
> Part of this discussion will necessarily have to include who the intended
> and potential beneficiaries of EV certi
On Mon, Dec 11, 2017 at 2:23 PM, Paul Wouters via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Mon, 11 Dec 2017, Ryan Sleevi via dev-security-policy wrote:
>
> I suppose this is both a question for policy and for Mozilla - given the
>> ability to
On Mon, Dec 11, 2017 at 2:14 PM, Tim Hollebeek
wrote:
>
> It turns out that the CA/Browser Validation working group is currently
> looking into how to address these issues, in order to tighten up validation
> in these cases. We discussed it a bit last Thursday, and will be
> continuing
> the dis
Recently, researchers have been looking into the value proposition of EV
certificates, and more importantly, how easy it is to obtain certificates that
may confuse or mislead users - a purpose that EV is supposedly intended to
avoid.
James Burton was able to obtain a certificate for "Identity V
On Mon, Dec 4, 2017 at 8:37 PM, J.C. Jones via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> All,
>
> Just an interesting heads up:
>
> While we were doing some maintenance on the CCADB, Chris Henderson found
> Golang could not process several of Wells Fargo's intermediate
On Fri, Dec 1, 2017 at 12:34 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 01/12/2017 17:06, Ryan Sleevi wrote:
>
>> On Fri, Dec 1, 2017 at 10:33 AM, Jakob Bohm via dev-security-policy <
>> dev-security-poli
On Fri, Dec 1, 2017 at 11:20 AM, Hubert Kario wrote:
> On Friday, 1 December 2017 17:11:56 CET Ryan Sleevi wrote:
> > On Fri, Dec 1, 2017 at 10:23 AM, Hubert Kario wrote:
> > > and fine for NSS too, if that changes don't have to be implemented in
> next
> >
On Fri, Dec 1, 2017 at 10:23 AM, Hubert Kario wrote:
>
> > - Windows and NSS both apply DER-like BER parsers and do not strictly
> > reject (Postel's principle, despite Postel-was-wrong)
>
> NSS did till very recently reject them, OpenSSL 1.0.2 still rejects them
> (probably even 1.1.0), are you
On Fri, Dec 1, 2017 at 10:33 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Depending on the prevalence of non-public CAs (not listed in public
> indexes) based on openssl (this would be a smallish company thing more
> than a big enterprise thing), it mig
On Fri, Dec 1, 2017 at 7:34 AM, Hubert Kario wrote:
> > It does feel like again the argument is The CA/EE should say 'I won't do
> X'
> > so that a client won't accept a signature if the CA does X, except it
> > doesn't change the security properties at all if the CA/EE does actually
> do
> > X,
Right, and to my point:
Each transparency mechanism has to be specific to the problem it's trying
to solve. CT is not a magic cureall for transparency - it's specific to,
well, certificates, and more generally, TLS web certificates.
For things like S/MIME, you have "Key Transparency" (based on CO
On Thu, Nov 30, 2017 at 3:12 PM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> The problem DNSSEC checks for CAA was intended to solve was the fact that
> it
> is certainly possible that a well-resourced attacker can manipulate the DNS
> responses that the
On Thu, Nov 30, 2017 at 3:23 PM, Hubert Kario wrote:
> On Thursday, 30 November 2017 18:46:12 CET Ryan Sleevi wrote:
> > On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario
> wrote:
> > > if the certificate is usable with PKCS#1 v1.5 signatures, it makes it
> > >
On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario wrote:
> if the certificate is usable with PKCS#1 v1.5 signatures, it makes it
> vulnerable to attacks like the Bleichenbacher, if it is not usable with
> PKCS#1
> v1.5 it's not vulnerable in practice to such attacks
>
A certificate does not produce
On Thu, Nov 30, 2017 at 4:02 AM, Quirin Scheitle via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Similar to the GlobalSign discussion, it is well possible that the domain
> briefly disabled their CAA records when you did the check — and re-enabled
> them later.
>
I think
On Wed, Nov 29, 2017 at 1:09 PM, Hubert Kario wrote:
> > The extent of the argument for flexibility, so far, has been OpenSSL's
> > behaviour to produce RSA-PSS signatures with a maximal salt length. These
> > same clients are also incapable of parsing RSA-PSS SPKIs (that only came
> > recently,
On Wed, Nov 29, 2017 at 7:55 AM, Hubert Kario via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
>
> > The fact that this new NSS implementation does not properly validate the
> > well-formedness of these signatures is somewhat in conflict with your
> > statement:
> > ""it tu
On Tue, Nov 28, 2017 at 8:04 AM, Hubert Kario wrote:
> On Monday, 27 November 2017 23:37:59 CET Ryan Sleevi wrote:
> > On Mon, Nov 27, 2017 at 4:51 PM, Hubert Kario wrote:
> > > > So no, we should not assume well-meaning actors, and we should be
> > >
> > >
On Mon, Nov 27, 2017 at 8:29 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 27/11/2017 19:37, Nick Lamb wrote:
>
>> On Fri, 24 Nov 2017 12:25:40 +
>> Gervase Markham via dev-security-policy
>> wrote:
>>
>> Validate example.com -> add "www.example.c
On Mon, Nov 27, 2017 at 4:51 PM, Hubert Kario wrote:
>
> > First, I absolutely disagree with your assumption - we need to assume
> > hostility, and design our code and policies to be robust against that. I
> > should hope that was uncontroversial, but it doesn't seem to be.
>
> my point was that t
On Mon, Nov 27, 2017 at 12:54 PM, Hubert Kario wrote:
>
> > On the realm of CA policy, we're discussing two matters:
> > 1) What should the certificates a CA issue be encoded as
> > 2) How should the CA protect and use its private key.
> >
> > While it may not be immediately obvious, both your pro
On Thu, Nov 23, 2017 at 7:07 AM, Hubert Kario via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> In response to comment made by Gervase Markham[1], pointing out that
> Mozilla
> doesn't have an official RSA-PSS usage policy.
>
> This is the thread to discuss it and make a pr
On Wed, Nov 22, 2017 at 12:24 PM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 22/11/17 17:03, Matthew Hardeman wrote:
> > approval in terms of community buy-in. The downside, of course, is that
> > while this alternative pre-discussion allows for d
On Wed, Nov 22, 2017 at 11:16 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Mozilla did not formally require this, but it is true that as far as we
>> can see, Richard Wang is still effectively in charge of WoSign/WoTrus.
>>
>>
> I think assessing and di
is being called OneCRL
> is the "certItems" part of https://hg.mozilla.org/
> mozilla-central/file/tip/browser/app/blocklist.xml? And the link which
> provides the JSON file (which I included in my message before) is derived
> from the blocklist XML?
>
> 2017-11-07 14:47 G
Note that additions and removals are made in OneCRL relate to the behaviour
of mozilla::pkix and the trust lists expressed by the associated version of
NSS shipping with the supported versions of Firefox.
For example, this includes revocation of 'email only' CAs (that are not
appropriately constra
On Mon, Nov 6, 2017 at 6:34 AM, Fotis Loukos via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 04/11/2017 02:36 μμ, Daniel Cater via dev-security-policy wrote:
> > I notice that on https://crt.sh/mozilla-onecrl there are lots of
> certificates that have recently been add
Neither CAA nor DNSSEC mitigate registry compromises.
On Sun, Nov 5, 2017 at 9:15 AM Daniel Cater via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hmm, CAA records could also potentially be spoofed in this situation, in
> which case they would also not be trustworthy (sav
On Tue, Oct 31, 2017 at 5:29 PM, Dimitris Zacharopoulos via
dev-security-policy wrote:
>
> I don't believe your statement is supported by the evidence - which is why
>> I'm pushing you to provide precise references. Consider from the
>> perspective as a consumer of such audits - there is zero awar
On Tue, Oct 31, 2017 at 3:44 PM, Peter Kurrasch via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Both articles are long on names, short on dates. I don't fault the authors
> for that but it is troubling that better information wasn't made available
> to them.
>
> When can
You didn't really leave room for productive discussion between your
options, did you? :)
As you can see from
https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md#8-ca-operational-changes
, notification is required for certain changes - but that notification goes
to a Mozilla mail a
On Tue, Oct 31, 2017 at 8:34 AM, Dimitris Zacharopoulos via
dev-security-policy wrote:
>
> Do you believe that the requirements stated in the policy are unclear? That
>> is, as Kathleen mentioned, the Mozilla policy states all the information
>> that must be present, as a template of what needs to
On Tue, Oct 31, 2017 at 5:21 AM Dimitris Zacharopoulos via
dev-security-policy wrote:
>
> It is not the first time this issue is brought up. While I have a very
> firm opinion that ETSI auditors under the ISO 17065 (focused on the
> quality of products/services) and ETSI EN 319 403 definitely che
On Mon, Oct 30, 2017 at 5:50 PM, Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> To give us a concrete example, here's a Bugzilla Bug that I filed this
> morning:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1412950
>
> The CA's 2015-2016 audit was Web
On Mon, Oct 30, 2017 at 5:39 PM, Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > Importantly,
> > within 17065 and 17021, the way of ensuring continued compliance is done
> > based on contracts and reporting - that is, the client is responsible for
> > r
On Mon, Oct 30, 2017 at 3:50 PM, Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> How do we get all auditors to start meeting our audit statement
> requirements?
>
> Why haven't all included CAs communicated these requirements to their
> auditors?
>
> Why
Without commenting on the Symantec aspect of this, there is a rather
substantial correction to the behaviour of client software - including
Firefox.
Unfortunately, very few libraries and path validators support chain
building terminating at trust anchors in the way you describe. Recent
changes in
On Tue, Oct 24, 2017 at 12:28 PM, Daymion Reynolds via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Godaddy LLC first became aware of possible ROCA vulnerability exposure on
> Monday October 16th 2017 at 9:30am. The following are the steps we took for
> detection, revocati
I think this would be of great benefit to the community.
1) It provides meaningful opportunity to ensure that the Mozilla-specific
program requirements are being met. The spate of misissuances discussed in
the past few months have revealed an unfortunately common trend of CAs not
staying aware of
On Tue, Oct 17, 2017 at 5:06 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 16/10/17 20:22, Peter Bowen wrote:
> > Will the new managed CAs, which will operated by DigiCert under
> > CP/CPS/Audit independent from the current Symantec ones, also be
ntil the pin expires. If pins last up to a year, customers
> issuing a cert after June 2016 should have time to migrate prior to root
> removal. One issue is that these customers won’t be able to get a new cert
> that functions off the old intermediate post Dec 1, 2017, effectively
> meanin
Hi Kathleen,
With respect to providing a list - is there any requirement to ensure
Mozilla accepts that as a reasonable remediation?
For example, would "We plan to not do the same in the future" be an
acceptable remediation plan? As currently worded, it would seem to meet the
letter of this requi
On Mon, Oct 2, 2017 at 10:42 AM, Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Friday, September 29, 2017 at 2:52:49 PM UTC-7, Eric Mill wrote:
> > That dynamic is natural, but accepting that this dynamic exists is
> > different than giving into it in
On Sun, Sep 24, 2017 at 12:40 PM, Peter Bowen wrote:
>
> I agree that 3b potentially has a higher risk than 3z, but it has a
> higher reward. 3b allows pins to continue to work even if the trust
> store removes 3. It comes down to the level of protection of the root
> key. If it is secure, then
On Fri, Sep 22, 2017 at 1:00 PM, Peter Bowen via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Ryan,
>
> As an existing Symantec customer, I'm not clear that this really
> addresses the challenges we face.
>
> So far we have found several different failure modes. We hope
n.
>
>
>
> If the agreement closes prior to Dec 1, the Managed CA will never exist.
> Instead, all issuance will occur through one of the three primary DigiCert
> roots mentioned above with the exception of customers required to use a
> Symantec root for certain platforms or p
Hi Gerv,
Based on the number of reports reviewed recently, I suspect we've got
opportunities for improvement, but I'm not quite sure yet what the concrete
suggestions on that should look like. A few thoughts below:
- The current report format biases itself towards "misissuance", when we
know ther
On Tue, Sep 19, 2017 at 10:49 PM, userwithuid via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Either way, in the specific case, StartCom, this criticism seems to be
> inapplicable, as the revoked one was never deployed in the first place.
I don't think that's a fair con
-policy
> [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Sunday, September 17, 2017 7:57 PM
> To: userwithuid
> Cc: mozilla-dev-security-policy
>
> Subject: Re: Old roots to new roots best practi
On Mon, Sep 18, 2017 at 8:12 AM, Inigo Barreira
wrote:
>
> We are not seeking to identify personal blame. We are seeking to
> understand what, if any, improvements have been made to address such
> issues. In reading this thread, I have difficulty finding any discussion
> about the steps that Start
Hi there,
I agree, Gerv's remarks are a bit confusing with respect to the concern.
You are correct that the process of establishing a new root generally
involves the creation of a self-signed certificate, and then any
cross-signing that happens conceptually creates an 'intermediate' - so you
have
On Fri, Sep 15, 2017 at 12:30 PM, Inigo Barreira via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> >
> > Hi Inigo,
> >
> > On 14/09/17 16:05, Inigo Barreira wrote:
> > > Those tests were done to check the CT behaviour, there was any other
> > testing of the new systems, jus
On Wed, Aug 2, 2017 at 5:12 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi everyone,
>
>
>
> Today, DigiCert and Symantec announced that DigiCert is acquiring the
> Symantec CA assets, including the infrastructure, personnel, roots, and
> platforms.
On Mon, Sep 11, 2017 at 3:09 PM Jonathan Rudenberg via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> > On Sep 11, 2017, at 17:41, Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> >
That seems like very poor logic and justification.
Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for
literally years now, perhaps it's worth asking why CAs are only now
discovering issues. That is, is the only reason we're discovering issues
because CAs waited for the last p
On Fri, Sep 8, 2017 at 2:39 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 07/09/2017 17:17, Gervase Markham wrote:
>
>> Mozilla has decided that there is sufficient concern about the
>> activities and operations of the CA "PROCERT" to collect together
On Thu, Sep 7, 2017 at 5:22 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 07/09/2017 21:00, Ryan Sleevi wrote:
>
Then there is your suggestion of requiring technically constrained
>>
>>> SubCAs (that were constrained under
On Thu, Sep 7, 2017 at 11:17 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Mozilla has decided that there is sufficient concern about the
> activities and operations of the CA "PROCERT" to collect together our
> list of current concerns. That list ca
On Thu, Sep 7, 2017 at 1:20 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> All but one of your suggestions would require the revocation of existing
> SubCA certificates, essentially invalidating all existing uses of
> certificates issued by those SubCAs (E
On Fri, Sep 1, 2017 at 2:07 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> RFC2818 postdates real world https by several years. The original de
> facto standard by Netscape/Mozilla used the commonName semantics, which
> survived for more than a decade in
On Thu, Aug 31, 2017 at 5:21 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 31/08/2017 22:26, Ryan Sleevi wrote:
>
>> Agreed. But in general, in order to maintain interoperability, there's a
>> process for building consensu
On Thu, Aug 31, 2017 at 4:13 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I am aware that this was the original specification. However like many
> other parts of PKIX it may not be as good in 20/20 hindsight.
Agreed. But in general, in order to mainta
On Thu, Aug 31, 2017 at 8:18 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Would it be beneficial to Mozilla in particular and the larger PKI
> community in general if the following was added to implementations:
>
Hi Jakob,
This was rather extensively d
On Tue, Aug 29, 2017 at 8:47 AM, Paul Kehrer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Symantec / GeoTrust
>
> CCADB does not list an email address. Not CC'd.
>
> DN: C=IT, O=UniCredit S.p.A., CN=UniCredit Subordinate External
> Example cert:
> https://crt.sh/?q=04
On Tue, Aug 22, 2017 at 12:01 PM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 21/08/17 06:20, Peter Kurrasch wrote:
> > The CA should decide what makes the most sense for their particular
> > situation, but I think they should be able to provide as
On Sun, Aug 20, 2017 at 3:44 PM, Peter Bowen wrote:
> From the perspective of being "clean" from a given NSS version this,
> makes sense. However the reality for most situations is there is
> demand to support applications and devices with trust stores that have
> not been updated for a while.
On Fri, Aug 18, 2017 at 11:02 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Sometimes, CAs apply for inclusion with new, clean roots. Other times,
> CAs apply to include roots which already have a history of issuance. The
> previous certs issued by t
state thar any cert with
> no equipment, sever Auth, or anyEKU is considered a BR cert regardless of
> other content.
>
> On Aug 18, 2017, at 8:26 AM, Ryan Sleevi vb wrote:
>
> Do you believe https://github.com/mozilla/pkipolicy/blob/master/
> rootstore/policy.md#11-scope is ambiguou
Do you believe
https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md#11-scope
is ambiguous in this context? That is what is referenced in the text.
It sounds as if you're suggesting they're in scope, via 1.1, but that
they're out of scope, because the policy does not state that (id-
On Fri, Aug 18, 2017 at 1:34 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Since QuoVadis has not yet responded, let me point to a few (partial)
> answers already known from previous messages from QuoVadis or others:
I believe it would be far more produc
On Tue, Aug 15, 2017 at 4:01 PM, Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Tuesday, August 15, 2017 at 12:46:36 PM UTC-7, Ryan Sleevi wrote:
> >
> > The requirement for revocation comes from the Baseline Requirements.
>
On Tue, Aug 15, 2017 at 3:37 PM, Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I do *NOT* necessarily expect the CAs to revoke all of these certificates.
> I expect the CAs to do a careful analysis of the situation and
> determine/explain whether or not
On Tuesday, August 15, 2017 at 10:34:27 AM UTC-4, Gervase Markham wrote:
> On 15/08/17 13:59, Ryan Sleevi wrote:
> > Note: adding to certdata.txt, at present, will have various undesirable
> > side-effects:
> >
> > - Distrust records, without associated certs,
801 - 900 of 1416 matches
Mail list logo
