On 13/02/17 16:18, Peter Bowen wrote:
> In addition to updating it to follow formal policy language, I would
> suggest adding it directly to the policy. As it stands today there
> are 79 pages in the wiki starting with "CA:". It simply isn't
> possible to know which ones are effectively part of t
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 t
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 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
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 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, orderi
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:
https://bugzilla.mozi
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 whi
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
som
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 lis
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
https://github.com/m
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 he
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:
https://letsencrypt.org/2015/10/29/phis
On 23/02/17 21:35, wuyi wrote:
> “Acknowledgment and Acceptance: An acknowledgment and acceptance that
> the CA is entitled to revoke the certificate immediately if the
> Applicant were to violate the terms of the Subscriber or Terms of Use
> Agreement or if the CA discovers that the Certificate is
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 pro
On 24/02/17 08:25, Andrew Ayer wrote:
> Below is an unrevoked SHA-1 serverAuth certificate for
> getset.trustis.com issued from this CA with a Not Before date of
> 2016-11-07.
Blake: you wrote: "As part of the incident handling procedure, Trustis’
security management committee, commissioned a full
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
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 t
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 mailing
Version 2.4 of Mozilla's CA Policy has now been published. You can find
it here:
https://github.com/mozilla/pkipolicy/blob/2.4/rootstore/policy.md
This document incorporates by reference the Common CCADB Policy 1.0:
https://github.com/mozilla/pkipolicy/blob/2.4/ccadb/policy.md
and the Mozilla CCAD
On 13/02/17 12:23, Gervase Markham wrote:
> The GoDaddy situation raises an additional issue.
> What can be done about the potential future issue (which might happen
> with any large CA) of the need to untrust a popular intermediate?
> Suggestions welcome.
Reviewing the d
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 Fire
Hi Doug,
On 28/02/17 12:44, douglas.beat...@gmail.com wrote:
> Sorry, I missed the last request. As outlined above, this domain was
> added to this account for only a very short period of time and then
> it was removed, so it's no longer being used. Further, we've
> educated the groups involved
On 28/02/17 20:02, douglas.beat...@gmail.com wrote:
> Suspicious Test certificate
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/-gaS1p3vrXc
>
> I provided a formal response in that thread that I believe closes
> this issue.
I still have an outstanding question.
> And last
On 02/03/17 20:45, Eric Mill wrote:
> Our goal is to start a new root and set of issuing CAs that is completely
> disconnected and separate from the existing Federal PKI bridge network that
> members of the web PKI community may be familiar with.
Are you able to say whether you will be seeking a c
On 03/03/17 10:16, benjaminp...@gmail.com wrote:
> Could RSASSA-PSS as the used signature algorithm be the Problem?
Yes, we don't support that. Although we may at some point:
https://bugzilla.mozilla.org/show_bug.cgi?id=1088140
Gerv
___
dev-security-po
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 clarify language, and improved the
Markdown markup.
*Th
On 06/03/17 17:44, Ryan Sleevi wrote:
> I'm assuming as with previous discussions, you'd like to keep the
> discussion on the list.
Yes, please :-)
> Overall: I would suggest every "should" be replaced with either a "must" or
> a "shall" RFC2119 style, to avoid any "best practice" vs "required ma
On 07/03/17 03:14, Ryan Hurst wrote:
>> Gerv: Just to be clear: GlobalSign continues to operate at least one subCA
>> under a root which Google has purchased, and that root is EV-enabled,
>> and the sub-CA continues to do EV issuance (and is audited as such) but
>> the root is no longer EV audit
Thank you again to Andrew Ayer for the original report.
As the community will have seen, these were the tip of an iceberg of
reasonably large proportions. While it's true that we are still waiting
for Symantec to provide information about e.g. how many certificates
have been re-validated and how m
On 07/03/17 23:26, Nick Lamb wrote:
> I am concerned that the specificity of Policy Proposals 1 & 2 risks
> fighting the last war by focusing so much on the RA role.
I guess that's possible; however, it's clear to me that we need policy
improvements in this area. If you know where the next war wil
On 07/03/17 20:37, Ryan Sleevi wrote:
> To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated
> Third Parties from participating in the issuance process? This would be
> effectively the same, in as much as the only capability to allow a
> third-party to participate in issuance
On 08/03/17 03:54, Peter Kurrasch wrote:
> - Google has acquired 2 root certificates from GMO GlobalSign but not
> the company itself.
Yes.
> GMO GlobalSign will continue to own other roots and
> will use only those other roots for the various products and services
> they choose to offer going
Having gained a good understanding of Peter and Ryan's positions, I
think I am now in a position to evaluate Peter's helpful policy suggestions.
Whether or not we decide to make updates, as Kathleen pronounced herself
satisfied at the time with Google's presented documentation and
migration plan,
On 08/03/17 16:36, Ryan Sleevi wrote:
> That is precisely the goal. We could define a set of process and procedures
> specific to DTPs, which is effectively duplicitive with the handling of
> subordinate CAs, or we could strive to align the two both conceptually and
> materially, since, as you note
On 08/03/17 17:43, Ryan Hurst wrote:
>> Gerv: We do require this, but not publicly. I note and recognise Ryan's
>> concern about requiring advance disclosure of private deals. I could see
>> a requirement that a transferred root was not allowed to issue anything
>> until the appropriate paperwor
On 09/03/17 02:15, Richard Wang wrote:
> So the policy can make clear that the root key transfer can't
> transfer the EV OID, the receiver must use its own EV policy OID for
> its EV SSL, the receiver can't use the transferor's EV OID.
We could indeed write this into the policy, but it would have
On 09/03/17 12:38, Richard Wang wrote:
> As my understanding, if WoSign buy an trusted EV enabled root key
> with EV OID today, then we can issue WoSign EV SSL cert using this EV
> OID tomorrow, the browser will display EV green bar. Right?
Technically, you are correct - such certs would produce
On 10/03/17 06:41, Peter Kurrasch wrote:
> * Types of transfers: I don't think the situation was envisioned where a
> single root would be transferred between entities in such a way that
> company names and branding would become intermingled. My own personal
> opinion is that such intermingling i
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 w
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 a
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 change.
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
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 agr
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
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 cer
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
> valida
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 repor
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 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 th
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 info,
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 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
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 sp
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 StartCo
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 futu
On 20/03/17 16:29, Kathleen Wilson wrote:
> updated
>
> See action 9 here:
> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2
You now need to remove the second bullet in this action, as it's
redundant with the reduced sco
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
On 07/03/17 10:07, Ryan Sleevi wrote:
>>> - As you reformat this, perhaps it's worth borrowing the Microsoft of
>>> approach of mapping trust bits to criteria
I have now tried this; thank you for your wording suggestion. Please let
me know what you think.
I've also updated it to use RFC 2119 la
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
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 versi
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 sum
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 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 wit
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
discu
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 w
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 decide
On 27/03/17 16:18, Ryan Sleevi wrote:
> I'm curious whether you would consider 18 months an appropriate target for
> a deprecation to 1 year certificates. That is, do you believe a transition
> to 1 year certificates requires 24 months or 18 months, or was it chosen
> simply for its appeal as a sta
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 compreh
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, an
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 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:
http://unicode
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
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 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 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 30/03/17 15:01, Peter Kurrasch wrote:
> By "not new", are you referring to Google being the second(?)
> instance where a company has purchased an individual root cert from
> another company? It's fair enough to say that Google isn't the first
> but I'm not aware of any commentary or airing of op
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, if
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 i
Version 2.4.1 of Mozilla's CA Policy has now been published. You can
find it here:
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
This document incorporates by reference the Common CCADB Policy 1.0:
https://github.com/mozilla/pkipolicy/blob/2.4.1/ccadb/policy.md
and the Mozill
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, de
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
publ
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 words,
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 shar
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 th
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
dev-securi
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
dev-securit
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 here
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 mailing
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 the
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 CA
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
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 buildi
Hi Eric,
Perhaps you are being intentionally non-directive, in which case perhaps
you can't answer my questions, but:
On 11/04/17 04:45, Eric Mill wrote:
> That root certificate's name ("VeriSign Class 3 SSP Intermediate CA - G2")
> was never mentioned in Bugzilla, and was not discussed during th
601 - 700 of 1053 matches
Mail list logo
