info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Violation report - Comodo CA certificates revocation delays
974 views
Skip to first unread message
please please
Sep 16, 2018, 11:30:23 PM9/16/18
to dev-secur...@lists.mozilla.org
Hello, I am the domain owner of debigare.com. I would like to make you aware that Comodo CA took more than 5 days to revoke certificates they had signed for my domain and subdomains after requesting them to do through their sslabuse email address, past the 24 hours maximum mentioned in the Baseline Requirements as stipulated in section 4.9.1.1.
For context, I was previously using Cloudflare's Universal SSL feature, but disabling it did not revoke the old certificates that had not yet expired, but simply removed them from its system, and some of the certificates were still valid for more than 6 months.
I first attempted to contact Cloudflare's support to ask them to revoke the certificates themselves on September 6 at 7:43 UTC. This only led to irrelevant responses and confused customer support agents that had no idea what I was talking about, and this appeared to go nowhere. I eventually got a response from them on September 11 at 5:53 UTC that they would request CAs to perform the revocation, but that was after I did so myself, and I never got a status report back afterwards.
There were two CAs affected by this issue. The vast majority of certificates were signed by Comodo CA, and the rest by DigiCert. I did not run into any issues with DigiCert (they in fact proactively checked with Cloudflare my claim and revoked the certificates before I even had the chance to attempt their domain ownership challenge), but Comodo CA was another story entirely.
My first request to Comodo CA to revoke the certificates for debigare.com and all of its subdomains was on September 8 at 4:37 UTC. I did not get a reply until September 9 at 15:53 UTC stating that the certificates have been revoked. Not only was this past the 24 hours requirement, but it was also false, as only the most recent certificates had been revoked, not all of them. I mentioned to them their mistake on September 10 at 5:55 UTC with a full list of affected certificates just in case my initial request was unclear to them, and never got a reply back. I did, however, notice that the certificates eventually got revoked on September 13 at 16:04 UTC according to their Certificate Transparency logs, a fact that I only discovered on September 15. Assuming the log is correct, that would be a delay of more than 3 days after notifying them of the incomplete revocation, more than 5 days after my initial request to them, and more than a week until I finally noticed the problem was fixed. It's also worth noting that throughout this entire series of events, Comodo CA never requested proof of domain ownership beyond the evidence I initially provided, so that cannot explain the delays.
One detail that I'm not sure about is why my initial evidence for domain ownership was apparently sufficient for Comodo CA but not for DigiCert. On this regard, the only evidence I provided to both of them was that the email address I used to contact them matched the contact information on my website. (My emails were protected with SPF, DKIM and DMARC for authenticity.) For some reason, DigiCert believed that this evidence did not met the Baseline Requirements for my request, a claim that I am currently unable to verify as I cannot find anything of the sort in them.
You can read the full story on my blog, which I hope will be sufficient to prove my identity: https://www.debigare.com/4-unexpected-issues-i-encountered-upon-switching-web-hosts/
I can also provide a full copy of the email exchange I had with Comodo CA as evidence on request.
Guillaume Fortin-Debigaré
For context, I was previously using Cloudflare's Universal SSL feature, but disabling it did not revoke the old certificates that had not yet expired, but simply removed them from its system, and some of the certificates were still valid for more than 6 months.
I first attempted to contact Cloudflare's support to ask them to revoke the certificates themselves on September 6 at 7:43 UTC. This only led to irrelevant responses and confused customer support agents that had no idea what I was talking about, and this appeared to go nowhere. I eventually got a response from them on September 11 at 5:53 UTC that they would request CAs to perform the revocation, but that was after I did so myself, and I never got a status report back afterwards.
There were two CAs affected by this issue. The vast majority of certificates were signed by Comodo CA, and the rest by DigiCert. I did not run into any issues with DigiCert (they in fact proactively checked with Cloudflare my claim and revoked the certificates before I even had the chance to attempt their domain ownership challenge), but Comodo CA was another story entirely.
My first request to Comodo CA to revoke the certificates for debigare.com and all of its subdomains was on September 8 at 4:37 UTC. I did not get a reply until September 9 at 15:53 UTC stating that the certificates have been revoked. Not only was this past the 24 hours requirement, but it was also false, as only the most recent certificates had been revoked, not all of them. I mentioned to them their mistake on September 10 at 5:55 UTC with a full list of affected certificates just in case my initial request was unclear to them, and never got a reply back. I did, however, notice that the certificates eventually got revoked on September 13 at 16:04 UTC according to their Certificate Transparency logs, a fact that I only discovered on September 15. Assuming the log is correct, that would be a delay of more than 3 days after notifying them of the incomplete revocation, more than 5 days after my initial request to them, and more than a week until I finally noticed the problem was fixed. It's also worth noting that throughout this entire series of events, Comodo CA never requested proof of domain ownership beyond the evidence I initially provided, so that cannot explain the delays.
One detail that I'm not sure about is why my initial evidence for domain ownership was apparently sufficient for Comodo CA but not for DigiCert. On this regard, the only evidence I provided to both of them was that the email address I used to contact them matched the contact information on my website. (My emails were protected with SPF, DKIM and DMARC for authenticity.) For some reason, DigiCert believed that this evidence did not met the Baseline Requirements for my request, a claim that I am currently unable to verify as I cannot find anything of the sort in them.
You can read the full story on my blog, which I hope will be sufficient to prove my identity: https://www.debigare.com/4-unexpected-issues-i-encountered-upon-switching-web-hosts/
I can also provide a full copy of the email exchange I had with Comodo CA as evidence on request.
Guillaume Fortin-Debigaré
Wayne Thayer
Sep 17, 2018, 8:10:04 PM9/17/18
to pleasei...@hotmail.com, MDSP
I have created a bug and requested a response from Comodo:
https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
As noted, there are no specific requirements regarding how CAs validate
revocation requests in the BRs. Every CA may do this however they choose,
so I don't believe there is any action required in regard to DigiCert's
response to their problem report.
- Wayne
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
As noted, there are no specific requirements regarding how CAs validate
revocation requests in the BRs. Every CA may do this however they choose,
so I don't believe there is any action required in regard to DigiCert's
response to their problem report.
- Wayne
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
please please
Sep 17, 2018, 11:51:02 PM9/17/18
to Wayne Thayer, MDSP
Good to know, and thank you very much for following up on this!
Small update by the way: I finally received a reply from Comodo CA confirming their 2nd wave of revocations a few hours ago, on September 17 at 16:55 UTC to be exact. Strangely, it was in response to an email where I informed them that I had already noticed they fully completed my revocation request. I don't think it's a relevant detail but I wanted to mention it to avoid any potential confusion.
Guillaume Fortin-Debigaré
________________________________
From: Wayne Thayer <wth...@mozilla.com>
Sent: September 17, 2018 20:09
To: pleasei...@hotmail.com
Cc: MDSP
Subject: Re: Violation report - Comodo CA certificates revocation delays
I have created a bug and requested a response from Comodo: https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
As noted, there are no specific requirements regarding how CAs validate revocation requests in the BRs. Every CA may do this however they choose, so I don't believe there is any action required in regard to DigiCert's response to their problem report.
- Wayne
On Sun, Sep 16, 2018 at 8:30 PM please please via dev-security-policy <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>> wrote:
Hello, I am the domain owner of debigare.com<http://debigare.com>. I would like to make you aware that Comodo CA took more than 5 days to revoke certificates they had signed for my domain and subdomains after requesting them to do through their sslabuse email address, past the 24 hours maximum mentioned in the Baseline Requirements as stipulated in section 4.9.1.1.
For context, I was previously using Cloudflare's Universal SSL feature, but disabling it did not revoke the old certificates that had not yet expired, but simply removed them from its system, and some of the certificates were still valid for more than 6 months.
I first attempted to contact Cloudflare's support to ask them to revoke the certificates themselves on September 6 at 7:43 UTC. This only led to irrelevant responses and confused customer support agents that had no idea what I was talking about, and this appeared to go nowhere. I eventually got a response from them on September 11 at 5:53 UTC that they would request CAs to perform the revocation, but that was after I did so myself, and I never got a status report back afterwards.
There were two CAs affected by this issue. The vast majority of certificates were signed by Comodo CA, and the rest by DigiCert. I did not run into any issues with DigiCert (they in fact proactively checked with Cloudflare my claim and revoked the certificates before I even had the chance to attempt their domain ownership challenge), but Comodo CA was another story entirely.
My first request to Comodo CA to revoke the certificates for debigare.com<http://debigare.com> and all of its subdomains was on September 8 at 4:37 UTC. I did not get a reply until September 9 at 15:53 UTC stating that the certificates have been revoked. Not only was this past the 24 hours requirement, but it was also false, as only the most recent certificates had been revoked, not all of them. I mentioned to them their mistake on September 10 at 5:55 UTC with a full list of affected certificates just in case my initial request was unclear to them, and never got a reply back. I did, however, notice that the certificates eventually got revoked on September 13 at 16:04 UTC according to their Certificate Transparency logs, a fact that I only discovered on September 15. Assuming the log is correct, that would be a delay of more than 3 days after notifying them of the incomplete revocation, more than 5 days after my initial request to them, and more than a week until I finally noticed the problem was fixed. It's also worth noting that throughout this entire series of events, Comodo CA never requested proof of domain ownership beyond the evidence I initially provided, so that cannot explain the delays.
One detail that I'm not sure about is why my initial evidence for domain ownership was apparently sufficient for Comodo CA but not for DigiCert. On this regard, the only evidence I provided to both of them was that the email address I used to contact them matched the contact information on my website. (My emails were protected with SPF, DKIM and DMARC for authenticity.) For some reason, DigiCert believed that this evidence did not met the Baseline Requirements for my request, a claim that I am currently unable to verify as I cannot find anything of the sort in them.
You can read the full story on my blog, which I hope will be sufficient to prove my identity: https://www.debigare.com/4-unexpected-issues-i-encountered-upon-switching-web-hosts/
I can also provide a full copy of the email exchange I had with Comodo CA as evidence on request.
Guillaume Fortin-Debigaré
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy
Small update by the way: I finally received a reply from Comodo CA confirming their 2nd wave of revocations a few hours ago, on September 17 at 16:55 UTC to be exact. Strangely, it was in response to an email where I informed them that I had already noticed they fully completed my revocation request. I don't think it's a relevant detail but I wanted to mention it to avoid any potential confusion.
Guillaume Fortin-Debigaré
________________________________
From: Wayne Thayer <wth...@mozilla.com>
Sent: September 17, 2018 20:09
To: pleasei...@hotmail.com
Cc: MDSP
Subject: Re: Violation report - Comodo CA certificates revocation delays
I have created a bug and requested a response from Comodo: https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
As noted, there are no specific requirements regarding how CAs validate revocation requests in the BRs. Every CA may do this however they choose, so I don't believe there is any action required in regard to DigiCert's response to their problem report.
- Wayne
Hello, I am the domain owner of debigare.com<http://debigare.com>. I would like to make you aware that Comodo CA took more than 5 days to revoke certificates they had signed for my domain and subdomains after requesting them to do through their sslabuse email address, past the 24 hours maximum mentioned in the Baseline Requirements as stipulated in section 4.9.1.1.
For context, I was previously using Cloudflare's Universal SSL feature, but disabling it did not revoke the old certificates that had not yet expired, but simply removed them from its system, and some of the certificates were still valid for more than 6 months.
I first attempted to contact Cloudflare's support to ask them to revoke the certificates themselves on September 6 at 7:43 UTC. This only led to irrelevant responses and confused customer support agents that had no idea what I was talking about, and this appeared to go nowhere. I eventually got a response from them on September 11 at 5:53 UTC that they would request CAs to perform the revocation, but that was after I did so myself, and I never got a status report back afterwards.
There were two CAs affected by this issue. The vast majority of certificates were signed by Comodo CA, and the rest by DigiCert. I did not run into any issues with DigiCert (they in fact proactively checked with Cloudflare my claim and revoked the certificates before I even had the chance to attempt their domain ownership challenge), but Comodo CA was another story entirely.
One detail that I'm not sure about is why my initial evidence for domain ownership was apparently sufficient for Comodo CA but not for DigiCert. On this regard, the only evidence I provided to both of them was that the email address I used to contact them matched the contact information on my website. (My emails were protected with SPF, DKIM and DMARC for authenticity.) For some reason, DigiCert believed that this evidence did not met the Baseline Requirements for my request, a claim that I am currently unable to verify as I cannot find anything of the sort in them.
You can read the full story on my blog, which I hope will be sufficient to prove my identity: https://www.debigare.com/4-unexpected-issues-i-encountered-upon-switching-web-hosts/
I can also provide a full copy of the email exchange I had with Comodo CA as evidence on request.
Guillaume Fortin-Debigaré
_______________________________________________
dev-security-policy mailing list
https://lists.mozilla.org/listinfo/dev-security-policy
please please
Oct 10, 2018, 8:31:02 PM10/10/18
to Wayne Thayer, MDSP
Any update behind the scenes about this issue? I've noticed that the soft limit to fill an Incident Report expired more than a week ago, and I'm starting to be a bit worried that some of the evidence in the CT logs might disappear if the investigation is not completed before December 6th, the earliest expiration date among the affected certificates.
Guillaume Fortin-Debigaré
________________________________
From: please please <pleasei...@hotmail.com>
Sent: September 17, 2018 23:39
To: Wayne Thayer
Guillaume Fortin-Debigaré
________________________________
From: please please <pleasei...@hotmail.com>
Sent: September 17, 2018 23:39
To: Wayne Thayer
Wayne Thayer
Oct 11, 2018, 1:54:16 PM10/11/18
to pleasei...@hotmail.com, MDSP
I just poked Comodo in the bug -
https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
CT Logs are designed such that certificates cannot be removed from them.
The evidence will not disappear once the certificates expire.
On Wed, Oct 10, 2018 at 5:26 PM please please <pleasei...@hotmail.com>
wrote:
> Any update behind the scenes about this issue? I've noticed that the soft
> limit to fill an Incident Report expired more than a week ago, and I'm
> starting to be a bit worried that some of the evidence in the CT logs might
> disappear if the investigation is not completed before December 6th, the
> earliest expiration date among the affected certificates.
>
> Guillaume Fortin-Debigaré
> ------------------------------
> *From:* please please <pleasei...@hotmail.com>
> *Sent:* September 17, 2018 23:39
> *To:* Wayne Thayer
> *Cc:* MDSP
> *Subject:* Re: Violation report - Comodo CA certificates revocation delays
> *From:* Wayne Thayer <wth...@mozilla.com>
> *Sent:* September 17, 2018 20:09
> *To:* pleasei...@hotmail.com
> *Cc:* MDSP
> *Subject:* Re: Violation report - Comodo CA certificates revocation delays
>
> Hello, I am the domain owner of debigare.com. I would like to make you
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
CT Logs are designed such that certificates cannot be removed from them.
The evidence will not disappear once the certificates expire.
On Wed, Oct 10, 2018 at 5:26 PM please please <pleasei...@hotmail.com>
wrote:
> Any update behind the scenes about this issue? I've noticed that the soft
> limit to fill an Incident Report expired more than a week ago, and I'm
> starting to be a bit worried that some of the evidence in the CT logs might
> disappear if the investigation is not completed before December 6th, the
> earliest expiration date among the affected certificates.
>
> Guillaume Fortin-Debigaré
> *From:* please please <pleasei...@hotmail.com>
> *Sent:* September 17, 2018 23:39
> *To:* Wayne Thayer
> *Cc:* MDSP
> *Subject:* Re: Violation report - Comodo CA certificates revocation delays
>
> Good to know, and thank you very much for following up on this!
>
> Small update by the way: I finally received a reply from Comodo CA
> confirming their 2nd wave of revocations a few hours ago, on September 17
> at 16:55 UTC to be exact. Strangely, it was in response to an email where I
> informed them that I had already noticed they fully completed my revocation
> request. I don't think it's a relevant detail but I wanted to mention it to
> avoid any potential confusion.
>
> Guillaume Fortin-Debigaré
>
> ------------------------------
> Good to know, and thank you very much for following up on this!
>
> Small update by the way: I finally received a reply from Comodo CA
> confirming their 2nd wave of revocations a few hours ago, on September 17
> at 16:55 UTC to be exact. Strangely, it was in response to an email where I
> informed them that I had already noticed they fully completed my revocation
> request. I don't think it's a relevant detail but I wanted to mention it to
> avoid any potential confusion.
>
> Guillaume Fortin-Debigaré
>
> *From:* Wayne Thayer <wth...@mozilla.com>
> *Sent:* September 17, 2018 20:09
> *To:* pleasei...@hotmail.com
> *Cc:* MDSP
> *Subject:* Re: Violation report - Comodo CA certificates revocation delays
>
> I have created a bug and requested a response from Comodo:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
>
> As noted, there are no specific requirements regarding how CAs validate
> revocation requests in the BRs. Every CA may do this however they choose,
> so I don't believe there is any action required in regard to DigiCert's
> response to their problem report.
>
> - Wayne
>
> On Sun, Sep 16, 2018 at 8:30 PM please please via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
> I have created a bug and requested a response from Comodo:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
>
> As noted, there are no specific requirements regarding how CAs validate
> revocation requests in the BRs. Every CA may do this however they choose,
> so I don't believe there is any action required in regard to DigiCert's
> response to their problem report.
>
> - Wayne
>
> On Sun, Sep 16, 2018 at 8:30 PM please please via dev-security-policy <
>
> Hello, I am the domain owner of debigare.com. I would like to make you
> aware that Comodo CA took more than 5 days to revoke certificates they had
> signed for my domain and subdomains after requesting them to do through
> their sslabuse email address, past the 24 hours maximum mentioned in the
> Baseline Requirements as stipulated in section 4.9.1.1.
>
> For context, I was previously using Cloudflare's Universal SSL feature,
> but disabling it did not revoke the old certificates that had not yet
> expired, but simply removed them from its system, and some of the
> certificates were still valid for more than 6 months.
>
> I first attempted to contact Cloudflare's support to ask them to revoke
> the certificates themselves on September 6 at 7:43 UTC. This only led to
> irrelevant responses and confused customer support agents that had no idea
> what I was talking about, and this appeared to go nowhere. I eventually got
> a response from them on September 11 at 5:53 UTC that they would request
> CAs to perform the revocation, but that was after I did so myself, and I
> never got a status report back afterwards.
>
> There were two CAs affected by this issue. The vast majority of
> certificates were signed by Comodo CA, and the rest by DigiCert. I did not
> run into any issues with DigiCert (they in fact proactively checked with
> Cloudflare my claim and revoked the certificates before I even had the
> chance to attempt their domain ownership challenge), but Comodo CA was
> another story entirely.
>
> My first request to Comodo CA to revoke the certificates for debigare.com
> signed for my domain and subdomains after requesting them to do through
> their sslabuse email address, past the 24 hours maximum mentioned in the
> Baseline Requirements as stipulated in section 4.9.1.1.
>
> For context, I was previously using Cloudflare's Universal SSL feature,
> but disabling it did not revoke the old certificates that had not yet
> expired, but simply removed them from its system, and some of the
> certificates were still valid for more than 6 months.
>
> I first attempted to contact Cloudflare's support to ask them to revoke
> the certificates themselves on September 6 at 7:43 UTC. This only led to
> irrelevant responses and confused customer support agents that had no idea
> what I was talking about, and this appeared to go nowhere. I eventually got
> a response from them on September 11 at 5:53 UTC that they would request
> CAs to perform the revocation, but that was after I did so myself, and I
> never got a status report back afterwards.
>
> There were two CAs affected by this issue. The vast majority of
> certificates were signed by Comodo CA, and the rest by DigiCert. I did not
> run into any issues with DigiCert (they in fact proactively checked with
> Cloudflare my claim and revoked the certificates before I even had the
> chance to attempt their domain ownership challenge), but Comodo CA was
> another story entirely.
>
> My first request to Comodo CA to revoke the certificates for debigare.com
>
>
please please
Oct 11, 2018, 7:47:13 PM10/11/18
to Wayne Thayer, MDSP
I was under the impression that CAs were allowed to remove CRL entries and OCSP support for expired certificates for some reason. Good to know!
On a slightly-unrelated note, you might also want to poke Comodo CA about https://bugzilla.mozilla.org/show_bug.cgi?id=1461391
Thanks again!
Sent: October 11, 2018 13:53
To: pleasei...@hotmail.com
Cc: MDSP
Subject: Re: Violation report - Comodo CA certificates revocation delays
I just poked Comodo in the bug - https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
CT Logs are designed such that certificates cannot be removed from them. The evidence will not disappear once the certificates expire.
From: please please <pleasei...@hotmail.com<mailto:pleasei...@hotmail.com>>
Good to know, and thank you very much for following up on this!
Small update by the way: I finally received a reply from Comodo CA confirming their 2nd wave of revocations a few hours ago, on September 17 at 16:55 UTC to be exact. Strangely, it was in response to an email where I informed them that I had already noticed they fully completed my revocation request. I don't think it's a relevant detail but I wanted to mention it to avoid any potential confusion.
Guillaume Fortin-Debigaré
________________________________
From: Wayne Thayer <wth...@mozilla.com<mailto:wth...@mozilla.com>>
Sent: September 17, 2018 20:09
To: pleasei...@hotmail.com<mailto:pleasei...@hotmail.com>
Cc: MDSP
Subject: Re: Violation report - Comodo CA certificates revocation delays
I have created a bug and requested a response from Comodo: https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
As noted, there are no specific requirements regarding how CAs validate revocation requests in the BRs. Every CA may do this however they choose, so I don't believe there is any action required in regard to DigiCert's response to their problem report.
- Wayne
On Sun, Sep 16, 2018 at 8:30 PM please please via dev-security-policy <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>> wrote:
Hello, I am the domain owner of debigare.com<http://debigare.com>. I would like to make you aware that Comodo CA took more than 5 days to revoke certificates they had signed for my domain and subdomains after requesting them to do through their sslabuse email address, past the 24 hours maximum mentioned in the Baseline Requirements as stipulated in section 4.9.1.1.
For context, I was previously using Cloudflare's Universal SSL feature, but disabling it did not revoke the old certificates that had not yet expired, but simply removed them from its system, and some of the certificates were still valid for more than 6 months.
I first attempted to contact Cloudflare's support to ask them to revoke the certificates themselves on September 6 at 7:43 UTC. This only led to irrelevant responses and confused customer support agents that had no idea what I was talking about, and this appeared to go nowhere. I eventually got a response from them on September 11 at 5:53 UTC that they would request CAs to perform the revocation, but that was after I did so myself, and I never got a status report back afterwards.
There were two CAs affected by this issue. The vast majority of certificates were signed by Comodo CA, and the rest by DigiCert. I did not run into any issues with DigiCert (they in fact proactively checked with Cloudflare my claim and revoked the certificates before I even had the chance to attempt their domain ownership challenge), but Comodo CA was another story entirely.
My first request to Comodo CA to revoke the certificates for debigare.com<http://debigare.com> and all of its subdomains was on September 8 at 4:37 UTC. I did not get a reply until September 9 at 15:53 UTC stating that the certificates have been revoked. Not only was this past the 24 hours requirement, but it was also false, as only the most recent certificates had been revoked, not all of them. I mentioned to them their mistake on September 10 at 5:55 UTC with a full list of affected certificates just in case my initial request was unclear to them, and never got a reply back. I did, however, notice that the certificates eventually got revoked on September 13 at 16:04 UTC according to their Certificate Transparency logs, a fact that I only discovered on September 15. Assuming the log is correct, that would be a delay of more than 3 days after notifying them of the incomplete revocation, more than 5 days after my initial request to them, and more than a week until I finally noticed the problem was fixed. It's also worth noting that throughout this entire series of events, Comodo CA never requested proof of domain ownership beyond the evidence I initially provided, so that cannot explain the delays.
One detail that I'm not sure about is why my initial evidence for domain ownership was apparently sufficient for Comodo CA but not for DigiCert. On this regard, the only evidence I provided to both of them was that the email address I used to contact them matched the contact information on my website. (My emails were protected with SPF, DKIM and DMARC for authenticity.) For some reason, DigiCert believed that this evidence did not met the Baseline Requirements for my request, a claim that I am currently unable to verify as I cannot find anything of the sort in them.
You can read the full story on my blog, which I hope will be sufficient to prove my identity: https://www.debigare.com/4-unexpected-issues-i-encountered-upon-switching-web-hosts/
I can also provide a full copy of the email exchange I had with Comodo CA as evidence on request.
Guillaume Fortin-Debigaré
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy
On a slightly-unrelated note, you might also want to poke Comodo CA about https://bugzilla.mozilla.org/show_bug.cgi?id=1461391
Thanks again!
Sent: October 11, 2018 13:53
To: pleasei...@hotmail.com
Cc: MDSP
Subject: Re: Violation report - Comodo CA certificates revocation delays
I just poked Comodo in the bug - https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
CT Logs are designed such that certificates cannot be removed from them. The evidence will not disappear once the certificates expire.
On Wed, Oct 10, 2018 at 5:26 PM please please <pleasei...@hotmail.com<mailto:pleasei...@hotmail.com>> wrote:
Any update behind the scenes about this issue? I've noticed that the soft limit to fill an Incident Report expired more than a week ago, and I'm starting to be a bit worried that some of the evidence in the CT logs might disappear if the investigation is not completed before December 6th, the earliest expiration date among the affected certificates.
Guillaume Fortin-Debigaré
________________________________
Any update behind the scenes about this issue? I've noticed that the soft limit to fill an Incident Report expired more than a week ago, and I'm starting to be a bit worried that some of the evidence in the CT logs might disappear if the investigation is not completed before December 6th, the earliest expiration date among the affected certificates.
Guillaume Fortin-Debigaré
From: please please <pleasei...@hotmail.com<mailto:pleasei...@hotmail.com>>
Sent: September 17, 2018 23:39
To: Wayne Thayer
Cc: MDSP
Subject: Re: Violation report - Comodo CA certificates revocation delays
To: Wayne Thayer
Cc: MDSP
Good to know, and thank you very much for following up on this!
Small update by the way: I finally received a reply from Comodo CA confirming their 2nd wave of revocations a few hours ago, on September 17 at 16:55 UTC to be exact. Strangely, it was in response to an email where I informed them that I had already noticed they fully completed my revocation request. I don't think it's a relevant detail but I wanted to mention it to avoid any potential confusion.
Guillaume Fortin-Debigaré
From: Wayne Thayer <wth...@mozilla.com<mailto:wth...@mozilla.com>>
Sent: September 17, 2018 20:09
To: pleasei...@hotmail.com<mailto:pleasei...@hotmail.com>
Cc: MDSP
Subject: Re: Violation report - Comodo CA certificates revocation delays
I have created a bug and requested a response from Comodo: https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
As noted, there are no specific requirements regarding how CAs validate revocation requests in the BRs. Every CA may do this however they choose, so I don't believe there is any action required in regard to DigiCert's response to their problem report.
- Wayne
Hello, I am the domain owner of debigare.com<http://debigare.com>. I would like to make you aware that Comodo CA took more than 5 days to revoke certificates they had signed for my domain and subdomains after requesting them to do through their sslabuse email address, past the 24 hours maximum mentioned in the Baseline Requirements as stipulated in section 4.9.1.1.
For context, I was previously using Cloudflare's Universal SSL feature, but disabling it did not revoke the old certificates that had not yet expired, but simply removed them from its system, and some of the certificates were still valid for more than 6 months.
I first attempted to contact Cloudflare's support to ask them to revoke the certificates themselves on September 6 at 7:43 UTC. This only led to irrelevant responses and confused customer support agents that had no idea what I was talking about, and this appeared to go nowhere. I eventually got a response from them on September 11 at 5:53 UTC that they would request CAs to perform the revocation, but that was after I did so myself, and I never got a status report back afterwards.
There were two CAs affected by this issue. The vast majority of certificates were signed by Comodo CA, and the rest by DigiCert. I did not run into any issues with DigiCert (they in fact proactively checked with Cloudflare my claim and revoked the certificates before I even had the chance to attempt their domain ownership challenge), but Comodo CA was another story entirely.
One detail that I'm not sure about is why my initial evidence for domain ownership was apparently sufficient for Comodo CA but not for DigiCert. On this regard, the only evidence I provided to both of them was that the email address I used to contact them matched the contact information on my website. (My emails were protected with SPF, DKIM and DMARC for authenticity.) For some reason, DigiCert believed that this evidence did not met the Baseline Requirements for my request, a claim that I am currently unable to verify as I cannot find anything of the sort in them.
You can read the full story on my blog, which I hope will be sufficient to prove my identity: https://www.debigare.com/4-unexpected-issues-i-encountered-upon-switching-web-hosts/
I can also provide a full copy of the email exchange I had with Comodo CA as evidence on request.
Guillaume Fortin-Debigaré
_______________________________________________
dev-security-policy mailing list
https://lists.mozilla.org/listinfo/dev-security-policy
Matt Palmer
Oct 11, 2018, 10:00:08 PM10/11/18
to dev-secur...@lists.mozilla.org
On Thu, Oct 11, 2018 at 11:19:18PM +0000, please please via dev-security-policy wrote:
> I was under the impression that CAs were allowed to remove CRL entries and OCSP support for expired certificates for some reason. Good to know!
CT logs are not CRLs or OCSP responders, nor do they track revocation.
> I was under the impression that CAs were allowed to remove CRL entries and OCSP support for expired certificates for some reason. Good to know!
- Matt
Ryan Sleevi
Oct 11, 2018, 10:16:33 PM10/11/18
to Matt Palmer, MDSP
I believe that may be misunderstanding the concern.
Once these certificates expire, there's not a good way to check whether or
not they were revoked, because such revocation information may be culled
after certificate expiration.
Similarly, if one is looking to verify the claims about revocation dates
and timelines, once those are culled from the CRLs, you can only
demonstrate with past CRLs or responses that may have been archived.
The concern about December 6 represents when some of the certificates begin
to expire, and thus being able to examine whether or not and when things
were done may no longer be available.
>
Once these certificates expire, there's not a good way to check whether or
not they were revoked, because such revocation information may be culled
after certificate expiration.
Similarly, if one is looking to verify the claims about revocation dates
and timelines, once those are culled from the CRLs, you can only
demonstrate with past CRLs or responses that may have been archived.
The concern about December 6 represents when some of the certificates begin
to expire, and thus being able to examine whether or not and when things
were done may no longer be available.
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
>
Robin Alden
Oct 12, 2018, 8:28:47 AM10/12/18
to mozilla-dev-s...@lists.mozilla.org
I understand the OP's concern and will respond to the bug shortly.
Regards
Robin Alden
Comodo CA Ltd.
Regards
Robin Alden
Comodo CA Ltd.
Ben Laurie
Oct 12, 2018, 8:34:03 AM10/12/18
to Ryan Sleevi, Matt Palmer, dev-secur...@lists.mozilla.org
On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> I believe that may be misunderstanding the concern.
>
> Once these certificates expire, there's not a good way to check whether or
> not they were revoked, because such revocation information may be culled
> after certificate expiration.
>
> Similarly, if one is looking to verify the claims about revocation dates
> and timelines, once those are culled from the CRLs, you can only
> demonstrate with past CRLs or responses that may have been archived.
>
> The concern about December 6 represents when some of the certificates begin
> to expire, and thus being able to examine whether or not and when things
> were done may no longer be available.
>
This is one of the reasons we also need revocation transparency.
dev-secur...@lists.mozilla.org> wrote:
> I believe that may be misunderstanding the concern.
>
> Once these certificates expire, there's not a good way to check whether or
> not they were revoked, because such revocation information may be culled
> after certificate expiration.
>
> Similarly, if one is looking to verify the claims about revocation dates
> and timelines, once those are culled from the CRLs, you can only
> demonstrate with past CRLs or responses that may have been archived.
>
> The concern about December 6 represents when some of the certificates begin
> to expire, and thus being able to examine whether or not and when things
> were done may no longer be available.
>
Jakob Bohm
Oct 12, 2018, 8:54:07 AM10/12/18
to mozilla-dev-s...@lists.mozilla.org
On 12/10/2018 14:33, Ben Laurie wrote:
> On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> I believe that may be misunderstanding the concern.
>>
>> Once these certificates expire, there's not a good way to check whether or
>> not they were revoked, because such revocation information may be culled
>> after certificate expiration.
>>
>> Similarly, if one is looking to verify the claims about revocation dates
>> and timelines, once those are culled from the CRLs, you can only
>> demonstrate with past CRLs or responses that may have been archived.
>>
>> The concern about December 6 represents when some of the certificates begin
>> to expire, and thus being able to examine whether or not and when things
>> were done may no longer be available.
>>
>
> This is one of the reasons we also need revocation transparency.
>
Or just a crt.sh enhancement to remember the previously collected
> On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> I believe that may be misunderstanding the concern.
>>
>> Once these certificates expire, there's not a good way to check whether or
>> not they were revoked, because such revocation information may be culled
>> after certificate expiration.
>>
>> Similarly, if one is looking to verify the claims about revocation dates
>> and timelines, once those are culled from the CRLs, you can only
>> demonstrate with past CRLs or responses that may have been archived.
>>
>> The concern about December 6 represents when some of the certificates begin
>> to expire, and thus being able to examine whether or not and when things
>> were done may no longer be available.
>>
>
> This is one of the reasons we also need revocation transparency.
>
revocations.
Unlike certificates, revocations are already published in signed CRLs
that auditing services can simply gather and store, along with some
timestamping of the fact that they were seen at a given time.
The exception being Let's Encrypt, because they only provide OCSP.
A secondary auditing process can statistically sample certificates
from CRLs and CT and check that the samples have the published OCSP
response, plus/minus an acceptable delay (policy dictated) between
updating of OCSP and CRL servers.
>
>>
>> On Thu, Oct 11, 2018 at 10:00 PM Matt Palmer via dev-security-policy <
>> dev-secur...@lists.mozilla.org> wrote:
>>
>>> On Thu, Oct 11, 2018 at 11:19:18PM +0000, please please via
>>> dev-security-policy wrote:
>>>> I was under the impression that CAs were allowed to remove CRL entries
>>> and OCSP support for expired certificates for some reason. Good to know!
>>>
>>> CT logs are not CRLs or OCSP responders, nor do they track revocation.
>>>
>>> - Matt
>>>
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
Ben Laurie
Oct 12, 2018, 9:05:04 AM10/12/18
to dev-secur...@lists.mozilla.org, mozilla-dev-s...@lists.mozilla.org, jb-mo...@wisemo.com
On Fri, 12 Oct 2018 at 13:54, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> On 12/10/2018 14:33, Ben Laurie wrote:
dev-secur...@lists.mozilla.org> wrote:
> On 12/10/2018 14:33, Ben Laurie wrote:
> > On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy <
> > dev-secur...@lists.mozilla.org> wrote:
> >
> >> I believe that may be misunderstanding the concern.
> >>
> >> Once these certificates expire, there's not a good way to check whether
> or
> >> not they were revoked, because such revocation information may be culled
> >> after certificate expiration.
> >>
> >> Similarly, if one is looking to verify the claims about revocation dates
> >> and timelines, once those are culled from the CRLs, you can only
> >> demonstrate with past CRLs or responses that may have been archived.
> >>
> >> The concern about December 6 represents when some of the certificates
> begin
> >> to expire, and thus being able to examine whether or not and when things
> >> were done may no longer be available.
> >>
> >
> > This is one of the reasons we also need revocation transparency.
> >
>
> > dev-secur...@lists.mozilla.org> wrote:
> >
> >> I believe that may be misunderstanding the concern.
> >>
> >> Once these certificates expire, there's not a good way to check whether
> or
> >> not they were revoked, because such revocation information may be culled
> >> after certificate expiration.
> >>
> >> Similarly, if one is looking to verify the claims about revocation dates
> >> and timelines, once those are culled from the CRLs, you can only
> >> demonstrate with past CRLs or responses that may have been archived.
> >>
> >> The concern about December 6 represents when some of the certificates
> begin
> >> to expire, and thus being able to examine whether or not and when things
> >> were done may no longer be available.
> >>
> >
> > This is one of the reasons we also need revocation transparency.
> >
>
> Or just a crt.sh enhancement to remember the previously collected
> revocations.
>
> Unlike certificates, revocations are already published in signed CRLs
> that auditing services can simply gather and store, along with some
> timestamping of the fact that they were seen at a given time.
>
> The exception being Let's Encrypt, because they only provide OCSP.
>
> A secondary auditing process can statistically sample certificates
> from CRLs and CT and check that the samples have the published OCSP
> response, plus/minus an acceptable delay (policy dictated) between
> updating of OCSP and CRL servers.
>
Of course this is also useful. Transparency, however, would prevent certain
> revocations.
>
> Unlike certificates, revocations are already published in signed CRLs
> that auditing services can simply gather and store, along with some
> timestamping of the fact that they were seen at a given time.
>
> The exception being Let's Encrypt, because they only provide OCSP.
>
> A secondary auditing process can statistically sample certificates
> from CRLs and CT and check that the samples have the published OCSP
> response, plus/minus an acceptable delay (policy dictated) between
> updating of OCSP and CRL servers.
>
attacks that this does not.
>
> >
> >>
> >> On Thu, Oct 11, 2018 at 10:00 PM Matt Palmer via dev-security-policy <
> >> dev-secur...@lists.mozilla.org> wrote:
> >>
> >>> On Thu, Oct 11, 2018 at 11:19:18PM +0000, please please via
> >>> dev-security-policy wrote:
> >>>> I was under the impression that CAs were allowed to remove CRL entries
> >>> and OCSP support for expired certificates for some reason. Good to
> know!
> >>>
> >>> CT logs are not CRLs or OCSP responders, nor do they track revocation.
> >>>
> >>> - Matt
> >>>
>
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
Ben Laurie
Oct 12, 2018, 9:05:05 AM10/12/18
to dev-secur...@lists.mozilla.org, mozilla-dev-s...@lists.mozilla.org, jb-mo...@wisemo.com
On Fri, 12 Oct 2018 at 13:54, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> On 12/10/2018 14:33, Ben Laurie wrote:
dev-secur...@lists.mozilla.org> wrote:
> On 12/10/2018 14:33, Ben Laurie wrote:
> > On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy <
> > dev-secur...@lists.mozilla.org> wrote:
> >
> >> I believe that may be misunderstanding the concern.
> >>
> >> Once these certificates expire, there's not a good way to check whether
> or
> >> not they were revoked, because such revocation information may be culled
> >> after certificate expiration.
> >>
> >> Similarly, if one is looking to verify the claims about revocation dates
> >> and timelines, once those are culled from the CRLs, you can only
> >> demonstrate with past CRLs or responses that may have been archived.
> >>
> >> The concern about December 6 represents when some of the certificates
> begin
> >> to expire, and thus being able to examine whether or not and when things
> >> were done may no longer be available.
> >>
> >
> > This is one of the reasons we also need revocation transparency.
> >
>
> > dev-secur...@lists.mozilla.org> wrote:
> >
> >> I believe that may be misunderstanding the concern.
> >>
> >> Once these certificates expire, there's not a good way to check whether
> or
> >> not they were revoked, because such revocation information may be culled
> >> after certificate expiration.
> >>
> >> Similarly, if one is looking to verify the claims about revocation dates
> >> and timelines, once those are culled from the CRLs, you can only
> >> demonstrate with past CRLs or responses that may have been archived.
> >>
> >> The concern about December 6 represents when some of the certificates
> begin
> >> to expire, and thus being able to examine whether or not and when things
> >> were done may no longer be available.
> >>
> >
> > This is one of the reasons we also need revocation transparency.
> >
>
> Or just a crt.sh enhancement to remember the previously collected
> revocations.
>
> Unlike certificates, revocations are already published in signed CRLs
> that auditing services can simply gather and store, along with some
> timestamping of the fact that they were seen at a given time.
>
> The exception being Let's Encrypt, because they only provide OCSP.
>
> A secondary auditing process can statistically sample certificates
> from CRLs and CT and check that the samples have the published OCSP
> response, plus/minus an acceptable delay (policy dictated) between
> updating of OCSP and CRL servers.
>
Of course this is also useful. Transparency, however, would prevent certain
attacks that this does not.
>
> >
> >>
> revocations.
>
> Unlike certificates, revocations are already published in signed CRLs
> that auditing services can simply gather and store, along with some
> timestamping of the fact that they were seen at a given time.
>
> The exception being Let's Encrypt, because they only provide OCSP.
>
> A secondary auditing process can statistically sample certificates
> from CRLs and CT and check that the samples have the published OCSP
> response, plus/minus an acceptable delay (policy dictated) between
> updating of OCSP and CRL servers.
>
Of course this is also useful. Transparency, however, would prevent certain
attacks that this does not.
>
> >
> >>
> >> On Thu, Oct 11, 2018 at 10:00 PM Matt Palmer via dev-security-policy <
> >> dev-secur...@lists.mozilla.org> wrote:
> >>
> >>> On Thu, Oct 11, 2018 at 11:19:18PM +0000, please please via
> >>> dev-security-policy wrote:
> >>>> I was under the impression that CAs were allowed to remove CRL entries
> >>> and OCSP support for expired certificates for some reason. Good to
> know!
> >>>
> >>> CT logs are not CRLs or OCSP responders, nor do they track revocation.
> >>>
> >>> - Matt
> >>>
>
>
>
> >> dev-secur...@lists.mozilla.org> wrote:
> >>
> >>> On Thu, Oct 11, 2018 at 11:19:18PM +0000, please please via
> >>> dev-security-policy wrote:
> >>>> I was under the impression that CAs were allowed to remove CRL entries
> >>> and OCSP support for expired certificates for some reason. Good to
> know!
> >>>
> >>> CT logs are not CRLs or OCSP responders, nor do they track revocation.
> >>>
> >>> - Matt
> >>>
>
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
Rob Stradling
Oct 12, 2018, 9:19:31 AM10/12/18
to dev-secur...@lists.mozilla.org, Jakob Bohm
On 12/10/18 13:53, Jakob Bohm via dev-security-policy wrote:
> On 12/10/2018 14:33, Ben Laurie wrote:
<snip>
> On 12/10/2018 14:33, Ben Laurie wrote:
>> This is one of the reasons we also need revocation transparency.
>
>
> Or just a crt.sh enhancement to remember the previously collected
> revocations.
crt.sh already remembers previously collected CRL entries.
> revocations.
Examples:
1. https://crt.sh/?id=35391481 is a now-expired cert that crt.sh
observed as revoked-by-CRL whilst it was time-valid.
2. https://crt.sh/mozilla-disclosures#disclosedandunrevokedfromcrl shows
that https://crt.sh/?id=12724140 was revoked-by-CRL and then "unrevoked"
(see also https://bugzilla.mozilla.org/show_bug.cgi?id=1442091)
--
Rob Stradling
Senior Research & Development Scientist
Email: R...@ComodoCA.com
Ryan Sleevi
Oct 12, 2018, 11:41:11 AM10/12/18
to Ben Laurie, Ryan Sleevi, Matt Palmer, MDSP
On Fri, Oct 12, 2018 at 8:33 AM Ben Laurie <be...@google.com> wrote:
>
>
> On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> I believe that may be misunderstanding the concern.
>>
>> Once these certificates expire, there's not a good way to check whether or
>> not they were revoked, because such revocation information may be culled
>> after certificate expiration.
>>
>> Similarly, if one is looking to verify the claims about revocation dates
>> and timelines, once those are culled from the CRLs, you can only
>> demonstrate with past CRLs or responses that may have been archived.
>>
>> The concern about December 6 represents when some of the certificates
>> begin
>> to expire, and thus being able to examine whether or not and when things
>> were done may no longer be available.
>>
>
>
>
> On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> I believe that may be misunderstanding the concern.
>>
>> Once these certificates expire, there's not a good way to check whether or
>> not they were revoked, because such revocation information may be culled
>> after certificate expiration.
>>
>> Similarly, if one is looking to verify the claims about revocation dates
>> and timelines, once those are culled from the CRLs, you can only
>> demonstrate with past CRLs or responses that may have been archived.
>>
>> The concern about December 6 represents when some of the certificates
>> begin
>> to expire, and thus being able to examine whether or not and when things
>> were done may no longer be available.
>>
>
> This is one of the reasons we also need revocation transparency.
>
As tempting as the buzzword is, and as much as we love motherhood and apple
>
pie and must constantly think of the children, slapping transparency after
a word doesn't actually address the needs of the community or users, nor
does it resolve the challenging policy issues that arise. Just because
something is cryptographically verifiable does not mean it actually
resolves real world problems, or does not introduce additional ones.
A simpler solution, for example, is to maintain an archive of CRLs signed
by the CA. Which would address the need without the distraction, and
without having the technical equivalent of Fermat's Last Theorem being
invoked. Let's not let the perfect (and unspecified) be the enemy of the
good and reasonable.
Ben Laurie
Oct 12, 2018, 1:57:44 PM10/12/18
to Ryan Sleevi, Matt Palmer, dev-secur...@lists.mozilla.org
"transparency" is an improvement is that it practically and efficiently
prevents equivocation, which archives do not.
Perhaps you don't care about equivocation.
Rob Stradling
Oct 12, 2018, 2:01:58 PM10/12/18
to ry...@sleevi.com, Ben Laurie, Matt Palmer, MDSP
On 12/10/18 16:40, Ryan Sleevi via dev-security-policy wrote:
> On Fri, Oct 12, 2018 at 8:33 AM Ben Laurie <be...@google.com> wrote:
<snip>
> On Fri, Oct 12, 2018 at 8:33 AM Ben Laurie <be...@google.com> wrote:
>> This is one of the reasons we also need revocation transparency.
>
> As tempting as the buzzword is, and as much as we love motherhood and apple
> pie and must constantly think of the children, slapping transparency after
> a word doesn't actually address the needs of the community or users, nor
> does it resolve the challenging policy issues that arise. Just because
> something is cryptographically verifiable does not mean it actually
> resolves real world problems, or does not introduce additional ones.
>
> A simpler solution, for example, is to maintain an archive of CRLs signed
> by the CA. Which would address the need without the distraction, and
> without having the technical equivalent of Fermat's Last Theorem being
> invoked. Let's not let the perfect (and unspecified) be the enemy of the
> good and reasonable.
FWIW, we (Comodo CA) do maintain an archive of all the CRLs we've ever
>
> As tempting as the buzzword is, and as much as we love motherhood and apple
> pie and must constantly think of the children, slapping transparency after
> a word doesn't actually address the needs of the community or users, nor
> does it resolve the challenging policy issues that arise. Just because
> something is cryptographically verifiable does not mean it actually
> resolves real world problems, or does not introduce additional ones.
>
> A simpler solution, for example, is to maintain an archive of CRLs signed
> by the CA. Which would address the need without the distraction, and
> without having the technical equivalent of Fermat's Last Theorem being
> invoked. Let's not let the perfect (and unspecified) be the enemy of the
> good and reasonable.
signed.
Jakob Bohm
Oct 15, 2018, 12:39:25 PM10/15/18
to mozilla-dev-s...@lists.mozilla.org
in order for the community to detect that CAs (do not) attempt to
falsify their history of past revocations.
It appears that crt.sh is already providing this service to the
community, albeit without a cryptographic timestamp signature on the
evidence that crt.sh had indeed seen specific CRLs before a certain
date/time.
However the mere existence of contradictory CRLs covering the same date
range would already be significant evidence against any such rogue CA.
Ben Laurie
Oct 18, 2018, 5:56:11 PM10/18/18
to Rob Stradling, Ryan Sleevi, Matt Palmer, dev-secur...@lists.mozilla.org
On Fri, 12 Oct 2018 at 19:01, Rob Stradling <R...@comodoca.com> wrote:
> On 12/10/18 16:40, Ryan Sleevi via dev-security-policy wrote:
> > On Fri, Oct 12, 2018 at 8:33 AM Ben Laurie <be...@google.com> wrote:
> <snip>
> >> This is one of the reasons we also need revocation transparency.
> >
> > As tempting as the buzzword is, and as much as we love motherhood and
> apple
> > pie and must constantly think of the children, slapping transparency
> after
> > a word doesn't actually address the needs of the community or users, nor
> > does it resolve the challenging policy issues that arise. Just because
> > something is cryptographically verifiable does not mean it actually
> > resolves real world problems, or does not introduce additional ones.
> >
> > A simpler solution, for example, is to maintain an archive of CRLs signed
> > by the CA. Which would address the need without the distraction, and
> > without having the technical equivalent of Fermat's Last Theorem being
> > invoked. Let's not let the perfect (and unspecified) be the enemy of the
> > good and reasonable.
>
> FWIW, we (Comodo CA) do maintain an archive of all the CRLs we've ever
> signed.
>
Put it in Trillian? :-)
> On 12/10/18 16:40, Ryan Sleevi via dev-security-policy wrote:
> > On Fri, Oct 12, 2018 at 8:33 AM Ben Laurie <be...@google.com> wrote:
> <snip>
> >> This is one of the reasons we also need revocation transparency.
> >
> > As tempting as the buzzword is, and as much as we love motherhood and
> apple
> > pie and must constantly think of the children, slapping transparency
> after
> > a word doesn't actually address the needs of the community or users, nor
> > does it resolve the challenging policy issues that arise. Just because
> > something is cryptographically verifiable does not mean it actually
> > resolves real world problems, or does not introduce additional ones.
> >
> > A simpler solution, for example, is to maintain an archive of CRLs signed
> > by the CA. Which would address the need without the distraction, and
> > without having the technical equivalent of Fermat's Last Theorem being
> > invoked. Let's not let the perfect (and unspecified) be the enemy of the
> > good and reasonable.
>
> FWIW, we (Comodo CA) do maintain an archive of all the CRLs we've ever
> signed.
>
Rob Stradling
Oct 19, 2018, 5:38:31 AM10/19/18
to Ben Laurie, Ryan Sleevi, Matt Palmer, dev-secur...@lists.mozilla.org
On 18/10/2018 22:55, Ben Laurie wrote:
That had occurred to me. ;-)
Would it be useful?
Would it be useful?
Ben Laurie
Oct 19, 2018, 5:43:19 AM10/19/18
to Rob Stradling, Ryan Sleevi, Matt Palmer, dev-secur...@lists.mozilla.org
inclusion proofs, but its a step in the right direction. Is there a way to
add ad-hoc stuff to CRLs?
Rob Stradling
Oct 19, 2018, 5:54:43 AM10/19/18
to Ben Laurie, Ryan Sleevi, Matt Palmer, dev-secur...@lists.mozilla.org
On 19/10/2018 10:42, Ben Laurie wrote:
> On Fri, 19 Oct 2018 at 10:38, Rob Stradling wrote:
<snip>
I suppose "CRL Transparency" would look much the same as CT, except that
it would operate on X.509v3 CRL blobs instead of X.509v3 Certificate blobs.
> On Fri, 19 Oct 2018 at 10:38, Rob Stradling wrote:
<snip>
>>>> FWIW, we (Comodo CA) do maintain an archive of all the CRLs we've ever >>>> signed.>>>
>>> Put it in Trillian? :-)
>>
>> That had occurred to me. ;-)
>>
>> Would it be useful?
>
> To be properly useful you would need to extend CRL protocols to include
> inclusion proofs, but its a step in the right direction. Is there a way
> to add ad-hoc stuff to CRLs?
Yes, CRLs have X.509v3 extensions, just like certificates do.
>>> Put it in Trillian? :-)
>>
>> That had occurred to me. ;-)
>>
>> Would it be useful?
>
> To be properly useful you would need to extend CRL protocols to include
> inclusion proofs, but its a step in the right direction. Is there a way
> to add ad-hoc stuff to CRLs?
I suppose "CRL Transparency" would look much the same as CT, except that
it would operate on X.509v3 CRL blobs instead of X.509v3 Certificate blobs.
war...@gmail.com
Nov 27, 2018, 10:29:49 AM11/27/18
to mozilla-dev-s...@lists.mozilla.org
Friday, October 12, 2018 14:28:47 UTC+2 Robin Alden wrote:
> I understand the OP's concern and will respond to the bug shortly.
Given that 45 days passed now, the internal definition of "shortly" used by Comodo seems to differ a lot from the common use of the term.
> I understand the OP's concern and will respond to the bug shortly.
please please
Dec 17, 2018, 11:18:20 AM12/17/18
to Wayne Thayer, MDSP
I just noticed that Comodo CA has finally posted its incident report in https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
Comments:
- The report suggests that no BR violation occurred because I was not the Subscriber to fulfill the conditions in bullet point 1 of BR 4.9.1.1. However, I believe I fulfilled the conditions for triggering the 24 hours revocation anyway because of bullet point 6 of the same BR, which states "The CA is made aware of any circumstance indicating that use of a Fully Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. [...] a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated [...])", as I explicitly stated in my initial revocation request email that Cloudflare was no longer authorized to represent my domain but still controlled the private keys.
- Comodo CA claims that my request was "potentially ambiguous", but did not explain in what regard, nor did they ever asked me for clarifications. I can only assume as of now that the issue was to get an exhaustive list of certificates as I ran into the same problem and could not do so efficiently myself, but assumed Comodo CA would have had the means necessary to extract them easily from their own data based on my request.
- I'm concerned that the incident report was posted more than 2 months past Mozilla's soft deadline to do so, especially when considering that the incident was also about being late to take necessary action for a deadline.
Let me know if you need additional information from me to complete your assessment of the incident.
Guillaume Fortin-Debigaré
________________________________
From: please please <pleasei...@hotmail.com>
Sent: October 11, 2018 19:19
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy
Comments:
- The report suggests that no BR violation occurred because I was not the Subscriber to fulfill the conditions in bullet point 1 of BR 4.9.1.1. However, I believe I fulfilled the conditions for triggering the 24 hours revocation anyway because of bullet point 6 of the same BR, which states "The CA is made aware of any circumstance indicating that use of a Fully Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. [...] a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated [...])", as I explicitly stated in my initial revocation request email that Cloudflare was no longer authorized to represent my domain but still controlled the private keys.
- Comodo CA claims that my request was "potentially ambiguous", but did not explain in what regard, nor did they ever asked me for clarifications. I can only assume as of now that the issue was to get an exhaustive list of certificates as I ran into the same problem and could not do so efficiently myself, but assumed Comodo CA would have had the means necessary to extract them easily from their own data based on my request.
- I'm concerned that the incident report was posted more than 2 months past Mozilla's soft deadline to do so, especially when considering that the incident was also about being late to take necessary action for a deadline.
Let me know if you need additional information from me to complete your assessment of the incident.
Guillaume Fortin-Debigaré
________________________________
From: please please <pleasei...@hotmail.com>
To: Wayne Thayer
Cc: MDSP
Subject: Re: Violation report - Comodo CA certificates revocation delays
Cc: MDSP
Subject: Re: Violation report - Comodo CA certificates revocation delays
I was under the impression that CAs were allowed to remove CRL entries and OCSP support for expired certificates for some reason. Good to know!
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy
Wayne Thayer
Dec 17, 2018, 1:00:50 PM12/17/18
to please please, MDSP
On Sun, Dec 16, 2018 at 11:49 PM please please <pleasei...@hotmail.com>
wrote:
> I just noticed that Comodo CA has finally posted its incident report in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
>
> Comments:
> - The report suggests that no BR violation occurred because I was not the
> Subscriber to fulfill the conditions in bullet point 1 of BR 4.9.1.1.
> However, I believe I fulfilled the conditions for triggering the 24 hours
> revocation anyway because of bullet point 6 of the same BR, which states "The
> CA is made aware of any circumstance indicating that use of a Fully
> Qualified Domain Name or IP address in the Certificate is no longer legally
> permitted (e.g. [...] a relevant licensing or services agreement between
> the Domain Name Registrant and the Applicant has terminated [...])", as I
> explicitly stated in my initial revocation request email that Cloudflare
> was no longer authorized to represent my domain but still controlled the
> private keys.
>
Sectigo's (formerly Comodo's) response does seem to both admit the
violation and downplay it. Shortly after the violation the BRs were changed
to allow 5 days for most revocations, and that may be the motivation for
calling out that the Subscriber didn't request revocation. However, I
believe this case still falls under the 24-hour rule due to 4.9.1.1(4):
The CA obtains evidence that the validation of domain authorization or
control for any Fully-Qualified Domain Name or IP address in the
Certificate should not be relied upon.
- Comodo CA claims that my request was "potentially ambiguous", but did not
> explain in what regard, nor did they ever asked me for clarifications. I
> can only assume as of now that the issue was to get an exhaustive list of
> certificates as I ran into the same problem and could not do so efficiently
> myself, but assumed Comodo CA would have had the means necessary to extract
> them easily from their own data based on my request.
>
I've requested more information in the bug. This may be a case of Sectigo
falling back on the interpretation that the revocation clock doesn't start
until the certificates have been identified. However, Sectigo also accepts
responsibility by stating "The urgency of the revocation request was not
adequately communicated as the request was passed along."
- I'm concerned that the incident report was posted more than 2 months past
> Mozilla's soft deadline to do so, especially when considering that the
> incident was also about being late to take necessary action for a deadline.
>
> Yes, this is a concern. When a CA exhibits a pattern of slow responses, it
is taken into consideration when Mozilla is making decisions about the CA,
such as whether to include new roots.
Let me know if you need additional information from me to complete your
> assessment of the incident.
>
> Guillaume Fortin-Debigaré
> *Sent:* October 11, 2018 19:19
> *Subject:* Re: Violation report - Comodo CA certificates revocation delays
>
> Hello, I am the domain owner of debigare.com. I would like to make you
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
wrote:
> I just noticed that Comodo CA has finally posted its incident report in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
>
> Comments:
> - The report suggests that no BR violation occurred because I was not the
> Subscriber to fulfill the conditions in bullet point 1 of BR 4.9.1.1.
> However, I believe I fulfilled the conditions for triggering the 24 hours
> revocation anyway because of bullet point 6 of the same BR, which states "The
> CA is made aware of any circumstance indicating that use of a Fully
> Qualified Domain Name or IP address in the Certificate is no longer legally
> permitted (e.g. [...] a relevant licensing or services agreement between
> the Domain Name Registrant and the Applicant has terminated [...])", as I
> explicitly stated in my initial revocation request email that Cloudflare
> was no longer authorized to represent my domain but still controlled the
> private keys.
>
violation and downplay it. Shortly after the violation the BRs were changed
to allow 5 days for most revocations, and that may be the motivation for
calling out that the Subscriber didn't request revocation. However, I
believe this case still falls under the 24-hour rule due to 4.9.1.1(4):
The CA obtains evidence that the validation of domain authorization or
control for any Fully-Qualified Domain Name or IP address in the
Certificate should not be relied upon.
- Comodo CA claims that my request was "potentially ambiguous", but did not
> explain in what regard, nor did they ever asked me for clarifications. I
> can only assume as of now that the issue was to get an exhaustive list of
> certificates as I ran into the same problem and could not do so efficiently
> myself, but assumed Comodo CA would have had the means necessary to extract
> them easily from their own data based on my request.
>
falling back on the interpretation that the revocation clock doesn't start
until the certificates have been identified. However, Sectigo also accepts
responsibility by stating "The urgency of the revocation request was not
adequately communicated as the request was passed along."
- I'm concerned that the incident report was posted more than 2 months past
> Mozilla's soft deadline to do so, especially when considering that the
> incident was also about being late to take necessary action for a deadline.
>
is taken into consideration when Mozilla is making decisions about the CA,
such as whether to include new roots.
Let me know if you need additional information from me to complete your
> assessment of the incident.
>
> Guillaume Fortin-Debigaré
> *To:* Wayne Thayer
> *Cc:* MDSP
> *Subject:* Re: Violation report - Comodo CA certificates revocation delays
> *Cc:* MDSP
>
> I was under the impression that CAs were allowed to remove CRL entries and
> OCSP support for expired certificates for some reason. Good to know!
>
> On a slightly-unrelated note, you might also want to poke Comodo CA about
> https://bugzilla.mozilla.org/show_bug.cgi?id=1461391
>
> Thanks again!
>
> Guillaume Fortin-Debigaré
> *Sent:* October 11, 2018 13:53
> I was under the impression that CAs were allowed to remove CRL entries and
> OCSP support for expired certificates for some reason. Good to know!
>
> On a slightly-unrelated note, you might also want to poke Comodo CA about
> https://bugzilla.mozilla.org/show_bug.cgi?id=1461391
>
> Thanks again!
>
> Guillaume Fortin-Debigaré
> *Subject:* Re: Violation report - Comodo CA certificates revocation delays
>
> I just poked Comodo in the bug -
> https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
>
> CT Logs are designed such that certificates cannot be removed from them.
> The evidence will not disappear once the certificates expire.
>
> On Wed, Oct 10, 2018 at 5:26 PM please please <pleasei...@hotmail.com>
> I just poked Comodo in the bug -
> https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
>
> CT Logs are designed such that certificates cannot be removed from them.
> The evidence will not disappear once the certificates expire.
>
> On Wed, Oct 10, 2018 at 5:26 PM please please <pleasei...@hotmail.com>
> wrote:
>
> Any update behind the scenes about this issue? I've noticed that the soft
> limit to fill an Incident Report expired more than a week ago, and I'm
> starting to be a bit worried that some of the evidence in the CT logs might
> disappear if the investigation is not completed before December 6th, the
> earliest expiration date among the affected certificates.
>
> Guillaume Fortin-Debigaré
>
> Any update behind the scenes about this issue? I've noticed that the soft
> limit to fill an Incident Report expired more than a week ago, and I'm
> starting to be a bit worried that some of the evidence in the CT logs might
> disappear if the investigation is not completed before December 6th, the
> earliest expiration date among the affected certificates.
>
> Guillaume Fortin-Debigaré
> ------------------------------
> *From:* please please <pleasei...@hotmail.com>
> *Sent:* September 17, 2018 23:39
> *To:* Wayne Thayer
> *Cc:* MDSP
> *Subject:* Re: Violation report - Comodo CA certificates revocation delays
> *From:* please please <pleasei...@hotmail.com>
> *Sent:* September 17, 2018 23:39
> *To:* Wayne Thayer
> *Cc:* MDSP
>
> Good to know, and thank you very much for following up on this!
>
> Small update by the way: I finally received a reply from Comodo CA
> confirming their 2nd wave of revocations a few hours ago, on September 17
> at 16:55 UTC to be exact. Strangely, it was in response to an email where I
> informed them that I had already noticed they fully completed my revocation
> request. I don't think it's a relevant detail but I wanted to mention it to
> avoid any potential confusion.
>
> Guillaume Fortin-Debigaré
>
> Good to know, and thank you very much for following up on this!
>
> Small update by the way: I finally received a reply from Comodo CA
> confirming their 2nd wave of revocations a few hours ago, on September 17
> at 16:55 UTC to be exact. Strangely, it was in response to an email where I
> informed them that I had already noticed they fully completed my revocation
> request. I don't think it's a relevant detail but I wanted to mention it to
> avoid any potential confusion.
>
> Guillaume Fortin-Debigaré
>
> ------------------------------
> *From:* Wayne Thayer <wth...@mozilla.com>
> *Sent:* September 17, 2018 20:09
> *To:* pleasei...@hotmail.com
> *Cc:* MDSP
> *Subject:* Re: Violation report - Comodo CA certificates revocation delays
> *From:* Wayne Thayer <wth...@mozilla.com>
> *Sent:* September 17, 2018 20:09
> *To:* pleasei...@hotmail.com
> *Cc:* MDSP
>
> I have created a bug and requested a response from Comodo:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
>
> As noted, there are no specific requirements regarding how CAs validate
> revocation requests in the BRs. Every CA may do this however they choose,
> so I don't believe there is any action required in regard to DigiCert's
> response to their problem report.
>
> - Wayne
>
> On Sun, Sep 16, 2018 at 8:30 PM please please via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
> I have created a bug and requested a response from Comodo:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
>
> As noted, there are no specific requirements regarding how CAs validate
> revocation requests in the BRs. Every CA may do this however they choose,
> so I don't believe there is any action required in regard to DigiCert's
> response to their problem report.
>
> - Wayne
>
> On Sun, Sep 16, 2018 at 8:30 PM please please via dev-security-policy <
>
> Hello, I am the domain owner of debigare.com. I would like to make you
> aware that Comodo CA took more than 5 days to revoke certificates they had
> signed for my domain and subdomains after requesting them to do through
> their sslabuse email address, past the 24 hours maximum mentioned in the
> Baseline Requirements as stipulated in section 4.9.1.1.
>
> For context, I was previously using Cloudflare's Universal SSL feature,
> but disabling it did not revoke the old certificates that had not yet
> expired, but simply removed them from its system, and some of the
> certificates were still valid for more than 6 months.
>
> I first attempted to contact Cloudflare's support to ask them to revoke
> the certificates themselves on September 6 at 7:43 UTC. This only led to
> irrelevant responses and confused customer support agents that had no idea
> what I was talking about, and this appeared to go nowhere. I eventually got
> a response from them on September 11 at 5:53 UTC that they would request
> CAs to perform the revocation, but that was after I did so myself, and I
> never got a status report back afterwards.
>
> There were two CAs affected by this issue. The vast majority of
> certificates were signed by Comodo CA, and the rest by DigiCert. I did not
> run into any issues with DigiCert (they in fact proactively checked with
> Cloudflare my claim and revoked the certificates before I even had the
> chance to attempt their domain ownership challenge), but Comodo CA was
> another story entirely.
>
> My first request to Comodo CA to revoke the certificates for debigare.com
> signed for my domain and subdomains after requesting them to do through
> their sslabuse email address, past the 24 hours maximum mentioned in the
> Baseline Requirements as stipulated in section 4.9.1.1.
>
> For context, I was previously using Cloudflare's Universal SSL feature,
> but disabling it did not revoke the old certificates that had not yet
> expired, but simply removed them from its system, and some of the
> certificates were still valid for more than 6 months.
>
> I first attempted to contact Cloudflare's support to ask them to revoke
> the certificates themselves on September 6 at 7:43 UTC. This only led to
> irrelevant responses and confused customer support agents that had no idea
> what I was talking about, and this appeared to go nowhere. I eventually got
> a response from them on September 11 at 5:53 UTC that they would request
> CAs to perform the revocation, but that was after I did so myself, and I
> never got a status report back afterwards.
>
> There were two CAs affected by this issue. The vast majority of
> certificates were signed by Comodo CA, and the rest by DigiCert. I did not
> run into any issues with DigiCert (they in fact proactively checked with
> Cloudflare my claim and revoked the certificates before I even had the
> chance to attempt their domain ownership challenge), but Comodo CA was
> another story entirely.
>
> My first request to Comodo CA to revoke the certificates for debigare.com
>
>
please please
Dec 17, 2018, 5:56:03 PM12/17/18
to Wayne Thayer, MDSP
A lot of things changes in 3 months it seems. ??
The wording for the new "validation of domain authorization or control [...] should not be relied upon" condition seems open to interpretation, so I'm not sure if it really applies here. Wouldn't it fully cover the "no longer legally permitted" condition as well in this case, making the latter redundant?
In any case, I should point out that even when taking into account the latest version of the BRs instead of the one that applied at the time (v.1.6.0), it would still have violated the "no longer legally permitted" condition that I previously quoted within the extended deadline of 5 days anyway.
Thanks again Wayne for the follow-up!
Sent: December 17, 2018 13:00
To: please please
Cc: MDSP
Subject: Re: Violation report - Comodo CA certificates revocation delays
On Sun, Dec 16, 2018 at 11:49 PM please please <pleasei...@hotmail.com<mailto:pleasei...@hotmail.com>> wrote:
I just noticed that Comodo CA has finally posted its incident report in https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
Comments:
- The report suggests that no BR violation occurred because I was not the Subscriber to fulfill the conditions in bullet point 1 of BR 4.9.1.1. However, I believe I fulfilled the conditions for triggering the 24 hours revocation anyway because of bullet point 6 of the same BR, which states "The CA is made aware of any circumstance indicating that use of a Fully Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. [...] a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated [...])", as I explicitly stated in my initial revocation request email that Cloudflare was no longer authorized to represent my domain but still controlled the private keys.
Sectigo's (formerly Comodo's) response does seem to both admit the violation and downplay it. Shortly after the violation the BRs were changed to allow 5 days for most revocations, and that may be the motivation for calling out that the Subscriber didn't request revocation. However, I believe this case still falls under the 24-hour rule due to 4.9.1.1(4):
The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon.
- Comodo CA claims that my request was "potentially ambiguous", but did not explain in what regard, nor did they ever asked me for clarifications. I can only assume as of now that the issue was to get an exhaustive list of certificates as I ran into the same problem and could not do so efficiently myself, but assumed Comodo CA would have had the means necessary to extract them easily from their own data based on my request.
I've requested more information in the bug. This may be a case of Sectigo falling back on the interpretation that the revocation clock doesn't start until the certificates have been identified. However, Sectigo also accepts responsibility by stating "The urgency of the revocation request was not adequately communicated as the request was passed along."
- I'm concerned that the incident report was posted more than 2 months past Mozilla's soft deadline to do so, especially when considering that the incident was also about being late to take necessary action for a deadline.
Yes, this is a concern. When a CA exhibits a pattern of slow responses, it is taken into consideration when Mozilla is making decisions about the CA, such as whether to include new roots.
Let me know if you need additional information from me to complete your assessment of the incident.
Guillaume Fortin-Debigaré
I was under the impression that CAs were allowed to remove CRL entries and OCSP support for expired certificates for some reason. Good to know!
On a slightly-unrelated note, you might also want to poke Comodo CA about https://bugzilla.mozilla.org/show_bug.cgi?id=1461391
Thanks again!
Guillaume Fortin-Debigaré
Sent: October 11, 2018 13:53
Subject: Re: Violation report - Comodo CA certificates revocation delays
I just poked Comodo in the bug - https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
CT Logs are designed such that certificates cannot be removed from them. The evidence will not disappear once the certificates expire.
Good to know, and thank you very much for following up on this!
Small update by the way: I finally received a reply from Comodo CA confirming their 2nd wave of revocations a few hours ago, on September 17 at 16:55 UTC to be exact. Strangely, it was in response to an email where I informed them that I had already noticed they fully completed my revocation request. I don't think it's a relevant detail but I wanted to mention it to avoid any potential confusion.
Guillaume Fortin-Debigaré
I have created a bug and requested a response from Comodo: https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
As noted, there are no specific requirements regarding how CAs validate revocation requests in the BRs. Every CA may do this however they choose, so I don't believe there is any action required in regard to DigiCert's response to their problem report.
- Wayne
On Sun, Sep 16, 2018 at 8:30 PM please please via dev-security-policy <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>> wrote:
Hello, I am the domain owner of debigare.com<http://debigare.com>. I would like to make you aware that Comodo CA took more than 5 days to revoke certificates they had signed for my domain and subdomains after requesting them to do through their sslabuse email address, past the 24 hours maximum mentioned in the Baseline Requirements as stipulated in section 4.9.1.1.
For context, I was previously using Cloudflare's Universal SSL feature, but disabling it did not revoke the old certificates that had not yet expired, but simply removed them from its system, and some of the certificates were still valid for more than 6 months.
I first attempted to contact Cloudflare's support to ask them to revoke the certificates themselves on September 6 at 7:43 UTC. This only led to irrelevant responses and confused customer support agents that had no idea what I was talking about, and this appeared to go nowhere. I eventually got a response from them on September 11 at 5:53 UTC that they would request CAs to perform the revocation, but that was after I did so myself, and I never got a status report back afterwards.
There were two CAs affected by this issue. The vast majority of certificates were signed by Comodo CA, and the rest by DigiCert. I did not run into any issues with DigiCert (they in fact proactively checked with Cloudflare my claim and revoked the certificates before I even had the chance to attempt their domain ownership challenge), but Comodo CA was another story entirely.
My first request to Comodo CA to revoke the certificates for debigare.com<http://debigare.com> and all of its subdomains was on September 8 at 4:37 UTC. I did not get a reply until September 9 at 15:53 UTC stating that the certificates have been revoked. Not only was this past the 24 hours requirement, but it was also false, as only the most recent certificates had been revoked, not all of them. I mentioned to them their mistake on September 10 at 5:55 UTC with a full list of affected certificates just in case my initial request was unclear to them, and never got a reply back. I did, however, notice that the certificates eventually got revoked on September 13 at 16:04 UTC according to their Certificate Transparency logs, a fact that I only discovered on September 15. Assuming the log is correct, that would be a delay of more than 3 days after notifying them of the incomplete revocation, more than 5 days after my initial request to them, and more than a week until I finally noticed the problem was fixed. It's also worth noting that throughout this entire series of events, Comodo CA never requested proof of domain ownership beyond the evidence I initially provided, so that cannot explain the delays.
One detail that I'm not sure about is why my initial evidence for domain ownership was apparently sufficient for Comodo CA but not for DigiCert. On this regard, the only evidence I provided to both of them was that the email address I used to contact them matched the contact information on my website. (My emails were protected with SPF, DKIM and DMARC for authenticity.) For some reason, DigiCert believed that this evidence did not met the Baseline Requirements for my request, a claim that I am currently unable to verify as I cannot find anything of the sort in them.
You can read the full story on my blog, which I hope will be sufficient to prove my identity: https://www.debigare.com/4-unexpected-issues-i-encountered-upon-switching-web-hosts/
I can also provide a full copy of the email exchange I had with Comodo CA as evidence on request.
Guillaume Fortin-Debigaré
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy
The wording for the new "validation of domain authorization or control [...] should not be relied upon" condition seems open to interpretation, so I'm not sure if it really applies here. Wouldn't it fully cover the "no longer legally permitted" condition as well in this case, making the latter redundant?
In any case, I should point out that even when taking into account the latest version of the BRs instead of the one that applied at the time (v.1.6.0), it would still have violated the "no longer legally permitted" condition that I previously quoted within the extended deadline of 5 days anyway.
Thanks again Wayne for the follow-up!
Sent: December 17, 2018 13:00
To: please please
Cc: MDSP
Subject: Re: Violation report - Comodo CA certificates revocation delays
On Sun, Dec 16, 2018 at 11:49 PM please please <pleasei...@hotmail.com<mailto:pleasei...@hotmail.com>> wrote:
I just noticed that Comodo CA has finally posted its incident report in https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
Comments:
- The report suggests that no BR violation occurred because I was not the Subscriber to fulfill the conditions in bullet point 1 of BR 4.9.1.1. However, I believe I fulfilled the conditions for triggering the 24 hours revocation anyway because of bullet point 6 of the same BR, which states "The CA is made aware of any circumstance indicating that use of a Fully Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. [...] a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated [...])", as I explicitly stated in my initial revocation request email that Cloudflare was no longer authorized to represent my domain but still controlled the private keys.
Sectigo's (formerly Comodo's) response does seem to both admit the violation and downplay it. Shortly after the violation the BRs were changed to allow 5 days for most revocations, and that may be the motivation for calling out that the Subscriber didn't request revocation. However, I believe this case still falls under the 24-hour rule due to 4.9.1.1(4):
The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon.
- Comodo CA claims that my request was "potentially ambiguous", but did not explain in what regard, nor did they ever asked me for clarifications. I can only assume as of now that the issue was to get an exhaustive list of certificates as I ran into the same problem and could not do so efficiently myself, but assumed Comodo CA would have had the means necessary to extract them easily from their own data based on my request.
I've requested more information in the bug. This may be a case of Sectigo falling back on the interpretation that the revocation clock doesn't start until the certificates have been identified. However, Sectigo also accepts responsibility by stating "The urgency of the revocation request was not adequately communicated as the request was passed along."
- I'm concerned that the incident report was posted more than 2 months past Mozilla's soft deadline to do so, especially when considering that the incident was also about being late to take necessary action for a deadline.
Yes, this is a concern. When a CA exhibits a pattern of slow responses, it is taken into consideration when Mozilla is making decisions about the CA, such as whether to include new roots.
Let me know if you need additional information from me to complete your assessment of the incident.
Guillaume Fortin-Debigaré
________________________________
From: please please <pleasei...@hotmail.com<mailto:pleasei...@hotmail.com>>
From: please please <pleasei...@hotmail.com<mailto:pleasei...@hotmail.com>>
Sent: October 11, 2018 19:19
To: Wayne Thayer
Cc: MDSP
Subject: Re: Violation report - Comodo CA certificates revocation delays
To: Wayne Thayer
Cc: MDSP
I was under the impression that CAs were allowed to remove CRL entries and OCSP support for expired certificates for some reason. Good to know!
On a slightly-unrelated note, you might also want to poke Comodo CA about https://bugzilla.mozilla.org/show_bug.cgi?id=1461391
Thanks again!
Guillaume Fortin-Debigaré
Subject: Re: Violation report - Comodo CA certificates revocation delays
I just poked Comodo in the bug - https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
CT Logs are designed such that certificates cannot be removed from them. The evidence will not disappear once the certificates expire.
On Wed, Oct 10, 2018 at 5:26 PM please please <pleasei...@hotmail.com<mailto:pleasei...@hotmail.com>> wrote:
Any update behind the scenes about this issue? I've noticed that the soft limit to fill an Incident Report expired more than a week ago, and I'm starting to be a bit worried that some of the evidence in the CT logs might disappear if the investigation is not completed before December 6th, the earliest expiration date among the affected certificates.
Guillaume Fortin-Debigaré
Any update behind the scenes about this issue? I've noticed that the soft limit to fill an Incident Report expired more than a week ago, and I'm starting to be a bit worried that some of the evidence in the CT logs might disappear if the investigation is not completed before December 6th, the earliest expiration date among the affected certificates.
Guillaume Fortin-Debigaré
________________________________
From: please please <pleasei...@hotmail.com<mailto:pleasei...@hotmail.com>>
Sent: September 17, 2018 23:39
From: please please <pleasei...@hotmail.com<mailto:pleasei...@hotmail.com>>
To: Wayne Thayer
Cc: MDSP
Subject: Re: Violation report - Comodo CA certificates revocation delays
Cc: MDSP
Good to know, and thank you very much for following up on this!
Small update by the way: I finally received a reply from Comodo CA confirming their 2nd wave of revocations a few hours ago, on September 17 at 16:55 UTC to be exact. Strangely, it was in response to an email where I informed them that I had already noticed they fully completed my revocation request. I don't think it's a relevant detail but I wanted to mention it to avoid any potential confusion.
Guillaume Fortin-Debigaré
________________________________
From: Wayne Thayer <wth...@mozilla.com<mailto:wth...@mozilla.com>>
Sent: September 17, 2018 20:09
To: pleasei...@hotmail.com<mailto:pleasei...@hotmail.com>
Cc: MDSP
Subject: Re: Violation report - Comodo CA certificates revocation delays
From: Wayne Thayer <wth...@mozilla.com<mailto:wth...@mozilla.com>>
Sent: September 17, 2018 20:09
To: pleasei...@hotmail.com<mailto:pleasei...@hotmail.com>
Cc: MDSP
I have created a bug and requested a response from Comodo: https://bugzilla.mozilla.org/show_bug.cgi?id=1492006
As noted, there are no specific requirements regarding how CAs validate revocation requests in the BRs. Every CA may do this however they choose, so I don't believe there is any action required in regard to DigiCert's response to their problem report.
- Wayne
Hello, I am the domain owner of debigare.com<http://debigare.com>. I would like to make you aware that Comodo CA took more than 5 days to revoke certificates they had signed for my domain and subdomains after requesting them to do through their sslabuse email address, past the 24 hours maximum mentioned in the Baseline Requirements as stipulated in section 4.9.1.1.
For context, I was previously using Cloudflare's Universal SSL feature, but disabling it did not revoke the old certificates that had not yet expired, but simply removed them from its system, and some of the certificates were still valid for more than 6 months.
I first attempted to contact Cloudflare's support to ask them to revoke the certificates themselves on September 6 at 7:43 UTC. This only led to irrelevant responses and confused customer support agents that had no idea what I was talking about, and this appeared to go nowhere. I eventually got a response from them on September 11 at 5:53 UTC that they would request CAs to perform the revocation, but that was after I did so myself, and I never got a status report back afterwards.
There were two CAs affected by this issue. The vast majority of certificates were signed by Comodo CA, and the rest by DigiCert. I did not run into any issues with DigiCert (they in fact proactively checked with Cloudflare my claim and revoked the certificates before I even had the chance to attempt their domain ownership challenge), but Comodo CA was another story entirely.
One detail that I'm not sure about is why my initial evidence for domain ownership was apparently sufficient for Comodo CA but not for DigiCert. On this regard, the only evidence I provided to both of them was that the email address I used to contact them matched the contact information on my website. (My emails were protected with SPF, DKIM and DMARC for authenticity.) For some reason, DigiCert believed that this evidence did not met the Baseline Requirements for my request, a claim that I am currently unable to verify as I cannot find anything of the sort in them.
You can read the full story on my blog, which I hope will be sufficient to prove my identity: https://www.debigare.com/4-unexpected-issues-i-encountered-upon-switching-web-hosts/
I can also provide a full copy of the email exchange I had with Comodo CA as evidence on request.
Guillaume Fortin-Debigaré
_______________________________________________
dev-security-policy mailing list
https://lists.mozilla.org/listinfo/dev-security-policy
Tim Hollebeek
Dec 17, 2018, 7:18:15 PM12/17/18
to dev-secur...@lists.mozilla.org
I don't think we've commented on this before, but I'll note that sending an
e-mail
from the e-mail address listed as the contact address on a website is not
one of
the approved methods of showing ownership or control of a website as
specified
in section 3.2.2.4. The approved methods of validating ownership or control
have undergone a lot of scrutiny, and the CA/Browser Forum continues to
spend
lots of its time trying to make them better.
Given the degree to which support and infrastructure is outsourced these
days,
it is tempting to say that merely comparing email addresses is a very, very
bad
way of confirming authenticity of requests and CAs should not rely on it.
Technical measures like SPF or DMARC do not mitigate the risk that the
sender
is not authorized to request revocation as they do not verify that the
sender
owns or controls the website that they are listed as the contact address
for.
CAs should not accept that as proof of ownership or control, and I'm happy
that
we didn't.
That said, the latest Baseline Requirements include Relying Parties as
someone
who can request revocation in section 4.9.2, in addition to "other third
parties".
This is basically anyone who has ever used a browser, which at this point is
most of the people on the planet. I'm not sure why we don't just say
"anyone
can submit a Certificate Problem Report", because it's functionally
equivalent
(and much less confusing). We take these requests very seriously, no matter
who they come from, and would encourage other CAs to do so as well.
Handling revocation requests within the mandated window is often very
challenging, but it's also very important to get right. The recent
clarifications
and improvements from Wayne's ballot do make things significantly better,
but this is still an area we should pay close attention to in order to make
sure
we get the balance right in making sure revocations happen quickly,
efficiently,
and most importantly, securely when they are necessary.
-Tim
> securit...@lists.mozilla.org<mailto:dev-security-
> dev-secur...@lists.mozilla.org<mailto:dev-security-
> pol...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy
from the e-mail address listed as the contact address on a website is not
one of
the approved methods of showing ownership or control of a website as
specified
in section 3.2.2.4. The approved methods of validating ownership or control
have undergone a lot of scrutiny, and the CA/Browser Forum continues to
spend
lots of its time trying to make them better.
Given the degree to which support and infrastructure is outsourced these
days,
it is tempting to say that merely comparing email addresses is a very, very
bad
way of confirming authenticity of requests and CAs should not rely on it.
Technical measures like SPF or DMARC do not mitigate the risk that the
sender
is not authorized to request revocation as they do not verify that the
sender
owns or controls the website that they are listed as the contact address
for.
CAs should not accept that as proof of ownership or control, and I'm happy
that
we didn't.
That said, the latest Baseline Requirements include Relying Parties as
someone
who can request revocation in section 4.9.2, in addition to "other third
parties".
This is basically anyone who has ever used a browser, which at this point is
most of the people on the planet. I'm not sure why we don't just say
"anyone
can submit a Certificate Problem Report", because it's functionally
equivalent
(and much less confusing). We take these requests very seriously, no matter
who they come from, and would encourage other CAs to do so as well.
Handling revocation requests within the mandated window is often very
challenging, but it's also very important to get right. The recent
clarifications
and improvements from Wayne's ballot do make things significantly better,
but this is still an area we should pay close attention to in order to make
sure
we get the balance right in making sure revocations happen quickly,
efficiently,
and most importantly, securely when they are necessary.
-Tim
> pol...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
0 new messages