Hi Doug,
On 01/06/17 10:54, Doug Beattie wrote:
> Can you give some examples of validation functions that need to be enforced
> by multifactor authentication? There are some that I don't think can be done
> using multi-factor authentication, such as domain validation via email (the
> link to
On 31/05/17 18:02, Matthew Hardeman wrote:
> Perhaps some reference to technologically incorrect syntax (i.e. an
> incorrectly encoded certificate) being a mis-issuance?
Well, if it's so badly encoded Firefox doesn't recognise it, we don't
care too much (apart from how it speaks to
On 01/06/17 01:48, Yuhong Bao wrote:
> I don't think there is anything important on example.com though
How would you like it if a CA decided there was nothing important on
your website and so decided it was OK to misissue certificates for it?
This requirement is a positive requirement ("must
It has been suggested we need a formal definition of what we consider
mis-issuance. The closest we have is currently a couple of sentence in
section 7.3:
"A certificate that includes domain names that have not been verified
according to section 3.2.2.4 of the Baseline Requirements is considered
On 19/05/17 14:47, Gervase Markham wrote:
> We need to have a discussion about the appropriate scope for:
>
> 1) the applicability of Mozilla's root policy
> 2) required disclosure in the CCADB
I've now reviewed the previous discussion we had on this topic, here:
On 19/05/17 13:18, Gervase Markham wrote:
> Ryan Sleevi suggested a wording clarification/policy extension to the
> multi-factor auth requirement, from:
>
> "enforce multi-factor authentication for all accounts capable of
> directly causing certificate issuance"
>
> to
>
> "enforce multi-factor
On 19/05/17 13:55, Gervase Markham wrote:
> "CAs whose certificates are included in Mozilla's root program MUST:
> .
> * follow industry best practice for securing their networks, for example
> by conforming to the CAB Forum Network Security Guidelines or a
> successor document;"
Implemented
On 26/05/17 01:01, Kathleen Wilson wrote:
> Known problems: - Some CAs did not provide their CAA (Certification
> Authority Authorization) information correctly, so that column is
> empty for them. Note that some CAs do not have the Websites trust bit
> set for any of their root certs, so that
Here's my roundup of things I think we should require of Symantec.
* Mozilla would wish, after 2017-08-08, to alter Firefox such that it
trusts certificates issued in the "new PKI" directly by embedding a set
of certs or trust anchors which are part of that PKI, and can therefore
distrust any new
On 24/05/17 16:33, Peter Bowen wrote:
> Can you clarify the meaning of "new PKI"? I can see two reasonable
> interpretations:
> 2) The new PKI includes both new offline CAs that meet the
> requirements to be Root CAs and new subordinate CAs that issue
> end-entity certificates. the The new
On 24/05/17 15:31, Peter Kurrasch wrote:
> It might be fair to characterize my position as "vague but
> comprehensive"...if that's even possible? There are some standard-ish
> frameworks that could be adopted:
I think we would prefer to wait for the CAB Forum to adopt something
rather than
Hi Doug,
On 18/05/17 12:03, Doug Beattie wrote:
> I'm still looking for audit guidance on subordinate CAs that have EKU
> of Server auth and/or Secure Mail along with name constraints. Do
> these need to be audited?
>
> I'm looking at this:
>
On 23/05/17 04:18, Peter Kurrasch wrote:
> I think the term "industry best practices" is too nebulous. For
> example, if I patch some of my systems but not all of them I could
> still make a claim that I am following best practices even though my
> network has plenty of other holes in it.
I'm not
On 22/05/17 16:43, Matthew Hardeman wrote:
> Regarding specifically the risk of the holder of a technically
> constrained subCA issuing a certificate with an SHA-1 signature or
> other improper signature / algorithm, my belief at this time is that
> with respect to the web PKI, we should be able
On 21/05/17 19:37, userwithuid wrote:
> With the new proposal, the "minimal disruption" solution for Firefox
> will require keeping the legacy stuff around for another 3.5-4 years
> and better solutions will now be a lot harder to sell without the
> leverage provided by Google.
Why so? In eight
On 19/05/17 22:10, Jakob Bohm wrote:
> Necessity: Whitelists in various forms based on such CT log entries,
> as well as the SCTs in OCSP responses can provide an alternative for
> relying parties checking current certificates even if the cleanup at
> Symantec reveals a catastrophic breach
On 19/05/17 21:04, Kathleen Wilson wrote:
> - What validity periods should be allowed for SSL certs being issued
> in the old PKI (until the new PKI is ready)?
Symantec is required only to be issuing in the new PKI by 2017-08-08 -
in around ten weeks time. In the mean time, there is no
On 20/05/17 15:26, Michael Casadevall wrote:
> However, for Mozilla's purposes, is there a case where having a SCT in
> certificate would either break something, or otherwise be undesirable?
I believe we turned the checking on and discovered performance issues,
so we turned it off. I'm not sure
On 19/05/17 20:40, Matthew Hardeman wrote:
> Not speaking as to the status quo, but rather in terms of
> updates/changes which might be considered for incorporation into
> policy would be to recognize the benefit of name constrained
> intermediates and allow a reduction in burden to entities
On 19/05/17 15:52, Carl Mehner wrote:
> Should we specify somewhere that multi-factor auth encompasses two
> _different_ factors and not simply multiple authenticators?
I appreciate your desire to cover all the angles, but I think the
standard definition of the term encompasses this.
I think
Hi m.d.s.p.,
Google have posted their updated plan for Symantec in the blink-dev
forum (copied below).
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ
Insofar as it pertains to Google's actions, you should go over and
discuss it there. But of course, this plan
On 19/05/17 16:06, Inigo Barreira wrote:
> Yes, I wanted to know if a regular user can use its Gmail account to get an
> s/mime cert but that can´t be issued because the CA can´t validate the
> domain properly because it´s not his or authorized to use it when doing the
> 3.2.2.4
This is about
On 19/05/17 15:16, Inigo Barreira wrote:
> What about those for gmail, Hotmail, etc.? Are out of scope?
I'm not sure what you mean. If Gmail wants a TCSC for @gmail.com, they
can have one. They would presumably need to set the dirName to "" or
null, because no dirName can cover all of their
On 19/05/17 15:28, Peter Bowen wrote:
> This is not accurate. They have indicated that the SSP customers have
> some level of issuance capability.
Oops. Well, they said that a while back, but yes indeed, since then we
have discovered the above fact.
Gerv
On 19/05/17 14:26, Kurt Roeckx wrote:
> I'm wondering why something like this should be in the Mozilla policy
> and not be part of something else that they get audited for.
Section 6.5.1 of the BRs states:
"The CA SHALL enforce multi‐factor authentication for all accounts
capable of directly
On 15/05/17 21:06, Michael Casadevall wrote:
> Sorry, I could have been more clear here. What I'm proposing is that
> after a specific TBD NotBefore date, we require SCTs to be in place on
> the certificate to be trusted. Certificates from before that date
> would remain trusted as-is (pending any
On 15/05/17 22:08, Michael Casadevall wrote:
> RA & EV:
> Were all the certificates issued by the RAs uploaded to a CT log? If
> not, what, if any, subsets were uploaded?
>
> I'm aware Symantec was required to upload certificates to CT or if it
> was retroactive, but I'm unsure if that requirement
On 19/05/17 14:58, Jakob Bohm wrote:
> Because the O and other dirname attributes may be shown in an e-mail
> client (current or future) as a stronger identity than the technical
> e-mail address.
Do you know of any such clients?
> Imagine a certificate saying that ge...@wosign.cn is "CN=Gervase
We need to have a discussion about the appropriate scope for:
1) the applicability of Mozilla's root policy
2) required disclosure in the CCADB
The two questions are related, with 2) obviously being a subset of 1).
It's also possible we might decide that for some certificates, some
subset of the
On 08/05/17 11:32, Dimitris Zacharopoulos wrote:
> On 8/5/2017 1:18 μμ, Gervase Markham wrote:
>>> + dirName entries scoped in the Organizational name and
>>> location
>> Help me understand how dirName interacts with id-kp-emailProtection?
>
> When the Subscriber belongs to an
On 12/04/17 10:47, Gervase Markham wrote:
> We don't have any "Email BRs" to refer to, but I think we want something
> like this:
>
> "If the certificate includes the id-kp-emailProtection extended key
> usage, it MUST include the Name Constraints X.509v3 extension with
> constraints on
At the moment, the CAB Forum's Network Security guidelines are audited
as part of an SSL BR audit. This means that CAs or sub-CAs which only do
email don't technically have to meet them. However, they also have a
number of deficiencies, and the CAB Forum is looking at replacing them
with something
Ryan Sleevi suggested a wording clarification/policy extension to the
multi-factor auth requirement, from:
"enforce multi-factor authentication for all accounts capable of
directly causing certificate issuance"
to
"enforce multi-factor authentication for all accounts capable of causing
On 12/05/17 14:00, Gervase Markham wrote:
> Because the Mozilla root store is used by more people than Mozilla,
> Kathleen would like to put anyEKU in scope even though Firefox ignores it.
Implemented as specced.
Gerv
___
dev-security-policy mailing
On 12/05/17 14:21, Gervase Markham wrote:
> Specifically, we could add text to the top of section 5.2 ("Forbidden
> and Required Practices"):
>
> "CA operations MUST at all times be in accordance with the applicable CP
> and CPS."
Implemented as specced.
Gerv
On 12/05/17 18:54, Jakob Bohm wrote:
> Perhaps tweak the wording to make the document submitted to the CCADB
> binding, rather than any CP/CPS published elsewhere.
While that certainly seems attractive, changing the location of the
canonical CP/CPS from the CA's repository to Mozilla's repository
On 12/05/17 14:18, Gervase Markham wrote:
> I propose instead:
>
> "Changes that are motivated by a security concern such as certificate
> misissuance or a root or intermediate compromise MUST be treated as a
> security-sensitive, and a secure bug filed in Bugzilla.
Implemented as proposed.
On 18/05/17 23:40, Nick Lamb wrote:
> Mmmm. I believe only 3.2.2.4 is acceptable to Mozilla, am I wrong
> here? Judging from self-assessment document, TrustCor's actual
> practices are all intended to be 3.2.2.4 compliant (I will examine in
> more detail later) but the language here suggests it
On 17/05/17 13:32, Rob Stradling wrote:
> I've just added two columns to
> https://crt.sh/mozilla-disclosures#undisclosed:
> - "Earliest SCT".
> - "Listed Here Since".
Lovely! Now we just need a cert to be on the list so we can see what it
looks like ;-)
Gerv
On 17/05/17 15:08, Rob Stradling wrote:
> Incidentally, it's true that Mozilla have said that they don't care
> about the Code Signing trust bit any more, but the
> CKA_TRUST_CODE_SIGNING haven't yet been removed from certdata.txt. Bug?
Yes, but a low priority one. Feel free to file :-)
Gerv
On 17/05/17 12:55, Jakob Bohm wrote:
> That is /human readable/ information, not /computer readable/ data that
> can be imported by other libraries when those are used with the Mozilla
> root program.
Yes, indeed. But you asked where in certdata.txt those things are, and
that page explains pretty
On 16/05/17 18:04, Jakob Bohm wrote:
> Could you please point out where in certdata.txt the following are
> expressed, as I couldn't find it in a quick scan:
>
> 1. The date restrictions on WoSign-issued certificates.
>
> 2. The EV trust bit for some CAs.
I am surprised you are engaging in a
On 16/05/17 02:26, userwithuid wrote:
> After skimming the responses and checking a few CAs, I'm starting to
> wonder: Wouldn't it be easier to just add another mandatory field to
> the CCADB (e..g. "revocation contact"), requiring $URL or $EMAIL via
> policy and just use that to provide a public
On 15/05/17 14:19, Doug Beattie wrote:
> https://support.globalsign.com/customer/portal/articles/1216323
Thanks, Doug. There's no date on that doc - are you able to say when it
was written?
Gerv
___
dev-security-policy mailing list
On 12/05/17 09:18, Cory Benfield wrote:
> I try not to decide whether there is interest in features like this:
> if they’re easy I’d just implement them and let users decide if they
> want it. That’s what I’d be inclined to do here. If Mozilla added
> such a flag, I’d definitely be open to adding
On 15/05/17 12:54, Kurt Roeckx wrote:
> At least it's technically constrained.
Ah yes, you are right. Not nearly such an issue, then.
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
On 15/05/17 14:07, Jakob Bohm wrote:
> 1. Microsoft's e-mail clients were very late to accept stronger
> signature algorithms for e-mails (including e-mails sent by users of
> non-problematic e-mail clients). I believe Globalsign's page about
> SHA256-transition for customers provides a
With two exceptions (neither of which have the websites trust bit set),
all answers are now in from the April 2017 CA Communication. You can
find links to the answers here:
https://wiki.mozilla.org/CA/Communications#April_2017_Responses
Some highlights for the community's attention:
* (Q1) It
Hi all,
One of the CA Communication questions was about the Problem Reporting
Mechanisms that CAs are supposed to have. The answers are here:
https://mozillacaprogram.secure.force.com/Communications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC=Q00028
I would love it if someone would
Symantec have supplied the audits for their GeoRoot partner "Aetna":
https://bug1334377.bmoattachments.org/attachment.cgi?id=8867397
https://bug1334377.bmoattachments.org/attachment.cgi?id=8867398
The community might find them interesting reading. These audits are the
only ones Symantec received
Mozilla policy requires that certificates issued in contravention of a
CA's CP/CPS should be revoked. Other than that, Mozilla policy does not
directly require that a CA operate in accordance with its CP and CPS. We
require this indirectly because the audits that we require, require it.
This
Mozilla's Enforcement Policy indicates what to do when a serious
security concern is noticed, but does not indicate what to do when a
lesser security concern is noticed.
The current text is now in section 7, and says:
"Changes that are motivated by a serious security concern such as a
major root
On 11/05/17 18:05, Alex Gaynor wrote:
> I don't think Cory's arguing against browsers making use of these types of
> remediations, he just wants the non-browser clients to be able to
> participate as well :-)
Sure. I'm just heading off that argument at the pass :-)
Gerv
On 11/05/17 13:02, wiz...@ida.net wrote:
> That said, it is fair point that the plan should spell out what happens if
> symantec does not cooperate.
I think we should cross that bridge when we come to it, which I hope we
won't. Not that I'm not prepared to cross it, but there's no point
On 11/05/17 12:46, Rob Stradling wrote:
> There's a "Created by" field (Username, Timestamp) and a "Last Modified
> By" field (Username, Timestamp) in the CCADB, but neither of these
> fields are currently provided in the public CSV reports that Mozilla
> publishes.
Rob: do you think you could
Hi Cory,
On 11/05/17 15:21, Cory Benfield wrote:
> While I’m very supportive of this kind of remediation, it is not a
> remediation that non-browser implementations can follow very easily.
Unfortunately, this is not a good enough reason to remove graduate trust
proposals from our arsenal of
Dear Steve and Rick,
This is an official communication from the Mozilla CA program requesting
Symantec's answers to the following questions by close of business on
Monday 15th May. Your answers will be posted in
mozilla.dev.security.policy if you don't put them there yourselves. Your
speedy
On 10/05/17 18:12, userwithuid wrote:
> Limiting to 60 months could be done right now as a sanity check and shouldn't
> cause any problems, right?
https://bugzilla.mozilla.org/show_bug.cgi?id=908125 .
Gerv
___
dev-security-policy mailing list
On 08/05/17 13:24, Gervase Markham wrote:
> 8) Please explain how the Management Assertions for your December 2014
Strike this question; it's based on a misunderstanding of how audits are
done.
Let's add:
10) Do you agree that, during the period of time that Symantec
cross-signed the Federal
On 09/05/17 18:25, Doug Beattie wrote:
> I'm not clear on what you mean by CAs must use only the 10 Blessed Methods by
> 21st July 2017.
>
> I'm assuming this is the latest official draft:
>
> https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md
Yes :-)
> Specifically, does
On 01/05/17 10:13, Gervase Markham wrote:
> This would involve replacing section 2.2.3 of the policy with:
Incorporated as drafted. CAs should take note (from this change and from
the CA Communication) that Mozilla's policy is moving in the direction
of requiring the 10 Blessed Methods alone,
On 01/05/17 10:09, Gervase Markham wrote:
> This simply involves changing a "2.0" to "2.2" in section 3.1.1 and
> updating the URL labelled "WebTrust-BRs" to be
> http://www.webtrust.org/principles-and-criteria/docs/item83987.pdf .
Done.
Gerv
___
On 01/05/17 10:02, Gervase Markham wrote:
> Here is a diff of the proposed changes:
> https://github.com/mozilla/pkipolicy/compare/issue-57
Incorporated.
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
On 08/05/17 16:50, Kurt Roeckx wrote:
> So all of them except those from 2017-05-05 should have been marked in
> the Common CA Database as revoked but haven't been marked as such.
Thank you. I have drawn this to the attention of the 3 CAs concerned and
asked them to post here to indicate when
Hi everyone,
Yesterday was May 8th, which was the day I had said we would stop
discussing my proposal of what to do about Symantec and hand it over to
Kathleen for a decision. This didn't happen for two reasons: I had some
personal things to deal with, and also I think the proposal needs some
I think it might be appropriate to have a further round of questions to
Symantec from Mozilla, to try and get some clarity on some outstanding
and concerning issues. Here are some _proposed_ questions; feel free to
suggest modifications or other questions, and I will decide what to send
officially
On 05/05/17 19:44, Dimitris Zacharopoulos wrote:
> * MUST include an EKU that has the id-kp-emailProtection value AND
> * MUST include a nameConstraints extension with
> o a permittedSubtrees with
> + rfc822Name entries scoped in the Domain (@example.com) or
>Domain
On 05/05/17 18:58, Peter Bowen wrote:
>> Right now the policy does not require disclosure of CA-certificates
>> that the CA deems are technically constrained.
I believe this was made the case for some mix of the following reasons:
a) the CA did not want to reveal every customer it had;
b) this
On 05/05/17 17:09, Peter Bowen wrote:
> We know that the RAs could use different certificate profiles, as
> certificates they approved had varying issuers, and "Issuer DN" has
> the same "No(1)" that CP has in the table in the doc you linked. I
> don't see any indication of what profiles each RA
On 01/05/17 09:55, Gervase Markham wrote:
> "Each entry in permittedSubtrees must either be or end with a Public
> Suffix." (And we'd need to link to publicsuffix.org)
Aargh. This should, of course, be "Public Suffix + 1" - i.e. an actual
domain owned by someone.
> The second option is harder to
CrossCert appear to be issuing BR-noncompliant certs under KISA roots now:
https://crt.sh/?cablint=101=40347=cablint
We don't trust KISA as it's a Super-CA:
https://crt.sh/?caid=55=cablint
https://bugzilla.mozilla.org/show_bug.cgi?id=335197
https://bugzilla.mozilla.org/show_bug.cgi?id=1310580
but
On 05/05/17 04:30, Steve Medin wrote:
> Gerv, thank you for your draft proposal under consideration. We have posted
> our comments and detailed information at:
> https://www.symantec.com/connect/blogs/symantec-ca-continues-public-dialogue
It feels somewhat strange to have this disjointed
On 04/05/17 21:58, Ryan Sleevi wrote:> rather, it was based on the
evidence that there were issues
> and patterns that were unresolved, and thus sought to minimize the impact
> of an eventual total distrust in a gradual way.
So the first Chrome proposal had the explicit target of an eventual
On 04/05/17 19:30, Jakob Bohm wrote:
> 1. Issue D actually seems to conflate three *completely different*
> issues:
Are you sure you are not referring to the Issues List document here
rather than the proposal?
> 2. If the remaining unconstrained SubCAs are operated by Symantec and
> subject
On 05/05/17 10:22, Rob Stradling wrote:
> Mozilla could CNAME from ccadb.org to .force.com, and then
> declare that the ccadb.org URLs are the official ones.
It would need to be .ccadb.org, as we plan to use
www.ccadb.org as an introductory website for the CCADB, once Mozilla IT
configures things
On 04/05/17 18:42, Kathleen Wilson wrote:
> Gerv is leading the effort to clean up Mozilla's Root Store related
> wiki pages.
With lots of help from Kathleen :-)
> Please let me know if information that you need disappears, and you
> are not able to find it by starting with
On 03/05/17 21:31, Han Yuwei wrote:
> A question:How would a domain holder express denial for certain certificate
> requests?
Please can you post new questions as new threads rather than as replies
to existing threads on another topic?
The answer to your question is that they can define which
On 03/05/17 16:45, Peter Kurrasch wrote:
> Perhaps a different way to pose the questions here is whether Mozilla
> wants to place any expectations on the CA's regarding fraud and the
> prevention thereof.
You need to be more specific, because there are lots of different ways a
system can have
Hi Steve,
On 02/05/17 18:39, Steve Medin wrote:
> Gerv- Thank you for the thoughtful analysis. We are reviewing and intend to
> respond to your latest proposal shortly.
Please understand that this is not (yet) Mozilla's response to Symantec.
If we were a closed root program, this would be an
Group participants may be interested in David Keeler's analysis of why
Firefox seemed to be seeing cert pinning mismatches for Mozilla properties:
https://people-mozilla.org/~dkeeler/deployment-checker-analysis.html
Gerv
___
dev-security-policy mailing
On 01/05/17 18:33, Alex Gaynor wrote:
> One idea that occurred to me (maybe novel, though I doubt it), is requiring
> mandatory _timely_ CT submission for intermediates/cross signatures. That
> is, to be compliant an issuers's (SCT-timestamp - cert-not-before) must be
> less than some period,
On 02/05/17 00:01, Ryan Sleevi wrote:
> Thank you for
> 1) Disclosing the details to a sufficient level of detail immediately
> 2) Providing regular updates and continued investigation
> 3) Confirming the acceptability of the plan before implementing it, and
> with sufficient detail to understand
On 02/05/17 03:10, Peter Kurrasch wrote:
> Your updates look good! One small quibble: The bottom of the Physical
> Relocation section mentions the code signing trust bit, but I think that
> is irrelevant now?
I see that on https://wiki.mozilla.org/CA:RootTransferPolicy , but
that's the document
On 02/05/17 01:55, Peter Kurrasch wrote:
> I was thinking that fraud takes many forms generally speaking and that
> the PKI space is no different. Given that Mozilla (and everyone else)
> work very hard to preserve the integrity of the global PKI and that the
> PKI itself is an important tool to
On 01/05/17 18:53, Lee wrote:
> You seem to be replacing a "meets or exceeds" requirement with a
> "strictly meets" requirement.
That is not particularly the intention. I think that the Baseline nature
of the Baseline Requirements means that CAs know it's generally OK to go
above and beyond what
Here is my analysis and proposal for what actions the Mozilla CA
Certificates module owner should take in respect of Symantec.
https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit#
Please discuss the document here in mozilla.dev.security.policy. A good
timeframe
The last CA Communication laid down our policy of only permitting the 10
Blessed Methods of domain validation. A CA Communication is an official
vehicle for Mozilla Policy so this is now policy, but it's not reflected
in the main policy doc. I was planning to wait until the latest version
of the
There is a new version of the WebTrust criteria, version 2.2, which
references version 1.4.2 of the BRs (although the BRs themselves say
that audits should be to the latest version). We should update our
policy to reference this new version.
This simply involves changing a "2.0" to "2.2" in
Mozilla has a Root Transfer Policy which sets out our expectations
regarding how roots are transferred between organizations, or what
happens when one company buys another, based on a recognition that trust
is not always transferable.
https://wiki.mozilla.org/CA:RootTransferPolicy
It has been
Does anyone have any thoughts about this issue, below?
I sent out a message saying that I had adopted this change as proposed,
but that was an error. It has not yet been adopted, because I am
concerned about the below.
The first option is simpler, because it does not need to get into the
details
On 20/04/17 14:46, Gervase Markham wrote:
> So, proposed new text:
>
> "CAs MUST revoke Certificates that they have issued upon the
> occurrence of any event listed in the appropriate subsection of section
> 4.9.1 of the Baseline Requirements (for email certificates, not
> including those events
On 20/04/17 14:39, Gervase Markham wrote:
> So I propose removing it, and reformatting the section accordingly.
Edit made as proposed.
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
On 01/05/17 07:52, Percy wrote:
> It seems that StartCom continues to sell untrusted certs. Neither their home
> page https://www.startcomca.com/ nor their announcement page
> https://www.startcomca.com/index/news mentions that those certs are not
> trusted.
Why is this something that Mozilla
On 20/04/17 14:02, Gervase Markham wrote:
> I propose this section be removed from the document.
This section has now been removed. Regardless of other points raised,
the issuing of wildcard certs /per se/ is not a Problematic Practice.
Gerv
___
If the Nets Norway intermediate is technically constrained only to
domains that Nets Norway own or control, I have no problem with leaving
it active.
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
On 21/04/17 18:19, Eric Mill wrote:
> The FPKI cross-signs at issue in Issue L are now expired (and so don't show
> on the links above). They do show when expired certificates are included --
> there are 6 of them with OU=FPKI:
> https://crt.sh/?Identity=%25=1384
>
> Each of those certificates
Hi Peter,
On 25/04/17 02:10, Peter Kurrasch wrote:
> Fair enough. I propose the following for consideration:
As it happens, I have been working on encoding:
https://wiki.mozilla.org/CA:RootTransferPolicy
into our policy. A sneak preview first draft is here:
Hi Blake,
On 21/04/17 16:55, blake.mor...@trustis.com wrote:
> Following further discussion with, and guidance from Mozilla, it has
> been determined that the getset.trustis.com certificate issued in
> November 2016 was a mis-issuance. This incident has highlighted an
> ambiguity arising from
On 21/04/17 11:38, Kurt Roeckx wrote:
> I'm still concerned that they don't seem to have an idea of what
> software they're all (still) running, and they didn't reply to any
> question about it.
I'm sorry, I don't follow. Can you expand?
Gerv
___
On 22/04/17 02:23, Matt Palmer wrote:
> Didn't a CA get caught fairly recently issuing certs with sAN:example.com
> when the validation was for www.example.com, and got a stern talking to as a
> result? I vaguely recall something about that, but not with enough detail
> to trawl the archives
201 - 300 of 431 matches
Mail list logo
