Hi everyone,
We've now worked our way through all 21 issues which were scheduled for
Mozilla CA Policy 2.4. You can see the current text here:
https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md
https://github.com/mozilla/pkipolicy/blob/master/ccadb/policy.md
On 16/02/17 18:26, blake.mor...@trustis.com wrote:
> Trustis has now revoked the SHA-1 Certificate for hmrcset.trustis.com
> and replaced it with a SHA-256 Certificate. This status is reflected
> in the latest CRL.
Hi Blake,
We are pleased to hear that, but the detail of your report compares
On 13/02/17 23:53, Wayne Thayer wrote:
> Gerv - this makes sense and it is GoDaddy's intent to perform these steps
> within 3 months.
No significant objections have been put forward about this action plan,
and so I have filed a Bugzilla bug to track GoDaddy's implementation:
On 07/02/17 17:45, Gervase Markham wrote:
> We want to update the permitted algorithms and key sizes list.
Resolution: resolved as specced (using English descriptions rather than
AlgorithmIdentifiers).
Gerv
___
dev-security-policy mailing list
On 07/02/17 17:25, Gervase Markham wrote:
> Therefore, we would like to update Mozilla's CA policy to implement a
> "proper" SHA-1 ban.
Resolution: resolved pretty much as drafted.
Gerv
___
dev-security-policy mailing list
Hi Stephen,
On 16/02/17 18:37, Stephen Davidson wrote:
> Incident Report
Thank you for your prompt and detailed incident report. It seems to me
that this highlights the particular extra care that needs to be taken by
all CAs regarding manual issuances which do not use the normal software
into
On 24/02/17 07:08, blake.mor...@trustis.com wrote:
> Certificates for the HMRC SET Service are issued from the SHA-1 “FPS
> TT Issuing Authority”, which is now only used for this service. The
> replacement server certificate for hmrcset.trustis.com was issued
> from the FPS TT IA, via a manual
On 22/02/17 17:08, Richard Wang wrote:
> I think "apple-id-2.com" is a high risk domain that must be blocked to issue
> DV SSL to those domains.
I don't represent Let's Encrypt, but their policy on such things is
relevant to this discussion, and it is here:
On 22/02/17 14:42, Tony Zhaocheng Tan wrote:
> On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com.
> However, until today, the domain apple-id-2.com has apparently never
> been registered. How was the certificate issued?
On Hacker News, Josh Aas writes:
"Head of Let's Encrypt
On 13/02/17 14:34, Nick Lamb wrote:
> I don't think Ballot 169 represents best practices per se. Instead as
> with the rest of the Baseline Requirements what we have here are
> _minimums_, we aren't asking that CAs should do no more than what is
> described, but that they must do at least what is
On 13/02/17 16:41, Nick Lamb wrote:
> GoDaddy came up with). Thus, even though some of the methods from
> Ballot 169 are not included in the Baseline Requirements today,
> Mozilla intends to oblige root programme members to pick from those
> ten methods.
Yes. And this is permitted by the BRs
On 13/02/17 14:34, Doug Beattie wrote:
> This was for GlobalSign account used for testing, so it was a
> GlobalSIgn employee. Customers are not, nor have they ever been,
> permitted to add domains without GlobalSign enforcing the domain
> verification process.
OK, then I'm a bit confused. You
On 11/02/17 12:13, Peter Gutmann wrote:
> Is no-one at Mozilla able to explain why they did this? It's a nontrivial
> piece of code to implement, surely someone must know what the thinking was
> behind doing it this way?
Peter: you are going to have to re-summarise your question. And then, if
On 10/02/17 06:15, Richard Wang wrote:
> I think Mozilla should have a very clear policy for:
> (1) If a company that not a public trusted CA acquired a trusted root key,
> what the company must do?
> (2) If a company is a public trusted CA that acquired a trusted root key,
> what the company
On 09/02/17 14:32, Gijs Kruitbosch wrote:
> Would Mozilla's root program consider changing this requirement so that
> it *does* require public disclosure, or are there convincing reasons not
> to? At first glance, it seems like 'guiding' CAs towards additional
> transparency in the CA
On 10/02/17 05:10, Peter Bowen wrote:
> On Thu, Feb 9, 2017 at 7:41 AM, Gervase Markham via
>> A) The date Google took control of the GlobalSign roots
>> B) The date Google publicly announced GTS
>>
>> you will see there's quite a big delta. If you assume Google told
>> Mozilla about event A)
Hi Ryan,
On 09/02/17 19:55, Ryan Hurst wrote:
> - The EV OID associated with this permission is associated with GlobalSign
> and not Google and,
Which EV OID are you referring to, precisely?
> - GlobalSign is active member in good standing with the respective root
> programs and,
> - Google
On 13/02/17 14:34, Doug Beattie wrote:
> This was for GlobalSign account used for testing, so it was a
> GlobalSIgn employee. Customers are not, nor have they ever been,
> permitted to add domains without GlobalSign enforcing the domain
> verification process.
But currently GlobalSign employees
On 13/02/17 19:22, Jeremy Rowley wrote:
> As we tied the intermediate to a specific set of companies (which correlated
> roughly to a specific volume of certificates), renewal and pinning were
> non-issues. As long as each company was identified under the same umbrella,
> an entity renewing,
On 13/02/17 17:34, okaphone.elektron...@gmail.com wrote:
> Isn't this mostly something that CAs should keep in mind when they
> setup "shop"?
>
> I mean it would be nice to have a way of avoiding that kind of impact
> of course, but if they think it's best to put all their eggs in one
> basket...
On 13/02/17 23:13, Santhan Raj wrote:
> One thing to highlight here is that the WebTrust audits are performed
> against the BRs and not against the root program requirements.
This is true, although (apart from the relative importance of domain
validation) this is similarly true of many items in
On 13/02/17 16:17, Steve Medin wrote:
> Getting all user agents with interest is issuance limits to implement
> the CA Issuers form of AIA for dynamic path discovery and educating
> server operators to get out of the practice of static chain
> installation on servers would make CA rollovers fairly
As members of the group will be aware, last month GoDaddy filed an
incident report concerning a problem with their domain validation system.
Domain validation is the most important task a CA can undertake, any any
flaws in it are serious. This is why the CAB Forum has been working for
some time
The GoDaddy situation raises an additional issue.
Mozilla is neither adding any of the 8951 revoked certificates to
OneCRL, nor untrusting any GoDaddy intermediates. However, a more
serious incident might have led us to consider that course of action. In
that regard, the following information is
Hi Steve,
On 12/02/17 15:27, Steve Medin wrote:
> A response is now available in Bugzilla 1334377 and directly at:
> https://bugzilla.mozilla.org/attachment.cgi?id=8836487
Thank you for this timely response. Mozilla continues to expect answers
to all reasonable and polite questions posed in our
On 27/02/17 21:41, Ryan Sleevi wrote:
> During a past discussion of precertificates, at
> https://groups.google.com/d/msg/mozilla.dev.security.policy/siHOXppxE9k/0PLPVcktBAAJ
> , Mozilla did not discuss whether or not it considered
> precertificates misissuance, although one module peer (hi! it's
On 26/02/17 00:50, Itzhak Daniel wrote:
> I talked with Ofer from Incapsula, he said the domain exist at some
> point; Someone have access to domain tools or other tool to verify
> this matter? Based on domaintools I can say the domain did exist but
> I can't tell when it cease to exist.
I think
Ryan H,
On 23/02/17 04:40, Peter Bowen wrote:
> Both Gerv and I posted follow up questions almost two weeks ago. I
> know you have been busy with CT days. When do you expect to have
> answers available?
Ping? :-)
Gerv
___
dev-security-policy
On 01/03/17 10:36, benjaminp...@gmail.com wrote:
> screenshot of the error message: http://imgur.com/a/BIQUm
That error message will not occur if only the root CA is SHA-1 signed,
because Firefox does not check the signatures on root CAs. There must be
some other certificate in the chain that
Hi Doug,
On 15/02/17 17:09, Gervase Markham wrote:
> But currently GlobalSign employees still are?
>
> If so, can you help us understand why that's necessary? Given that you
> control the domains used for testing, you should be able to set them up
> to auto-pass some form of automated
On 21/03/17 10:16, Gervase Markham wrote:
> On 17/03/17 11:30, Gervase Markham wrote:
>> The URL for the draft of the next CA Communication is here:
>> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2
>
> A few more
On 23/03/17 19:54, Jakob Bohm wrote:
> The above message (and one by Symantec) were posted to the
> mozilla.dev.security.policy newsgroup prior to becoming aware of
> Google's decision to move the discussion to its own private mailing
> list and procedures. I would encourage everyone concerned to
On 07/03/17 11:37, Gervase Markham wrote:
> Here are some proposals for policy change. Please do comment on these or
> suggest others.
I can report that at the CAB Forum face-to-face in Raleigh, NC, USA this
week, there was broad consensus to draw up a ballot which prevents CAs
from (to summarise
On 17/03/17 16:28, douglas.beat...@gmail.com wrote:
>> If the addition is so gated, what did the employee in this case do? Did
>> they upload bogus data?
>
> No bogus data was uploaded.
I spoke about this with Doug at the CAB Forum meeting. The system which
collects the data is not integrated
On 23/03/17 23:07, Kathleen Wilson wrote:
> Second paragraph of Action 1 now says: ~~ Note that version 1.4.2 of
> the BRs does not contain all 10 of these methods, but it does contain
> section 3.2.2.4.11, "Other Methods", so the subsections of version
> 3.2.2.4 that are marked "Reserved" in
On 23/03/17 16:09, Ryan Sleevi wrote:
> You can participate in this discussion at
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs
Participants who want to discuss Google's action should, of course,
visit the Blink forum above as Ryan has requested. However, the
On 27/03/17 23:18, okaphone.elektron...@gmail.com wrote:
> Will that remain the responsibility of GlobalSign for any existing
> certificates that have been signed with these roots? (Those would be
> intermediate certificates, if I understand correctly.) Or does
> revocation also require signing,
On 27/03/17 23:12, Andrew Ayer wrote:
> My interpretation of the policy is that a CA could delay disclosure for
> quite some time if the sub-CA is not used to issue certificates right
> away. If the sub-CA is created as a backup that is never used, the
> disclosure would never need to happen.
>
On 27/03/17 16:22, Ryan Sleevi wrote:
> Would it be useful to thus also query whether there would be impact in
> Mozilla applications failing to trust such certificates, but otherwise to
> continue permitting their issuance.
That is a good idea. How about:
If you are unable to support a
On 27/03/17 23:15, mono.r...@gmail.com wrote:
> Are there general proposals yet on how to distinguish phishing vs
> legitimate when it comes to domains? (like apple.com vs app1e.com vs
> mom'n'pop farmer's myapple.com)
Not for those sorts of differences. There are in an IDN context:
On 27/03/17 16:08, Martin Heaps wrote:
> The next level is now that any business or high valued entity should
> over the course of the next few years implement EV certificates (many
> already have) and that browsers should make EV certificates MORE
> noticable on websites..
or we should
On 17/03/17 15:30, Gervase Markham wrote:
> The URL for the draft of the next CA Communication is here:
> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2
>
> Note that this is a _draft_ - the form parts will not work,
On 28/03/17 12:21, Rob Stradling wrote:
> Increased attack surface. An undisclosed dormant sub-CA most likely has
> its private key in an online HSM, and so I think it's prudent to assume
> that it's more vulnerable (to being compromised by an attacker, or to
> being accidentally used to misissue
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
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
On 31/03/17 17:39, Peter Bowen wrote:
>>> For example, how frequently should roots
>>> be allowed to change hands? What would Mozilla's response be if
>>> GalaxyTrust (an operator not in the program)
>>> were to say that they are acquiring the HARICA root?
>>
>> From the above URL: "In addition,
As we continue to consider how best to react to the most recent incident
involving Symantec, and given that there is a question of whether it is
part of a pattern of behaviour, it seemed best to produce an issues list
as we did with WoSign. This means Symantec has proper opportunity to
respond to
On 06/03/17 15:10, Gervase Markham wrote:
> The next stage in the improvement of the Mozilla Root Store Policy is
> version 2.4.1. This is version 2.4, but rearranged significantly to have
> a more topic-based ordering and structure to it. I have also made
> editorial changes to clean up and
The URL for the draft of the next CA Communication is here:
https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2
Note that this is a _draft_ - the form parts will not work, and no CA
should attempt to use this URL or the form
On 16/03/17 11:25, douglas.beat...@gmail.com wrote:
> For the record, we don't think it's necessary (or permissible) to
> give employees (RAs) the power to add arbitrary domains to accounts
> without proper vetting.
I guess I'm still not being clear - sorry :-( Let me try one more time:
Why does
On 20/03/17 15:33, Kathleen Wilson wrote:
>> * Action 7: some of the BR Compliance bugs relate to CAs which are no
>> longer trusted, like StartCom. If StartCom does become a trusted CA
>> again, it will be with new systems which most likely do not have the
>> same bugs. Should we close the
On 20/03/17 13:07, Peter Bowen wrote:
>> E) SHA-1 and S/MIME
>>
>> Does your CA issue SHA-1 S/MIME certificates? If so, please explain your
>> plans for ceasing to do so, and any self-imposed or external deadlines
>> you are planning to meet. Mozilla plans to make policy in this area in
>> the
On 17/03/17 15:30, Gervase Markham wrote:
> The URL for the draft of the next CA Communication is here:
> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2
* Action 1 should say that if in future additional specific
On 16/03/17 13:15, Ryan Sleevi wrote:
> Or, put differently, it sounds as if you suggest the only obligation a CA
> has to ensure their DTP auditors are qualified for the task at hand is if,
> and only if, Mozilla requests those audits. In the absence of that request,
> the CA is allowed to make
On 16/03/17 17:20, douglas.beat...@gmail.com wrote:
> Yes, RAs (trusted role employees) need to have the technical ability
> to manually add domains to accounts. They can verify domains in one
> of the 10 different methods and some of those involve manually
> looking in who-is for registrant
On 17/03/17 11:30, Gervase Markham wrote:
> The URL for the draft of the next CA Communication is here:
> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2
A few more wording tweaks on the current version:
* Action 1
On 07/03/17 10:18, Gervase Markham wrote:
> OK. Question for group: would it make sense to add the intermediate(s)
> that GlobalSign is using for this purpose directly to the Mozilla trust
> store, with the EV bit enabled, and then remove the EV bit from the
> roots now owned by Google Trust
On 09/03/17 13:32, Ryan Sleevi wrote:
> (Wearing Google hat only for this statement)
> Have you considered having this discussion in the CA/Browser Forum? Google
> had planned to discuss this very topic at our upcoming F2F about how to
> address this, and would be very interested in collaborating
On 08/03/17 15:06, Peter Bowen wrote:
> By eliminating the DTP option, you will massively raise costs for CAs
> that rely upon local translators and information gatherers. I think a
> much better proposal would be to require the CA perform the RA
> activity contemplated by BR 3.2.2.4 and 3.2.2.5
On 08/03/17 16:20, Gervase Markham wrote:
> On 09/02/17 22:55, Peter Bowen wrote:
>> Policy Suggestion A) When transferring a root that is EV enabled, it
>> should be clearly stated whether the recipient of the root is also
>> receiving the EV policy OID(s).
>
> I agree with this suggestion; we
Hi Blake,
On 02/03/17 16:26, blake.mor...@trustis.com wrote:
> We have engaged with our external auditors in relation to this and the
> previous certificate that was reported. Once that activity has concluded we
> will be providing further information.
Do you have an ETA for this incident
On 13/03/17 21:31, Jeremy Rowley wrote:
> [JR] If you recall, I did try to change the policy. I was told to
> change the RFC if I didn’t like the requirement. I find trying to
> change the RFC nearly impossible as PKIX is dead and there are too
> many other issues people would also like to
On 16/03/17 10:50, Gervase Markham wrote:
> https://wiki.mozilla.org/CA:RootTransferPolicy#Change_in_Legal_Ownership
With these changes and the filing of
https://bugzilla.mozilla.org/show_bug.cgi?id=1347882 , I consider this
particular discussion RESOLVED. This means Mozilla plans to take no
On 03/03/17 20:59, douglas.beat...@gmail.com wrote:
> In general, when we receive new orders and issue certificates, the
> vetting is done just prior to issuance time which permits the
> certificate to be replaced up until expiration. We're looking into
> cases where new "orders" may have used
On 28/02/17 20:02, douglas.beat...@gmail.com wrote:
> And lastly this ticket. The Domain name was validated in accordance
> with the BRs, but there was a bug that allowed a user entered space
> to be included in some of the SAN values. While the value is not
> compliant with RFC 5280 or the BRs,
Hi Doug,
On 03/03/17 11:17, Gervase Markham wrote:
> That's lovely, but it doesn't answer my question. Let me restate it: why
> does GlobalSign believe it is necessary to give employees the power to
> add arbitrary domains to accounts without going through ownership
> validation?
You are getting
On 03/04/17 02:37, Peter Bowen wrote:
> I believe Issue L is incorrectly dated.
Thank you for this; I have updated Issue L to hopefully be more
accurate, but I intend to keep it as a separate issue.
Gerv
___
dev-security-policy mailing list
On 01/04/17 05:57, Peter Bowen wrote:
> The GeoRoot program was very similar to that offered by many CAs a few
> years ago. CyberTrust (then Verizon, now DigiCert) has the OmniRoot
> program, Entrust has a root signing program[1], and GlobalSign Trusted
> Root[2] are just a few examples.
While
On 01/04/17 00:38, Ryan Sleevi wrote:
> On Fri, Mar 31, 2017 at 2:39 PM, Gervase Markham via dev-security-policy <
> Thanks for organizing this information, as much of it was related to and
> relevant to Google's recent announcement. I want to take this opportunity
> to share add
On 11/04/17 17:18, Ryan Sleevi wrote:
> 1) On the basis of the controls Symantec described, at no point was any
> mention made of Symantec performing sampling audits to ensure their RA
> partners complied with either the RA partner's CP/CPS or Symantec's CP/CPS.
> a) Is it fair to conclude that
On 11/04/17 17:34, Ryan Sleevi wrote:
> Can you clarify what issues you believe this to be related?
That is a fair question. And also hard work to answer :-)
> Given that Symantec has a routine habit of exceeding any reasonable
> deadline for response, at what point do you believe it is
On 11/04/17 16:23, Ryan Sleevi wrote:
> The audits mention the CP/CPS has been evaluated as part of the scope of
> the audit.
Yep, OK.
> The CP/CPS mentions the issuance of TLS certificates as part of the
> hierarchy. For example,
>
> "E-Sign provides its services in accordance with its
On 11/04/17 17:51, Ryan Sleevi wrote:
> Also, search SSL. Not TLS :)
Aha!
> Further, its CPS states
>
> "MSC Trustgate.com is a “Processing Center,” as described in CP §
> 1.1.2.1.2, which
> means MSC Trustgate.com has established a secure facility housing, among
> other
> things, CA systems,
On 11/04/17 14:05, Peter Kurrasch wrote:
> Is there room to expand Mozilla policy in regards to ownership issues?
Subject to available time (which, as you might guess by the traffic in
this group, there's not a lot of right now, given that this is not my
only job) there's always room to
Hi Steve and Rick,
You have told me that you are considering your response(s) to the
Symantec issues list, which is fine. Based on the list and further
discussions which have been happening in m.d.s.policy, and on your
recent audit publication, I thought it would be helpful to give a few
specific
On 27/03/17 22:12, Andrew Ayer wrote:
> [ Corresponding issue on GitHub:
> https://github.com/mozilla/pkipolicy/issues/67 ]
This has now been added to the policy 2.5 draft with a one-week deadline.
Gerv
___
dev-security-policy mailing list
I've started the process of working on policy version 2.5 (does it ever
end? :-). The first thing I did was check in a number of tweaks and
wording changes which were in the April CA Communication, and therefore
had already been discussed, or which seemed uncontroversial. They are
those listed
On 03/04/17 13:11, Gervase Markham wrote:
> Hi Steve and Rick,
Q8) The accountant's letters for the 2015-2016 audits are dated February
28th 2017. The audits were supplied to Mozilla, and published, on the
1st of April 2017. Why the delay?
Gerv
___
On 04/04/17 16:31, douglas.beat...@gmail.com wrote:
> Attachment was stripped, here it the content:
Thanks Doug.
Unless anyone sees something particularly problematic here, I think we
can call this incident closed.
Gerv
___
dev-security-policy
On 31/03/17 22:20, Kathleen Wilson wrote:
> Please let me know asap if you see any problems, typos, etc. in this
> version.
Now that policy 2.4.1 has been published, we should update Action 3 to
say the following at the top:
Versions 2.4 and 2.4.1 of Mozilla's CA Certificate Policy have been
Hi Daniel,
We appreciate your additional input into determining the exact scope of
this problem.
On 31/03/17 19:37, Daniel Baxter (Aractus) wrote:
> With all due respect this reply is the most ridiculous load of
> nonsense I've ever read.
However, please keep the tone civil. If it's nonsense,
On 31/03/17 20:26, Peter Kurrasch wrote:
> The revised example is not entirely what I had in mind (more on that
> in a minute) but as written now is mostly OK by me. I do have a
> question as to whether the public discussion as mentioned must take
> place before the actual transfer? In other
Hi Doug,
Kathleen is unavailable this week, so I'll try and answer. (This might
have been better as a new top-level post, though...)
On 11/04/17 21:14, Doug Beattie wrote:
> This is my understanding:
>
> - Under policy 2.3 a CA that is technically
> constrained with EKU set to only secure email
On 11/04/17 23:07, Jakob Bohm wrote:
> Please consider the fact that this is Easter week, and most of the
> industry, including many people (on both the Browser and Symantec sides
> of the process) are likely to be unavailable for precisely this week of
> the entire year.
>
> In general, sending
Way back when, Mozilla wrote some requirements for auditors which were
more liberal than "be officially licensed by the relevant audit scheme".
This was partly because organizations like CACert, who were at the time
pondering applying for inclusion, might need to use
unofficially-qualified
Section 5.3.1 of policy 2.4.1 defines what it means to be technically
constrained for email sub-CAs (those with id-kp-emailProtection). It says:
"If the certificate includes the id-kp-emailProtection extended key
usage, then all end-entity certificates MUST only include e-mail
addresses or
There are some items that it would be very helpful for auditors to state
in their public-facing audit documentation so that we can be clear about
what was covered and what was not. The policy already has some
requirements here, in section 3.1.3, mostly relating to dates.
The proposal is to add
On 11/04/17 22:08, Eric Mill wrote:
> I'll leave it to others to opine on the severity of the mistake and the
> quality of the response, but I do want to at least properly communicate the
> impact.
Thank you. I have updated my write-up for Issue L.
Gerv
On 12/04/17 11:41, Kurt Roeckx wrote:
> But I'm also wondering what you expect if it contains other EKUs like
> client auth, code sign, unknown. Do we always consider them constraint?
Formally, we don't care if they also have those EKUs, or whether the use
of those EKUs is constrained, because
On 12/04/17 11:37, Jakob Bohm wrote:
> Does this (accidentally?) remove the ability of Mozilla to explicitly
> distrust a specific formally qualified auditor, such as E HK?
Good point. Not sure, but we should make that clear.
Add to the end of that exception sentence ", or refuse audits from
On 06/04/17 03:24, Peter Kurrasch wrote:
> things they like. It's a very lucrative business so when I see a root
> cert coming up for sale it's a no-brainer for me to go out and purchase
> it. Having access to a root will undoubtedly come in handy as I grow my
> business.
The previous owner of
On 06/04/17 18:42, Jakob Bohm wrote:
> Here are some ideas for reasonable new/enhanced policies (rough
> sketches to be discussed and honed before insertion into a future
> Mozilla policy version):
I'm not sure what's new or enhanced about them. Our current policies are
not this prescriptive so
Hi Ryan,
On 10/04/17 16:38, Ryan Sleevi wrote:
> 1) You're arguing that "the issuance of this cert didn't impose risk on
> anyone but this specific customer"
> a) What factors lead you to that decision?
Can you lay out for us a scenario where this issuance might impose risk
on someone else?
>
Hi Ryan,
On 10/04/17 17:20, Ryan Sleevi wrote:
> 1) You stated that this partner program applies to non-TLS certificates.
> The audit for both STN and for the RAs fails to make this distinction. For
> example, audits are listed related to the issuance of of TLS certificates.
The audits linked to
I have attempted to integrate the information provided by Symantec into:
https://wiki.mozilla.org/CA:Symantec_Issues
and started to draw some conclusions where that is warranted.
There are of course still open questions from myself, Ryan and others,
and so the truth relating to some incidents is
Hi Steve,
Thank you for this. Issue V was indeed somewhat confused - my apologies.
I have split it into Issue V, covering GeoRoot, and Issue W, covering
the RAs.
On 10/04/17 15:58, Steve Medin wrote:
> Separately, Symantec operates two subordinate CAs solely for NTT
> DoCoMo in an enterprise PKI
Hi Ryan,
On 10/04/17 17:03, Ryan Sleevi wrote:
> 2) You stated that "browsers didn't process certificate policy extensions
> content during path building". This fails to clarify whether you believe it
> was a Baseline Requirements violation, which makes no such statements
> regarding policy
Hi Steve and Rick,
Just to confirm: even after reviewing your extensive responses to the
issues list, I feel that all the 8 questions on my questions list are
still outstanding and require answers.
Thanks :-)
Gerv
___
dev-security-policy mailing list
On 13/04/17 17:43, Jeremy Rowley wrote:
> Because the certificate improperly included Symantec's BR-compliance OID. If
> the cert wasn't a BR-covered certificate but included the BR compliance OID,
> then the cert was still mis-issued and should be disclosed.
But that was not the reason they gave
On 21/04/17 10:12, Nick Lamb wrote:
> I'm not so uncomfortable with it that I want Mozilla to try to get it
> stopped, but I think signalling some residual discomfort here is
> worthwhile until somebody has thought through a good policy, and
> preferably at least got the big CAs to go along with
1 - 100 of 431 matches
Mail list logo
