On Friday, 3 June 2016 07:53:06 UTC+1, bernd.n...@t-systems.com wrote:
> We revoked the affected certificate immediately.
>
> One of our customers issued a S/MIME certificate (SHA-1) to misuse as gateway
> certificate. That's the reason, why this certificate was identified as
> incorrect TLS
On Tuesday, 21 June 2016 17:10:43 UTC+1, Peter Bowen wrote:
> If all paths from a trusted root to a given intermediate are revoked
> or expired, then I don't think it "directly or transitively chain[s]
> to a certificate included in Mozilla’s CA Certificate Program". It
> would be no different
On Sunday, 26 June 2016 21:26:06 UTC+1, Ben Laurie wrote:
> My concern is that is is trivial to demonstrate an intermediate is
> revoked, yet still validate a chain that includes that "revoked"
> certificate.
Sure. If you decide not to check for revocation, then you won't know if it's
revoked.
On Saturday, 23 April 2016 02:03:15 UTC+1, Kathleen Wilson wrote:
> In this case (as in most cases), I verified the information provided by the
> CA, according to the checklist,
> https://wiki.mozilla.org/CA:Information_checklist
Thanks again Kathleen. This makes more sense to me now.
On Friday, 22 April 2016 01:00:42 UTC+1, Rick Andrews wrote:
> Symantec AATL ECC Intermediate CA was never intended for issuing SSL/TLS
> certificates. It has never been used and will not be used in the future for
> SSL/TLS. As such, it hasn't been disclosed to date. We are planning to revoke
On Thursday, 21 April 2016 17:15:43 UTC+1, Rick Andrews wrote:
Microsoft has now expressed their opinion that they need to allow them
(https://cabforum.org/pipermail/public/2016-April/007335.html).
Did you mean to put another link there? That link is Jody writing about the
hack of shoving IP
On Wednesday, 20 April 2016 21:01:18 UTC+1, Kathleen Wilson wrote:
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=8727954
In this document "Note requesting EV treatment" probably should read "Not
requesting EV treatment" since, as I understand
On Friday, 29 April 2016 02:22:14 UTC+1, Man Ho (Certizen) wrote:
> Hi Rob,
>
> I know that there is a discussion regarding "bits of entropy" or
> "unpredictable bits" in certificate serial number. I do not familiar
> with this topic, but my gut feeling is that "unpredictable bits" is
>
On Wednesday, 13 April 2016 21:39:48 UTC+1, Kathleen Wilson wrote:
> I have added links to reports of the responses to the March 2016 CA
> Communication survey:
>
> https://wiki.mozilla.org/CA:Communications#March_2016_Responses
Thanks Kathleen,
I have compared the list of responses to the
On Friday, 6 May 2016 15:06:30 UTC+1, Richard Barnes wrote:
> I would phrase this slightly differently :) If C is a Mozilla program
> root, it has an obligation to verify that all of the subordinates under B
> are audited and disclosed. My point is that if C doesn't do this check
> proactively,
On Tuesday, 17 May 2016 04:19:57 UTC+1, Peter Gutmann wrote:
> So you're saying users expect CAs to certify malware sites?
I'm a user, and that's what I expect, so trivially yes.
___
dev-security-policy mailing list
On Friday, 13 May 2016 21:02:25 UTC+1, Rob Stradling wrote:
> If it were up to me, I would...
>1. Require https://crt.sh/?id=1790 to be disclosed precisely once, by
> Web.com, because the chain up to Web.com's Built-in Root is the shortest
> chain.
>2. Hold both Web.com and Comodo
On Friday, 6 May 2016 11:59:32 UTC+1, Rob Stradling wrote:
> Nick, IIUC you're arguing for "CoAP" (to use Richard's terminology). Is
> that right?
I suppose so. I think Richard has the trust arrow upside down in his reflection
on this policy. Take his scenario in which a SubCA (A) is
On Wednesday, 4 May 2016 21:34:28 UTC+1, Rob Stradling wrote:
> Thanks Nick. All suggestions welcome. :-)
Not so much a suggestion this time as a potential bug report
"Let's Encrypt Authority X2" appears twice in the table, both times it is
listed with the DST Root CA X3 issuer. However it
On Wednesday, 4 May 2016 12:07:01 UTC+1, Rob Stradling wrote:
> As promised, here it is...
>
> https://crt.sh/mozilla-disclosures
Thanks so much Rob, I have written previously in praise of tools that "take
something people already knew was a good idea and automate the boring parts".
This is
Some more thoughts (my previous substantive comments are awaiting moderation
because I foolishly sent them before subscribing)
1. Historically other CAs in this family have issued certificates which abuse
wildcards, like this:
https://crt.sh/?id=16640133=cablint
Over the several years this
Hi Robin,
On Friday, 29 July 2016 18:54:56 UTC+1, Robin Alden wrote:
> We received a report of bugs in the construction of the emails we send out
> in order to confirm authorization by the domain name registrant prior to
> issuing a server certificate.
>
> Colloquially these are known as
On Thursday, 14 July 2016 05:18:20 UTC+1, Andrew Ayer wrote:
> Revocation does not address the risk that this mis-issuance has caused
> to the ecosystem, since collided certificates (the ones we cannot see,
> and need to be worried about) have different serial numbers and
> therefore do not
On Wednesday, 6 July 2016 09:50:46 UTC+1, Peter Gutmann wrote:
> Oh dear God, another one? We've already got CMP, CMC, SCEP, EST, and a whole
> slew of other ones that failed to get as far as RFCs, which all do what ACME
> is trying to do. What's the selling point for ACME? That it blows up in
On Thursday, 7 July 2016 01:52:23 UTC+1, Peter Gutmann wrote:
> There wasn't any decision to leave it unaddressed, no-one had ever expressed
> any interest in this at any point during the work on the previous protocols,
> so there's nothing about it in any of the specs.
This claim is plainly
On Friday, 8 July 2016 07:04:49 UTC+1, Peter Gutmann wrote:
> Various SCEP drafts have contained all sorts of stuff that was dropped when
> no-one cared about it. The "out of band"/"beyond the scope of this document"
> is standard boilerplate that's used when no-one cares enough to include it in
On Saturday, 9 July 2016 00:21:27 UTC+1, Rick Andrews wrote:
> GSA which governs FPKI recently approved Symantec’s proposal for one-way
> cross-certification with the FBCA and to remove the cross-certificate from
> the Symantec CA to the FBCA. The cross certificate is expiring on June 31,
>
On Thursday, 30 June 2016 18:13:53 UTC+1, Peter Kurrasch wrote:
> Let's be even more pointed: How do we know that *any* of the certs issued
> through this interface were issued to the right person for the right domain?
> How can StartCom make that determination?
Assuming that
* This was the
On Thursday, 30 June 2016 09:29:15 UTC+1, Rob Stradling wrote:
> The cross-certificate issued by Symantec to "Federal Bridge CA 2013"
> (https://crt.sh/?id=12638543) expires in 1 month. I'm wondering if
> there's any point in revoking this intermediate or the two other
> intermediates that
On Wednesday, 29 June 2016 04:13:59 UTC+1, Matt Palmer wrote:
> The only difference here between LE and every other CA is that issuance from
> LE is free.
Nope. StartSSL and WoSign offer free issuance, Comodo offers a free "trial"
which would be perfectly good for criminal enterprise. Symantec
On Friday, 1 July 2016 20:44:00 UTC+1, Peter Kurrasch wrote:
> Only reason I'm focusing on Let's Encrypt and ACME is because they are
> currently under review for inclusion. As far as I'm concerned all CA's with
> similar interfaces warrant this extra scrutiny.
>
> I am somewhat curious if
On Wednesday, 17 August 2016 04:24:27 UTC+1, Ryan Sleevi wrote:
> That options pretty much a non-starter for reasons best not speculated about,
> but I'm curious: Why or how would that improve the security of Mozilla users?
> And if it doesn't meaningfully improve their security, how would it
Thank you for undertaking this investigation Doug and for sharing what you
found. I am glad to hear that GlobalSign had taken action to make similar
issuances less likely in the future even before Andrew reported this.
In hindsight probably it would have been helpful to suggest to all members
On Thursday, 19 January 2017 21:46:38 UTC, Andrew Ayer wrote:
> 2. The third certificate in the list above contains a SAN for
> DNS:*.crosscert.com - note that three of the misissued example.com
> certificates contain "Crosscert" in their Subject Organization.
Crosscert aka Korea Electronic
On Monday, 23 January 2017 18:07:59 UTC, Jeremy Rowley wrote:
> What do you mean they are weak sauce? Considering at least one of the
> patents is claimed to cover the ACME challenge validations, they seem pretty
> on-point.
I thought my comparison illustrated very well what I meant by weak
On Tuesday, 24 January 2017 04:40:12 UTC, Jeremy Rowley wrote:
> And why wouldn't a request token fit the patent's interpretation of a "Pass
> String"? The only definition I saw in the patent was something generated by
> the validating entity and forwarded to the requester.
The digest of the key
On Monday, 30 January 2017 11:10:00 UTC, Gervase Markham wrote:
> Could you point is at the parts of the CPS or other documents which led
> you to that belief?
I examined a great many documents since Andrew's initial report. I think the
document which originally caused me to form this incorrect
On Monday, 30 January 2017 17:52:34 UTC, Andrew Ayer wrote:
> I would appreciate confirmation from Steve, but note that dev119money.com
> is not currently a registered domain name.
Ah yes, none of the names on that certificate currently exist in the Internet
DNS: devhkhouse.co.kr and
On Sunday, 22 January 2017 10:09:26 UTC, Lewis Resmond wrote:
> The real solution would be a CAB/BR requirement forcing the CAs not to use
> the domain validation method XYZ, once it has been proven as vulnerable.
There are no doubt an unlimited number of vulnerable methods possible. Instead,
On Friday, 27 January 2017 12:11:06 UTC, Gervase Markham wrote:
> * It's not clear what the problem is with the issuance in category F. I
> don't see any mention of "dev119money.com" in Andrew's initial report.
> Can you explain (and provide a crt.sh link)?
https://crt.sh/?id=48539119 appears to
On Sunday, 29 January 2017 02:28:53 UTC, Steve Medin wrote:
> We completed our investigation of these 12 certificates by requesting
> archived documentation. CrossCert was unable to produce documentation to
> prove their validation as required under BR 5.4.1. We revoked all 12
> certificates
On Tuesday, 17 January 2017 23:34:20 UTC, Jakob Bohm wrote:
> How about "_and versions and strong (>= 256 bits) hashes_",
Frankly any _cryptographic_ hash should be adequate for this purpose. Even for
the most creaky crypto hashes I can think of (e.g. MD4) pre-image attacks are
theoretical
On Thursday, 19 January 2017 20:20:24 UTC, Jakob Bohm wrote:
> Google's CT initiative in its current form has serious privacy problems
> for genuine certificate holders. I applaud any well-run CA that stands
> up to this attack on the Internet at large.
I notice that you have not specifically
Hello again Rob,
"ISRG Root X1" is listed as "Unconstrained id-kp-serverAuth Trust: Disclosure
is required!"
I believe this root is now (or shortly will be) trusted directly by NSS, and so
isn't an intermediate and shouldn't appear on the list.
Before it was added to NSS, it simply wasn't
On Wednesday, 31 August 2016 19:32:43 UTC+1, Kathleen Wilson wrote:
> Thanks to all of you who have provided thoughtful and constructive input into
> this discussion.
>
> I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1299579 to request
> that the "Hongkong Post e-Cert CA 1 - 10"
A recurring theme of m.d.s.policy is that a CA behaves in a way that falls
short, sometimes far short of the reasonable expectations of relying parties
and yet in the end Mozilla doesn't end up distrusting that CA because of the
direct impact on relying parties, the indirect impact on
Thanks for your feedback Gerv,
On Friday, 2 September 2016 11:19:49 UTC+1, Gervase Markham wrote:
> Have you considered what was done for CNNIC? In that case, we distrusted
> all certificates issued after a certain time. We used a whitelist for
> determining this, but it would be possible to use
On Friday, 2 September 2016 08:50:02 UTC+1, Eddy Nigg wrote:
> Lets speak about relying parties - how does this bug affect you?
As a relying party I am entitled to assume that there is no more than one
certificate signed by a particular issuer with a certain serial number. If I
have seen this
On Tuesday, 6 September 2016 08:31:33 UTC+1, Kurt Roeckx wrote:
> I would really like to see OCSP stapling as mandatory. There currently
> only seem to be around 25% of the servers that do it, and the progress
> seem to be very slow. I'm wondering if there is something we can do so
> that it's
On Tuesday, 6 September 2016 15:11:00 UTC+1, Peter Gutmann wrote:
> Why would a public CA even need cross-certification from other CAs?
Maybe this question has some subtlety to it that I'm missing?
Acceptance into root trust stores is slow. Glacial in some cases. Mozilla has a
published
On Thursday, 1 September 2016 08:54:16 UTC+1, Eddy Nigg wrote:
> Not so, rather according to my assessment, the cost and everything it
> entailed (including other risks) to fix that particular issue outweighed
> the benefits for having it fixed within a time-frame shorter than that.
It seems
On Thursday, 1 September 2016 12:48:34 UTC+1, Man Ho (Certizen) wrote:
> We did inform all subscribers back in October 2014 that SHA-1 SSL server
> cert was CEASED since 1 January 2016, and reminded each of them
> individually that SHA-1 SSL server cert will no longer be trusted by
> browsers
Responding to the scenario Jakob described which I agree is likely in outline
Let's Encrypt has seen a number of enquiries about relaxing their rate limits
or granting some sort of exception so that firmware OEMs can use Let's Encrypt
to have their devices self-issue using ACME from a name pool
On Sunday, 11 September 2016 23:42:18 UTC+1, Lee wrote:
> Me personally? Not at all. I'm just asking if they _do_ have DNSSEC
> for their domains is there a way to leverage that to get a cert via an
> encrypted channel or at least do the domain validation via an
> encrypted channel instead of
(Apologies for shortness and lack of context. My home is being redecorated so
no non-work PCs powered on)
Ryan's example doesn't work, autodiscover is a sign of MS Exchange but that
means OWA Outlook Web Access may be enabled. Which means web browsers see that
certificate.
We had a thread about the TSYS application but not for First Data.
Unlike with TSYS I don't see anything here that leaps out as problematic in the
to-be-signed certificates but I do think the moral hazard problem is larger
here than with TSYS and anyway bears revisiting.
First Data say they
On Tuesday, 4 October 2016 11:14:01 UTC+1, Rob Stradling wrote:
> Neither. I'd like to run cablint over all certs pre-issuance, but
> unfortunately it's not practical to do this yet because 1) cablint is
> too slow and 2) there are some differences of opinion that have been
> discussed at
On Tuesday, 4 October 2016 12:21:47 UTC+1, Rob Stradling wrote:
> When we are required (by CABForum and/or root program requirements) to
> do , we will of course undertake to do .
>
> There are lots of s that we are already required to do. We
> haven't tended to issue a separate announcement
On Friday, 7 October 2016 21:11:01 UTC+1, Han Yuwei wrote:
> About the auditor Ernst & Young (Hong Kong), I don't understand how did it(?)
> involved this. Can someone explain that?
Management of a public CA are oblige to state periodically that they understand
and obey various rules for
Thanks Kathleen.
I have no substantive objections to this inclusion (with only the Email trust
bit to be set) at this time but I do have a minor editorial nitpick which might
as well go back to Symantec while we're here.
On page 1 of the Introduction of the CP document, a footnote refers to
On Tuesday, 20 September 2016 01:25:59 UTC+1, Richard Wang wrote:
> This case is WoSign problem, you found out all related subordinate companies
> and all related parent companies that up to nine generations! I think this is
> NOT the best practice in the modern law-respect society.
It seems
On Tuesday, 23 August 2016 20:03:13 UTC+1, Kathleen Wilson wrote:
> Are there any other topics that I should include in this upcoming CA
> Communication?
It can be worth following-up on date-in-time commitments from those CAs in
replies to the previous communication this year. Each CA should
On Tuesday, 23 August 2016 20:03:13 UTC+1, Kathleen Wilson wrote:
> Are there any other topics that I should include in this upcoming CA
> Communication?
Also, I think that the SHA-1 topic should be brought up again. Some CA folks
will be tired of reading about this, having managed the issue
On Wednesday, 28 September 2016 18:33:07 UTC+1, Percy wrote:
> I'm assuming WoSign/StartCom pressured Tyro to remove the blog post.
> WoSign/StartCom has previously publicly threatened legal actions over the
> secret purchase.
I would say it's just as likely that Tyro's executives decided
On Tuesday, 27 September 2016 10:15:38 UTC+1, Gervase Markham wrote:
> https://tyro.com/blog/merchant-security-is-tyros-priority/
This site reproduces what I guess is an email from Tyro (can't find similar
text on their website) that suggests very strongly they weren't prepared for
SHA-1
On Sunday, 2 October 2016 11:11:34 UTC+1, Patrick Figel wrote:
> https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg04274.html
Thanks, I too could not find this in Google Groups. That is a little concerning
as I had assumed this was the authoritative source, since it's linked
On Sunday, 2 October 2016 20:53:15 UTC+1, Peter Bowen wrote:
> There is some good news. The CA/Browser Forum has already addressed
> this, even prior to the current discussions. Ballot 169
> (https://cabforum.org/2016/08/05/ballot-169-revised-validation-requirements/)
> revises 3.2.2.4
On Sunday, 25 September 2016 15:35:07 UTC+1, mono...@gmail.com wrote:
> am I the only one who a) thinks this is slightly problematic and b) is
> surprised that the cert still isn't revoked?
I don't know enough about the .sb ccTLD to be clear how problematic the
described scenario is. I would
On Monday, 10 October 2016 12:49:37 UTC+1, Gervase Markham wrote:
> I think that's an over-generalisation of my position :-) Whether sacking
> people is an acceptable response depends on what has happened.
I'm very doubtful that it is ever really relevant to the relying parties or
trust stores.
On Tuesday, 25 October 2016 21:16:36 UTC+1, Ryan Sleevi wrote:
> The linked bug is a concrete example, where an unconstrained sub-CA was
> revoked, due to non-compliance with the BRs, but has now been cross-certified
> as a constrained sub-CA. All of these non-BR compliant certificates are now
On Wednesday, 9 November 2016 09:59:10 UTC, Gervase Markham wrote:
> The current maximum lifetime of a BR cert is 39 months. 17th Feb 2013 is
> more than 39 months ago. (Even if it were previously possible to issue
> longer certs and some may still be around, those will all be SHA-1, and
> so no
On Wednesday, 9 November 2016 18:50:25 UTC, Peter Bowen wrote:
> Here are some certs that appear to be for server authentication but
> don't have that EKU:
>
> https://crt.sh/?id=10621190
I didn't look at all of these, but
* The issuer isn't trusted by Mozilla, so arguably it's out of scope in
On Wednesday, 9 November 2016 13:03:37 UTC, Gervase Markham wrote:
> On 09/11/16 12:17, Nick Lamb wrote:
>
> > I am not always very clear on how Censys queries work, but I believe this
> > query is a useful starting point (within the limited context of Censys)
> >
>
On Friday, 11 November 2016 04:47:21 UTC, Jakob Bohm wrote:
> (Example 1: Let's Encrypt is cross signed by a CA already
> in existing root stores)
In fact ISRG Root X1, the new Let's Encrypt root being trusted by Mozilla (but
so far not by any other major root trust store) is _not_ cross signed
On Thursday, 10 November 2016 19:53:25 UTC, Robin Alden wrote:
> I can't speak to your assumptions, but I concede that it is not explicit in
> the CPS.
>
> It is now documented at
> https://secure.comodo.com/api/pdf/latest/Domain%20Control%20Validation.pdf
> and in the knowledgebase article at:
On Saturday, 5 November 2016 15:56:39 UTC, Peter Bowen wrote:
> Is this a problem? Maybe. We know about the risks of pivoting, but if
> browsers disable SHA-1 that risk goes away.
The risk exists so long as anything trusts SHA-1 signatures. Disabling SHA-1 in
current versions of browsers
On Friday, 4 November 2016 19:37:07 UTC, Jeremy Rowley wrote:
> We also like the public disclosures CT requires as its been essential in
> identifying issuing CAs and non-compliances. That's probably not a surprise
> as we've always strongly supported CT. I do see the need for name redaction
On Tuesday, 18 October 2016 00:27:09 UTC+1, Kathleen Wilson wrote:
> I’m not sure what I could reasonably require (and enforce) of the CA in
> regards to communicating with their customers.
As I understand it QiHoo 360 says they intend to co-operate in order to
eventually get the new StartCom
On Friday, 14 October 2016 02:21:36 UTC+1, Matt Palmer wrote:
> Will there be any requirements around the qualification status of the logs,
> or could anyone who wanted to be "nice" just stand up a log, and have these
> CAs obtain precerts from them?
I don't think Mozilla has declared any
On Tuesday, 25 October 2016 15:45:26 UTC+1, Han Yuwei wrote:
> Is there any timetable for enforcing CAs to support embedded CT or OCSP CT?
Well, the effect of Google's policy is that if you're a subscriber looking to
obtain certificates a year from now you have three options
1. Don't care
On Friday, 21 October 2016 11:48:21 UTC+1, marc@gmail.com wrote:
> Just the opinion of a user who is securing services, websites and his mails
> with certificates but is not capable of paying hundreds of Euros / Dollars
> for achieving this goal every year.
This is the "too big to fail"
On Monday, 14 November 2016 16:57:20 UTC, Jakob Bohm wrote:
> If this is the only privacy mechanism in 6962bis, I would suggest that
> everyone not employed by either Google or another mass-monitoring
> service block its adoption on human rights grounds and on the basis of
> being a mass-attack
On Wednesday, 23 November 2016 07:25:28 UTC, Arkadiusz Ławniczak wrote:
> This means that the verification of each end-entity certificate is
> implemented within the Certum's systems and procedures. In addition, the
> entire infrastructure is under the supervision of Certum.
Thank you, this is
On Thursday, 17 November 2016 19:28:54 UTC, Brian Smith wrote:
> Let's say I screw up something and accidentally issue a certificate from my
> sub-CA for google.com or addons.mozilla.org. Because of the name
> constraints, this is a non-issue and shouldn't result in any sanctions on
> the
On Friday, 11 November 2016 19:51:28 UTC, Peter Bowen wrote:
> EV is really hard to pin down. I purposefully avoided any discussion
> of Certificate Policy and Policy Mappings extensions, as there is
> little consistency in how they are handled in WebPKI. I could add a
> clause that inclusion
On Tuesday, 15 November 2016 09:35:17 UTC, Jakob Bohm wrote:
> The HTTPS-everywhere tendency, including the plans of some people to
> completely remove unencrypted HTTP from implementations, makes it
> necessary for non-public stuff connected to the Internet to get
> Internet-compatible TLS
On Wednesday, 26 October 2016 02:31:07 UTC+1, Ryan Sleevi wrote:
> Yes. There is no obligation or expectation, presently communicated, to revoke
> extant certificates. Indeed, CAs were adamantly opposed to such a
> requirement. So these certificates will still very much be valid.
Ah yes, I had
On Wednesday, 2 November 2016 15:26:37 UTC, Tom Ritter wrote:
> There's been (some) mention that even if a user moves off Cloudflare,
> the CA is not obligated to revoke. I don't agree with that. If a user
> purchased a domain from someone (or bought a recently expired domain)
> and a TLS
On Tuesday, 11 October 2016 09:47:20 UTC+1, Gervase Markham wrote:
> I guess you could ask a trusted competitor to generate them on new
> hardware and hold the HSMs securely, then you include the roots in
> Firefox straight away, and then only tell the competitor to release the
> HSMs to CA Foo
On Thursday, 13 October 2016 20:52:54 UTC+1, Gervase Markham wrote:
> To be clear, this is a permanent ban, applicable worldwide, but only to
> the Hong Kong branch of E (If further issues are found with E
> audits elsewhere, then we might consider something with wider scope.)
Please can Mozilla
On Tuesday, 11 October 2016 01:04:14 UTC+1, Kathleen Wilson wrote:
> Why do we need a minimum of 1 year?
> What purpose does that serve?
> If they meet all our requirements earlier, why couldn't we discuss it earlier
> than 1 year?
The exact period of one year is of course arbitrary. However I
On Wednesday, 12 October 2016 14:50:22 UTC+1, Gervase Markham wrote:
> However, we would counsel all sites to move
> away from SHA-1 as the user experience will be as bad as the security.
A message I've seen from some security vendors, that I don't want us
reinforcing, is the idea that the
On Thursday, 8 December 2016 21:42:29 UTC, Jakob Bohm wrote:
> This could easily conflict with other legal obligations, such as
> requirements to license said documents under a specific other license.
>
> It would be more realistic to add wording which simply requires the
> specific things that
Thanks once again for this work Kathleen,
On Wednesday, 14 December 2016 23:12:51 UTC, Kathleen Wilson wrote:
> 1) Salesforce (in cloud) is using the default Java root store, which is
> smaller than Mozilla's root store. This accounts for the
> "sun.security.validator.ValidatorException: PKIX
By the way Gerv, in your flurry of posts to CA/B Forum public you comment
"If I were going to calculate a SHA-1 collision, the certificate of a
machine handling tens or hundreds of thousands of credit cards a day
would be a reasonably obvious target, ISTM."
This would need a second pre-image
As Ryan said, thanks for informing m.d.s.policy about this issue. I am
interested in the same general area as Ryan but I will ask my question
separately, feel free to answer them together.
Has GoDaddy been following ACME https://datatracker.ietf.org/wg/acme/charter/
development, either with a
On Wednesday, 11 January 2017 18:31:32 UTC, Ryan Sleevi wrote:
> Because you're not required to setup the webserver for
> smtp.example.com.
Ah yes, silly me
> I'm not saying they'd be right in arguing so
I suppose that from a husbanding of resources point of view it makes sense to
wait and
As mentioned previously I have been working on verifying that CAs complied with
BR 7.1.4.2.1 which requires
"Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose
subjectAlternativeName extension or Subject commonName field contains a
Reserved IP Address or Internal
On Saturday, 7 January 2017 09:08:21 UTC, Gervase Markham wrote:
> One possibility for the latter two is that Comodo and/or Symantec used
> an algorithm for detecting certs with internal names which was "no
> dots", which wouldn't have turned these up. .local is clearly a local
> domain - RFC
On Monday, 9 January 2017 14:05:25 UTC, Robin Alden wrote:
> Nick,
> Thanks for the heads-up.
> We agree that the certificates you found should have been revoked.
Thank you Robin for investigating this, for your explanation of what happened
and for the sensible response of CT logging and
On Saturday, 7 January 2017 23:22:08 UTC, Lewis Resmond wrote:
> May I ask a small offtopic question? How did you examine the certificates? Is
> there a mechanism where you can get all the *.pem files so you can check them
> with a self developed script?
Certificate Transparency logs keep
Richard's advice is worth following. m.d.s.policy is not about bugs in web
servers on the whole (and that's what you've got here most likely)
However, a quick Google suggests that "SSL record layer" is a term one popular
tool uses to describe any SSL or TLS Hello message that goes unanswered,
On Thursday, 23 February 2017 01:11:54 UTC, Richard Wang wrote:
> https://crt.sh/?id=65208905 for google.ligboy.org
Without wanting to jump on this pre-existing dogpile:
This specific example is illustrative of two important factors that should be
considered in examining the threat here:
1.
On Monday, 13 February 2017 22:40:45 UTC, Steve Medin wrote:
> With de facto use of AIA, there is no issuer installation on the server that
> could be improper. Proper is defined at the moment, either by cache or
> discovery hints.
Much as I should like ubiquitous ambient Internet to be a
On Sunday, 12 February 2017 15:28:26 UTC, Steve Medin wrote:
> A response is now available in Bugzilla 1334377 and directly at:
> https://bugzilla.mozilla.org/attachment.cgi?id=8836487
Thanks for these responses Steve,
I believe that Symantec's decision to terminate the RA Partner programme was
1 - 100 of 281 matches
Mail list logo
