RE: Violation report - Comodo CA certificates revocation delays

[Tim Hollebeek via dev-security-policy]

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

> -Original Message-
> From: dev-security-policy 
> On Behalf Of please please via dev-security-policy
> Sent: Monday, December 17, 2018 5:51 PM
> To: Wayne Thayer 
> Cc: MDSP 
> Subject: Re: Violation report - Comodo CA certificates revocation delays
> 
> 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!
> 
> Guillaume Fortin-Debigaré
> 
> 
> ____________
> From: Wayne Thayer 
> 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
> mailto:pleaseiwantt...@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
Certificat

Re: Violation report - Comodo CA certificates revocation delays

[please please via dev-security-policy]

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!

Guillaume Fortin-Debigaré



From: Wayne Thayer 
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 
mailto:pleaseiwantt...@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 
mailto:pleaseiwantt...@hotmail.com>>
Sent: October 11, 2018 19:19
To: Wayne Thayer
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!

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é

From: Wayne Thayer mailto:wtha...@mozilla.com>>
Sent: October 11, 2018 13:53
To: pleaseiwantt...@hotmail.com<mailto:pleaseiwantt...@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 
mailto:pleaseiwantt...@hotmail.com>> wrote:
Any update behind

Re: Violation report - Comodo CA certificates revocation delays

[Wayne Thayer via dev-security-policy]

On Sun, Dec 16, 2018 at 11:49 PM please please 
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 
> *Sent:* October 11, 2018 19:19
> *To:* Wayne Thayer
> *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!
>
> 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é
> --------------
> *From:* Wayne Thayer 
> *Sent:* October 11, 2018 13:53
> *To:* pleaseiwantt...@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 
> 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 
> *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

Re: Violation report - Comodo CA certificates revocation delays

[please please via dev-security-policy]

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 
Sent: October 11, 2018 19:19
To: Wayne Thayer
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!

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é

From: Wayne Thayer 
Sent: October 11, 2018 13:53
To: pleaseiwantt...@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 
mailto:pleaseiwantt...@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 
mailto:pleaseiwantt...@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é


From: Wayne Thayer mailto:wtha...@mozilla.com>>
Sent: September 17, 2018 20:09
To: pleaseiwantt...@hotmail.com<mailto:pleaseiwantt...@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 
mailto:dev-security-policy@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 co

Re: Violation report - Comodo CA certificates revocation delays

[waryde--- via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Rob Stradling via dev-security-policy]

On 19/10/2018 10:42, Ben Laurie wrote:
> On Fri, 19 Oct 2018 at 10:38, Rob Stradling wrote:


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.

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.


--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Ben Laurie via dev-security-policy]

On Fri, 19 Oct 2018 at 10:38, Rob Stradling  wrote:

> On 18/10/2018 22:55, Ben Laurie wrote:
> > On Fri, 12 Oct 2018 at 19:01, Rob Stradling 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  > > 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
> > 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?


>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@comodoca.com
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Rob Stradling via dev-security-policy]

On 18/10/2018 22:55, Ben Laurie wrote:

On Fri, 12 Oct 2018 at 19:01, Rob Stradling 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 mailto:b...@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
signed.


Put it in Trillian? :-)


That had occurred to me.  ;-)

Would it be useful?

--
Rob Stradling
Senior Research & Development Scientist
Email: r...@comodoca.com

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Ben Laurie via dev-security-policy]

On Fri, 12 Oct 2018 at 19:01, Rob Stradling  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  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
> signed.
>

Put it in Trillian? :-)


>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@comodoca.com
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Jakob Bohm via dev-security-policy]

On 12/10/2018 20:01, Rob Stradling 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  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 
signed.




FYI, the point would be for a third party to archive copies of the CRLs,
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.


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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Ben Laurie via dev-security-policy]

On Fri, 12 Oct 2018 at 16:41, Ryan Sleevi  wrote:

>
>
> On Fri, Oct 12, 2018 at 8:33 AM Ben Laurie  wrote:
>
>>
>>
>> On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy <
>> dev-security-policy@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.
>

I am, of course, not opposed to such archives, but the core reason
"transparency" is an improvement is that it practically and efficiently
prevents equivocation, which archives do not.

Perhaps you don't care about equivocation.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Ryan Sleevi via dev-security-policy]

On Fri, Oct 12, 2018 at 8:33 AM Ben Laurie  wrote:

>
>
> On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy <
> dev-security-policy@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Rob Stradling via dev-security-policy]

On 12/10/18 13:53, Jakob Bohm via dev-security-policy wrote:

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.

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Ben Laurie via dev-security-policy]

On Fri, 12 Oct 2018 at 13:54, Jakob Bohm via dev-security-policy <
dev-security-policy@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-security-policy@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.


>
> >
> >>
> >> On Thu, Oct 11, 2018 at 10:00 PM Matt Palmer via dev-security-policy <
> >> dev-security-policy@lists.mozilla.org> wrote:
> >>
> >>> On Thu, Oct 11, 2018 at 11:19:18PM +, 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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Jakob Bohm via dev-security-policy]

On 12/10/2018 14:33, Ben Laurie wrote:

On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy <
dev-security-policy@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.





On Thu, Oct 11, 2018 at 10:00 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On Thu, Oct 11, 2018 at 11:19:18PM +, 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Ben Laurie via dev-security-policy]

On Fri, 12 Oct 2018 at 03:16, Ryan Sleevi via dev-security-policy <
dev-security-policy@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.


>
> On Thu, Oct 11, 2018 at 10:00 PM Matt Palmer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > On Thu, Oct 11, 2018 at 11:19:18PM +, 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-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Robin Alden via dev-security-policy]

I understand the OP's concern and will respond to the bug shortly.

Regards
Robin Alden
Comodo CA Ltd.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Ryan Sleevi via dev-security-policy]

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 Thu, Oct 11, 2018 at 10:00 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Oct 11, 2018 at 11:19:18PM +, 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-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[Matt Palmer via dev-security-policy]

On Thu, Oct 11, 2018 at 11:19:18PM +, 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-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Violation report - Comodo CA certificates revocation delays

[please please via dev-security-policy]

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é

From: Wayne Thayer 
Sent: October 11, 2018 13:53
To: pleaseiwantt...@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 
mailto:pleaseiwantt...@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 
mailto:pleaseiwantt...@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é


From: Wayne Thayer mailto:wtha...@mozilla.com>>
Sent: September 17, 2018 20:09
To: pleaseiwantt...@hotmail.com<mailto:pleaseiwantt...@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 
mailto:dev-security-policy@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

Re: Violation report - Comodo CA certificates revocation delays

[Wayne Thayer via dev-security-policy]

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 
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 
> *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é
>
> --
> *From:* Wayne Thayer 
> *Sent:* September 17, 2018 20:09
> *To:* pleaseiwantt...@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-security-policy@lists.mozilla.org> wrote:
>
> 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 s

Re: Violation report - Comodo CA certificates revocation delays

[please please via dev-security-policy]

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 
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é


From: Wayne Thayer 
Sent: September 17, 2018 20:09
To: pleaseiwantt...@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 
mailto:dev-security-policy@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 
R

Re: Violation report - Comodo CA certificates revocation delays

[please please via dev-security-policy]

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 
Sent: September 17, 2018 20:09
To: pleaseiwantt...@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 
mailto:dev-security-policy@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-security-policy@lists.mozilla.org<mailt

Re: Violation report - Comodo CA certificates revocation delays

[Wayne Thayer via dev-security-policy]

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-security-policy@lists.mozilla.org> wrote:

> 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é
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Violation report - Comodo CA certificates revocation delays

[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 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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy