OK, revoke all at tomorrow morning since our time is 22:22 now. The cloudapp.net is revoked at the issuance time.
Thanks. Regards, Richard > On 29 Aug 2016, at 21:53, Patrick Figel <patfi...@gmail.com> wrote: > > Richard, > > the problem with this approach is that the *subscriber* might not be > authorized to make this decision for the parent domain. To go back to > the GitHub case, the "owner" of a github.io subdomain telling you that > they are authorized to own a certificate that covers github.io is > irrelevant, as they have never demonstrated ownership of that domain. > > The right approach would be to revoke the affected certificates > immediately and inform your subscribers that they will need to re-issue > their certificates (while also verifying ownership of the root domain). > > Here's another similar case - cloudapp.net, which belongs to Microsoft > Azure. I'm fairly certain this certificate was not authorized by Microsoft: > > https://crt.sh/?id=29805555 > > Thanks, > > Patrick > >> On 29/08/16 11:30, Richard Wang wrote: >> Yes, we plan to revoke all after getting confirmation from >> subscriber. We are doing this. >> >> Regards, >> >> Richard >> >>> On 29 Aug 2016, at 16:38, Gervase Markham <g...@mozilla.org> >>> wrote: >>> >>>> On 29/08/16 05:46, Richard Wang wrote: For incident 1 - >>>> mis-issued certificate with un-validated subdomain, total 33 >>>> certificates. We have posted to CT log server and listed in >>>> crt.sh, here is the URL. Some certificates are revoked after >>>> getting report from subscriber, but some still valid, if any >>>> subscriber think it must be revoked and replaced new one, please >>>> contact us in the system, thanks. >>> >>> Er, no. If these certificates were issued with unvalidated parent >>> domains (e.g. with github.com when the person validation >>> foo.github.com) then they need to all be revoked. You should >>> actively contact your customers and issue them new certificates >>> containing only validated information, and then revoke these ones. >>> >>> Gerv >>> >>> >>> _______________________________________________ dev-security-policy >>> mailing list dev-security-policy@lists.mozilla.org >>> https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
