Re: CA scope transparency (was Re: Name-constraining government CAs, or not)
On Wednesday 10 June 2015 07:28:06 Rick Andrews wrote: > I don't understand. The domain owner/admin is not a third party. the third party in question was an entity running the CT service and since they can produce a certificate signed by a trusted CA as a proof of misissuance, the data itself is also trusted. Independent of your trust of the third party. > > -Rick > > > > On Jun 10, 2015, at 4:01 AM, Hubert Kario wrote: > > > > > >> On Tuesday 09 June 2015 11:57:40 Rick Andrews wrote: > >> > >>> On Tuesday, June 9, 2015 at 3:05:30 AM UTC-7, Hubert Kario wrote: > >>> True, OTOH, if a third party says that there was a misissuance, that > >>> means > >>> there was one. > >> > >> > >> I disagree. Only the domain owner knows for sure what is a misissuance, > >> and what isn't. It seems likely that I might turn over all known certs > >> for my domain to the third party, but they might find another one, and I > >> might say "oh, yeah, I forgot about that one". So a third party can only > >> report to the domain owner, but cannot know if the cert is legitimate. > > > > > > the implied situation was that the tool is run by the domain owner/admin > > > > -- > > Regards, > > Hubert Kario > > Quality Engineer, QE BaseOS Security team > > Web: www.cz.redhat.com > > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA scope transparency (was Re: Name-constraining government CAs, or not)
I don't understand. The domain owner/admin is not a third party. -Rick > On Jun 10, 2015, at 4:01 AM, Hubert Kario wrote: > >> On Tuesday 09 June 2015 11:57:40 Rick Andrews wrote: >>> On Tuesday, June 9, 2015 at 3:05:30 AM UTC-7, Hubert Kario wrote: >>> True, OTOH, if a third party says that there was a misissuance, that means >>> there was one. >> >> I disagree. Only the domain owner knows for sure what is a misissuance, and >> what isn't. It seems likely that I might turn over all known certs for my >> domain to the third party, but they might find another one, and I might say >> "oh, yeah, I forgot about that one". So a third party can only report to >> the domain owner, but cannot know if the cert is legitimate. > > the implied situation was that the tool is run by the domain owner/admin > > -- > Regards, > Hubert Kario > Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New certificate search tool - crt.sh
On 03/06/15 16:46, Rob Stradling wrote: On 03/06/15 16:15, Richard Barnes wrote: David Keeler has done some work on visualizing certs that may be helpful. http://people.mozilla.org/~dkeeler/certsplainer/ https://github.com/mozkeeler/certsplainer I'll take a look. Thanks. Hi Richard. I've been looking at certsplainer. There seem to be no limits on what you can do with JavaScript these days! BTW, https://crt.sh now has a certificate ASN.1 dump feature, powered by asn1js. :-) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New certificate search tool - crt.sh
On Tuesday 09 June 2015 10:53:37 Rob Stradling wrote: > On 08/06/15 15:09, Rob Stradling wrote: > > On 08/06/15 14:54, Hubert Kario wrote: > >> On Wednesday 03 June 2015 09:43:23 Eric Mill wrote: > >>> This is outstanding - simple, but totally what people need to start > >>> getting > >>> the idea and benefit of CT. > >>> > >>> One high ROI addition might be RSS feeds for search terms. That way, I > >>> could create e.g. an IFTTT alert that emails me whenever a > >>> certificate is > >>> publicly logged as being issued for my domains. > >>> > >>> -- Eric > >> > >> +1 on the awesome tool > > > > Thanks Hubert. :-) > > > >> and I would like to propose to extend the RSS to a general web API (JSON) > > > > Makes sense. I've added this to my to-do list. > > Hubert, I think a standard API for interfacing with CT monitors would be > a bigger win than an API that's specific to https://crt.sh. See the > message I just posted to the "CA scope transparency" thread. I agree, but we need to start from somewhere. and starting with a versioned API, that is precisely defined and documented, on the crt.sh website would be, IMHO, a good way to do that > >>> On Wed, Jun 3, 2015 at 8:56 AM, Rob Stradling > >>> > >>> wrote: > Hi. I thought folks here might find this useful. It's a web interface > that lets you search for certs that have been logged by CT. > > https://crt.sh > > Pronounced "search". :-) -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA scope transparency (was Re: Name-constraining government CAs, or not)
On Tuesday 09 June 2015 11:57:40 Rick Andrews wrote: > On Tuesday, June 9, 2015 at 3:05:30 AM UTC-7, Hubert Kario wrote: > > True, OTOH, if a third party says that there was a misissuance, that means > > there was one. > > I disagree. Only the domain owner knows for sure what is a misissuance, and > what isn't. It seems likely that I might turn over all known certs for my > domain to the third party, but they might find another one, and I might say > "oh, yeah, I forgot about that one". So a third party can only report to > the domain owner, but cannot know if the cert is legitimate. the implied situation was that the tool is run by the domain owner/admin -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA scope transparency (was Re: Name-constraining government CAs, or not)
On Wed, Jun 10, 2015 at 10:53:30AM +0100, Rob Stradling wrote: > On 10/06/15 01:54, Matt Palmer wrote: > >A log has a single well-defined purpose, and I don't think that adding > >independent > >functionality to the purpose of the log itself is a winning strategy. > > Indeed. A log and a monitor are separate software components. > > Sorry I was unclear. I was imagining that a provider might want to provide > both a log and a monitor for that log, running from the same server, using a > shared database. (IMHO, we shouldn't require this, but we shouldn't > prohibit it either). I must say, I'd never thought that anyone would try to forbid an entity running a log from also running a monitor. Its value, at least insofar as it is attempting to detect malfeasance of the log operator, may be quite limited, but that's for the users of the monitor service to decide for themselves. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA scope transparency (was Re: Name-constraining government CAs, or not)
On 10/06/15 01:54, Matt Palmer wrote: On Tue, Jun 09, 2015 at 10:44:58AM +0100, Rob Stradling wrote: On 09/06/15 04:05, Clint Wilson wrote: To further support your claims here, Chris, there are already tools coming out which actively monitor domains in CT logs and can be set up with notifications of misissuance: https://www.digicert.com/certificate-monitoring/ https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/EPv_u9V06n0 This type of tool for CT is only going to improve with time. So I'm wondering if the TRANS WG should think about standardizing a JSON API for searching CT logs and for setting up notifications of (mis-)issuance. The server side of this API could be implemented by services such as https://crt.sh or even directly by the logs themselves. For logs themselves, as a requirement for *being* a log? No. Fully agree. A log has a single well-defined purpose, and I don't think that adding independent functionality to the purpose of the log itself is a winning strategy. Indeed. A log and a monitor are separate software components. Sorry I was unclear. I was imagining that a provider might want to provide both a log and a monitor for that log, running from the same server, using a shared database. (IMHO, we shouldn't require this, but we shouldn't prohibit it either). An API for querying the CT-relevant data for a collection of certificates... *that* would probably be quite useful. :-) BTW, you probably won't be surprised to hear that I've been trying to think of reasons to create a shell script called "crt.sh". ;-) Nope, not particularly surprised. :-) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA scope transparency (was Re: Name-constraining government CAs, or not)
On 10/06/15 01:46, Matt Palmer wrote: On Tue, Jun 09, 2015 at 12:00:23PM -0700, Rick Andrews wrote: On Tuesday, June 9, 2015 at 7:45:05 AM UTC-7, Kurt Roeckx wrote: On 2015-06-09 15:26, Peter Kurrasch wrote: 3) How frequently might such tools run? Or to put it differently, how much time do I probably have between when I issue a gmail cert and when someone figures it out (and of course how much longer before my illegitimate cert is no longer valid)? I need only 24 hours to do all the damage I want, but in a pinch I'll make do with 8. CT allows to store precertificate. That is, the CA says it intents to issue a certificate. Should we mandate the use of precertificates and a minimum time between the precertificate and the real certificate? Kirk, The reason the CT designers invented SCTs was because the CAs weren't happy with the idea of CT imposing delays on certificate issuance. The long term hope/expectation is that precertificates will become less and less common, as more and more webservers are enhanced to support the CT TLS extension and/or OCSP Stapling. So the idea of requiring precertificates to be used is a non-starter, IMHO. Also, note that CT is intended to help detect, not prevent, certificate misissuance. Absolutely not. If a CA is unable to get the required minimum number of SCTs, it will likely not issue the cert (sure, it may retry, but it's possible that retries fail too). Logging must be seen as intent, but not a guarantee of issuance. A minimum time doesn't imply a maximum (or, rather, a finite maximum). From your perspective, I'd object on another basis: any non-trivial delay in issuance degrades the user experience of those acquiring certificates. As a consumer of CA services, I wouldn't want to have to wait (say) 3 days to get my DV cert, just because of CT requirements. Indeed so, Matt. That's precisely why the CAs lobbied against delays on certificate issuance. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA scope transparency (was Re: Name-constraining government CAs, or not)
On Tue, Jun 09, 2015 at 10:44:58AM +0100, Rob Stradling wrote: > On 09/06/15 04:05, Clint Wilson wrote: > >To further support your claims here, Chris, there are already tools coming > >out which actively monitor domains in CT logs and can be set up with > >notifications of misissuance: > >https://www.digicert.com/certificate-monitoring/ > >https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/EPv_u9V06n0 > > > >This type of tool for CT is only going to improve with time. > > So I'm wondering if the TRANS WG should think about standardizing a JSON API > for searching CT logs and for setting up notifications of (mis-)issuance. > The server side of this API could be implemented by services such as > https://crt.sh or even directly by the logs themselves. For logs themselves, as a requirement for *being* a log? No. A log has a single well-defined purpose, and I don't think that adding independent functionality to the purpose of the log itself is a winning strategy. An API for querying the CT-relevant data for a collection of certificates... *that* would probably be quite useful. > BTW, you probably won't be surprised to hear that I've been trying to think > of reasons to create a shell script called "crt.sh". ;-) Nope, not particularly surprised. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA scope transparency (was Re: Name-constraining government CAs, or not)
On Tue, Jun 09, 2015 at 08:26:55AM -0500, Peter Kurrasch wrote: > 1) How to exclude domains from the search? For example I want to find > gmail certs but exclude something like "eggmail" which could be a false > positive. Constrain your search to "domains which have a name part which is exactly 'gmail'". > 2) How to address wild cards? For example can I bypass these detection > tools by issuing a cert for "*[dot]innocentdomain[dot]com" instead of > "gmail[dot]innocentdomain[dot]com"? Fun times. > 3) How frequently might such tools run? Or to put it differently, how much > time do I probably have between when I issue a gmail cert and when someone > figures it out (and of course how much longer before my illegitimate cert > is no longer valid)? I need only 24 hours to do all the damage I want, > but in a pinch I'll make do with 8. How frequently does the consumer of such services *want* the tool to run? > 4) What's the expected model for a third-party monitor? Who might the > organizations be and how might the monitoring be funded? People give the monitor money. The monitor protects their interests. > In a way the SSL Labs service is a perfect example of the limitations of a > monitoring service. Their SSL Pulse found an awful lot of servers with > a failing grade. Luckily, CT doesn't aim to fix every Goober-with-Apache; it's main benefit is in providing sunshine on CA operations, and making it easier to provide complete evidence of malfeasance or incompetence. - Matt -- My favourite was some time ago, and involved a female customer thanking "Mr. Daemon" for his effort trying to deliver her mail, and offering him a "good time" if he ever visited Sydney. -- Matt McLeod ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA scope transparency (was Re: Name-constraining government CAs, or not)
On Tue, Jun 09, 2015 at 12:00:23PM -0700, Rick Andrews wrote: > On Tuesday, June 9, 2015 at 7:45:05 AM UTC-7, Kurt Roeckx wrote: > > On 2015-06-09 15:26, Peter Kurrasch wrote: > > > 3) How frequently might such tools run? Or to put it differently, how > > > much time do I probably have between when I issue a gmail cert and when > > > someone figures it out (and of course how much longer before my > > > illegitimate cert is no longer valid)? I need only 24 hours to do all the > > > damage I want, but in a pinch I'll make do with 8. > > > > CT allows to store precertificate. That is, the CA says it intents to > > issue a certificate. Should we mandate the use of precertificates and a > > minimum time between the precertificate and the real certificate? > > Absolutely not. If a CA is unable to get the required minimum number of > SCTs, it will likely not issue the cert (sure, it may retry, but it's > possible that retries fail too). Logging must be seen as intent, but not > a guarantee of issuance. A minimum time doesn't imply a maximum (or, rather, a finite maximum). From your perspective, I'd object on another basis: any non-trivial delay in issuance degrades the user experience of those acquiring certificates. As a consumer of CA services, I wouldn't want to have to wait (say) 3 days to get my DV cert, just because of CT requirements. - Matt -- Advocating Object-Oriented Programming is like advocating Pants-Oriented Clothing. -- Jacob Gabrielson ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
