Re: Underscore domains?
I am not 100% sure, but I have read that underscores can exist in domain names: https://stackoverflow.com/questions/2180465/can-domain-name-subdomains-have-an-underscore-in-it In another thread of this newsgroup, I saw a list of certificates to be revoked because of the underscore issue. And they had underscore domain names in it, either in CN or DNS-Names. So, I wonder, what's the whole forbit-underscore-certificates about? If there are domains out there with underscores, why do you want exclude them from being able to use TLS? Am Samstag, 22. Dezember 2018 03:46:01 UTC+1 schrieb Matt Palmer: > On Fri, Dec 21, 2018 at 06:14:19PM -0800, Lewis Resmond via > dev-security-policy wrote: > > I have read the debate about the underscores and I understand that they > > were never intended in the RFC. > > But I wonder, does it now mean that people who have a domain name with > > underscore will never be able to receive a certificate again? > > There are registered domains -- as in, actual eTLD+1 names -- that have > underscores in them? > > - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Underscore domains?
Hello, I have read the debate about the underscores and I understand that they were never intended in the RFC. But I wonder, does it now mean that people who have a domain name with underscore will never be able to receive a certificate again? I'm just being curious. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Telia CA - incorrect OID value
Am Freitag, 3. August 2018 10:51:34 UTC+2 schrieb pekka.la...@teliasonera.com: > Steps to fix: > 1. fix the DV profile; DONE 25-Jun-2018, no errors occurred after that > 2. reproduce all incorrect certificates any provide those to Customer; > ONGOING, planned to finnish 30-Sep-2018 > 3. revoke all incorrect ones; ONGOING, planned to finnish 30-Sep-2018 > 4. Telia CA decided to improve its testing process to avoid similar errors in > the future; DONE 6-Jul-2018 Why will the detecting/revocation process take 2 months? I think this is an extremely long time period for misissued certificates (I personally think a wrong OID is a misissurance). Also, shouldn't it be quite easy to find all wrong certificates with something like an script or query, or does it require a lot of human intervention? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Trustico code injection
Not in my opinion. If my house is burning, I expect someone to call the fire department even if I am not aware/convinced that the house is burning. The fact that they disabled their website is evidence that the Twitter posts were no fake. Am Donnerstag, 1. März 2018 20:53:16 UTC+1 schrieb Tim Shirley: > That's jumping the gun a bit. First of all they'd have to be made aware of > the suspected compromise before the 24 hour clock would start. And then > they'd need to be convinced that it actually was compromised. Since the > server has apparently been taken down, they wouldn't be able to verify these > claims themselves and I would certainly hope a CA wouldn't take such an > action based only on unverified claims on Twitter. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Verisign signed speedport.ip ?
Hello, I was researching about some older routers by Telekom, and I found out that some of them had SSL certificates for their (LAN) configuration interface, issued by Verisign for the fake-domain "speedport.ip". They (all?) are logged here: https://crt.sh/?q=speedport.ip I wonder, since this domain and even the TLD is non-existing, how could Verisign sign these? Isn't this violating the rules, if they sign anything just because a router factory tells them to do so? Although they are all expired since several years, I am interested how this could happen, and if such incidents of signing non-existing domains could still happen today. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom continues to sell untrusted certificates
Am Montag, 1. Mai 2017 16:49:32 UTC+2 schrieb Henri Sivonen: > On Mon, May 1, 2017 at 11:31 AM, Gervase Markham via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > 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 should be concerned with? > > > > "Selling untrusted certs" is not a crime, or a violation of any > > standard. Mozilla is not the global authority on what certificates may > > be issued. If StartCom are providing certificates which do not do what > > their customers expect, I'm sure those customers will let them know > > about it soon enough. > > What StartCom claims about compatibility is potentially more > Mozilla-relevant than what they are silent about. At the bottom of their > front page, it says "StartCom™ / StartSSL™is supported by:" followed by > icons. The icons include an early icon for Camino and the SeaMonkey icon. > Since Camino was discontinued before Mozilla's change in trust in StartCom > certificates, I guess having Camino there isn't technically incorrect, but > is about as relevant as having the Flock icon there. However, is it correct > to have the SeaMonkey icon there? The latest SeaMonkey release seems to > post-date the Mozilla root program's trust change in StartCom certificates. > (But then, it seems that there have been a number of Firefox ESR security > patch releases that post-date the SeaMonkey release. Is SeaMonkey still > active, despite appearing not to ship Gecko security updates, and does > SeaMonkey implement the same trust special-casing as Firefox? It seems to > produce nightlies still.) > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ It seems like they have removed the icons. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
