Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com
On 2017-12-09 at 08:59 -0700, Wayne Thayer wrote: > It can be confusing even for people following these things. That's where I > think collecting problem reporting info from audited sub-CAs in CCADB would > help. > > For everyone else, finding the correct problem reporting information is > mostly a matter of luck. Perhaps we should require an email address be > included in the end-entity certificate? Unless that info was exposed in the > browser, it would still be difficult to find, but at least it would then be > in a consistent location. Rather than an email, I think it should be a url. That could be an email through the use of mailto:, but I suspect CAs will find preferable to provide a web page where they explain what it is for, how to submit, etc. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Verisign signed speedport.ip ?
On Sat, Dec 9, 2017 at 11:42 AM, Lewis Resmond via dev-security-policy wrote: > 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. Before the CA/Browser Forum Baseline Requirements were created, this was not explicitly forbidden. Since approximately July 1, 2012 no new certificates have been allowed for unqualified names or names for which the TLD does not exist in the IANA root zone. So, to answer your questions: Q: How could Verisign sign these? A: These were all issued prior to the Baseline Requirements coming into effect Q: Could [...] such incidents of signing non-existing domains could still happen today? A: Not like this. All Domain Names in certificates now must be Fully Qualified Domains and the CA must validate that the FQDN falls in a valid namespace. It is allowable for me to get a certificate for nonexistent.home.peterbowen.org, even though that FQDN does not exist, as I am the registrant of peterbowen.org. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Verisign signed speedport.ip ?
Until November 11, 2015, publicly-trusted CAs were allowed to issue certificates for internal names and reserved IP addresses. All certificates of this nature had to be revoked by October 1, 2016. More details here: https://cabforum.org/internal-names/ Patrick On 09.12.17 20:42, Lewis Resmond via dev-security-policy wrote: > 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 > ___ 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
CA generated keys
Apologies for the new thread. It's difficult for me to reply to messages that were sent before I joined Digicert. With respect to CA generated SSL keys, there are a few points that I feel should be considered. First, third parties who are *not* CAs can run key generation and escrow services, and then the third party service can apply for a certificate for the key, and deliver the certificate and the key to a customer. I'm not sure how this could be prevented. So if this actually did end up being a Mozilla policy, the practical effect would be that SSL keys can be generated by third parties and escrowed, *UNLESS* that party is trusted by Mozilla. This seems . backwards, at best. Second, although I strongly believe that in general, as a best practice, keys should be generated by the device/entity it belongs to whenever possible, we've seen increasing evidence that key generation is difficult and many devices cannot do it securely. I doubt that forcing the owner of the device to generate a key on a commodity PC is any better (it's probably worse). With an increasing number of small devices running web servers, keys generated by audited, trusted third parties under whatever rules Mozilla chooses to enforce about secure key delivery may actually in many circumstances be superior than what would happen if the practice is banned. -Tim smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com
On 12/09/2017 01:50 AM, Kurt Roeckx via dev-security-policy wrote: > But it's not obvious to me who to contact to revoke a given > certifiate, and it would be really useful that given a certificate > it would be obvious what to do, who to contact, to get it revoked. Could it be useful to establish a practice of including such contact information in the certificate itself, e.g. requiring a URI in some standardized key containing the contact point? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com
It can be confusing even for people following these things. That's where I think collecting problem reporting info from audited sub-CAs in CCADB would help. For everyone else, finding the correct problem reporting information is mostly a matter of luck. Perhaps we should require an email address be included in the end-entity certificate? Unless that info was exposed in the browser, it would still be difficult to find, but at least it would then be in a consistent location. It may be related to that bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1418451 The certificate or a easily accessible public database should contains the information of who really is responsible for the issuance and revocation of the certificate. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com
On Sat, Dec 9, 2017 at 7:50 AM, Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Sat, 9 Dec 2017 09:51:59 +0100 > Hanno Böck via dev-security-policy > wrote: > > > On Fri, 8 Dec 2017 16:43:48 -0700 > > Wayne Thayer via dev-security-policy > > wrote: > > > > > The root CA is ultimately responsible for subordinate CAs it has > > > signed. > > > > I see a problem with that, as this is far from obvious. > > I saw "responsibility" here as meaning responsibility to the Trust > Stores on behalf of the Relying Parties. For the Relying Parties > themselves I think the right pattern is: Try filing a Problem Report > with the Issuer, if the result isn't satisfactory, complain to your > Trust Store(s). We can do the rest, can we not? > > Yes, I think we're talking about two separate problems. I was looking at this from Mozilla's perspective. > > > I'm mostly not concerned about the people following these things > > closely and are members of this list, but about random other people who > > happen to find problems. It surely seems beneficial for the certificate > > ecosystem to make sure that they can easily find the right place to > > report problems. It can be confusing even for people following these things. That's where I think collecting problem reporting info from audited sub-CAs in CCADB would help. For everyone else, finding the correct problem reporting information is mostly a matter of luck. Perhaps we should require an email address be included in the end-entity certificate? Unless that info was exposed in the browser, it would still be difficult to find, but at least it would then be in a consistent location. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com
On Sat, 9 Dec 2017 09:51:59 +0100 Hanno Böck via dev-security-policy wrote: > On Fri, 8 Dec 2017 16:43:48 -0700 > Wayne Thayer via dev-security-policy > wrote: > > > The root CA is ultimately responsible for subordinate CAs it has > > signed. > > I see a problem with that, as this is far from obvious. I saw "responsibility" here as meaning responsibility to the Trust Stores on behalf of the Relying Parties. For the Relying Parties themselves I think the right pattern is: Try filing a Problem Report with the Issuer, if the result isn't satisfactory, complain to your Trust Store(s). We can do the rest, can we not? The Trust Stores have just as much reason to distrust a root CA which can't keep its subCAs from breaking the rules as they do if this root CA were to break the rules directly themselves. That's sort-of the lesson from Symantec too, right albeit in their case the problem was RAs? It should be in the Root CA's interest to make sure that every sub-ordinate CA, whether physically under its control or not, is properly operated, and if there's a suspicion that it's not being properly operated, to get that sorted out. Handling problem reports is part of the proper operation of the CA. It may be that root CAs decide the best way to _achieve_ this objective [for a subCA they don't actually intend as simply a cross-signature to bootstrap another root] is to insist upon being the point of contact for Problem Reports, and they'll pass them on, so this way they have oversight. Or that they insist on the Problem Reports going to an alias, Exchange DL or similar that sends a copy to the root CA, I don't think we need to dictate how this is done, only to re-emphasise that as the root CA making sure the Problem Reports are handled properly is ultimately your responsibility, however you discharge it, not a situation for buck passing. We definitely mustn't be shy about problems affecting another business with a Trust Store. If Microsoft's executive management has any sense there is an institutional firewall between their Trust Store and their Certificate Authority functions, and the former is able to make decisions independent of their potential impact on the latter. If a root CA finds that it is politically uncomfortable to have two very different relationships (Programme Member: Trust Programme / CA: subCA) to the same public company, well, that's unfortunate, and I would suggest the less awkward way forward is to bring the subCA relationship to an ordered close. Perhaps Microsoft shouldn't be in both games (and if so, the same for Google), but that again is not a problem for Mozilla. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com
On Fri, 8 Dec 2017 16:43:48 -0700 Wayne Thayer via dev-security-policy wrote: > The root CA is ultimately responsible for subordinate CAs it has > signed. I see a problem with that, as this is far from obvious. If a random person discovers a problem with a certificate it seems quite natural to go to the place that issued it. If you see a certificate issued by Microsoft then why would you believe that anyone other than Microsoft is responsible for that? (Add to that that in order to find out that it's ultimately Digicert that is responsible you'd have to first figure out that the root is "Baltimore Cybertrust", then figure out that this is a company that no longer exists and that the root has been bought by Digicert at some point.) IMHO we're seeing a very problematic practice here. On the one Hand CAs offer that companies can get their own "branded" certificates that are "issued" by them, on the other hand that's not really the case and all the responsibility is still with the CA. For the user - and also for potential reporters of security problems - this is obfuscating things. I'm mostly not concerned about the people following these things closely and are members of this list, but about random other people who happen to find problems. It surely seems beneficial for the certificate ecosystem to make sure that they can easily find the right place to report problems. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy