Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-16 Thread Ben Laurie via dev-security-policy
On Fri, 16 Aug 2019 at 14:31, Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> DB: Yes, that's true.  I was saying that phishing sites don't use EV, not
> that EV sites don't get phished

Surely this shows that EV is not needed to make phishing work, not that EV
reduces phishing?



-- 
I am hiring! Formal methods, UX, SWE ... verified s/w and h/w.
#VerifyAllTheThings.

https://g.co/u58vjr https://g.co/adjusu
*(Google internal)*
___
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

2018-10-19 Thread 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

2018-10-18 Thread 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

2018-10-12 Thread 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

2018-10-12 Thread 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

2018-10-12 Thread 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: GoDaddy Revocation Disclosure

2018-08-18 Thread Ben Laurie via dev-security-policy
On Fri, 17 Aug 2018 at 18:22, Daymion Reynolds via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Revoke Disclosure
>
> GoDaddy has been proactively performing self-audits. As part of this
> process, we identified a vulnerability in our code that would allow our
> validation controls to be bypassed. This bug would allow for a Random Value
> that was generated for intended use with Method 3.2.2.4.6 and 3.2.2.4.7 and
> was validated using Method 3.2.2.4.2 by persons who were not confirmed as
> the domain contact. This bug was introduced November 2014 and was leveraged
> to issue a total of 865 certificates. The bug was closed hours after
> identification, and in parallel we started the scope and revocation
> activities.
>
> In accordance with CA/B Forum BR, section 4.9.1.1, all miss-issued
> certificates were revoked within 24 hours of identification.
>
> A timeline of the Events for Revocation are as follows:
>
> 8/13 9:30am – Exploit issue surfaced as possible revocation event.
> 8/13 9:30-4pm – Issue scope identification (at this point it was unknown),
> gathering certificate list
> 8/13 4pm – Certificate list finalized for revoke total 825 certs, Revoke
> notification sent to cert owners.
>

I presume you mean domain owners?

Do we know if any of these certs were used? If so, how?


> 8/14 1:30pm – All certificates revoked.
>
> Further research identified 40 certificates which contained re-use of
> suspect validation information.
> 8/15 – 2pm – Additional certificates identified due to re-use.
> 8/15 – 2:30pm – Customers notified of pending revoke.
> 8/16 – 12:30pm – All certificated revoked.
>
> We stand ready to answer any questions or concerns.
> Daymion
>
> Certificate list which can be found in CRT.sh:
>
> Domain,CRT.sh link
> www.makancoaching.co.uk,https://crt.sh/?id=486518293
> www.superguttervac.co.uk,https://crt.sh/?id=484345622
> www.aloftimaging.co.uk,https://crt.sh/?id=486443992
> www.inverroycrisismanagement.com,https://crt.sh/?id=505471354
> *.lumeter.co.uk,https://crt.sh/?id=575952063
> theredstartprimaryschool.co.uk,https://crt.sh/?id=448982417
> www.glscoatings.co.uk,https://crt.sh/?id=471607541
> www.thelittlecakekitchen.co.uk,https://crt.sh/?id=622887520
> bri-lyncsbs1.corp.uxc.com.au,https://crt.sh/?id=445612142
> mel-lyncsbs1.corp.uxc.com.au,https://crt.sh/?id=445611906
> syd-lyncsbs1.corp.uxc.com.au,https://crt.sh/?id=445589055
> www.photislight.co.uk,https://crt.sh/?id=627260711
> sportsandplayconsulting.co.uk,https://crt.sh/?id=432887146
> *.mca.uk.net,https://crt.sh/?id=476788955
> www.underdogcoffee.co.uk,https://crt.sh/?id=445809844
> www.kiyoraspa.co.uk,https://crt.sh/?id=448128056
> www.kinesisclinic.co.uk,https://crt.sh/?id=444013056
> www.homegenies.co.uk,https://crt.sh/?id=490198693
> activemountaineering.co.uk,https://crt.sh/?id=452604481
> www.brightonshellfish.co.uk,https://crt.sh/?id=48433
> www.electroquip.co.uk,https://crt.sh/?id=454680891
> www.melbournederbyshire.co.uk,https://crt.sh/?id=459144464
> iih.org.uk,https://crt.sh/?id=452613519
> *.growhub.co.uk,https://crt.sh/?id=445804391
> www.weaversguesthouse.co.uk,https://crt.sh/?id=516764585
> *.ctc-solutions.co.uk,https://crt.sh/?id=508837605
> thothmail.saqqara.co.uk,https://crt.sh/?id=627917932
> www.ringwoodhallhotel.com,https://crt.sh/?id=456471228
> remote.yachtingpages.com,https://crt.sh/?id=453013515
> www.waynesecigsupplies.co.uk,https://crt.sh/?id=484348665
> www.thoth.saqqara.co.uk,https://crt.sh/?id=477514633
> remote.mara.uk.com,https://crt.sh/?id=491400207
> www.needfulthings.uk.com,https://crt.sh/?id=458812648
> www.sensoryapphouse.com,https://crt.sh/?id=460684499
> www.youcanbecome.co.uk,https://crt.sh/?id=486521955
> *.speechbuilder.co.uk,https://crt.sh/?id=465020837
> www.somerville-house.co.uk,https://crt.sh/?id=513011072
> www.cameoclassics.co.uk,https://crt.sh/?id=627503851
> praxis-godesberger-allee.de,https://crt.sh/?id=491408016
> www.hydra-te.co.uk,https://crt.sh/?id=505470107
> *.mca.uk.net,https://crt.sh/?id=476788955
> *.mhsserver5.com,https://crt.sh/?id=575963842
> www.dormagen-anwalt.de,https://crt.sh/?id=487910728
> rosenbaumgruppe.eu,https://crt.sh/?id=484075777
> remote.micheloud.net,https://crt.sh/?id=491387626
> webmail.janssensmarket.com,https://crt.sh/?id=527896643
> www.collegeinabox.co.uk,https://crt.sh/?id=500425581
> www.lepetitcapelier.com,https://crt.sh/?id=497736247
> www.total-michel.com,https://crt.sh/?id=486035156
> www.thetoolbox.uk.com,https://crt.sh/?id=486038438
> www.theinformer.org.uk,https://crt.sh/?id=488179681
> outlook.comprovide.de,https://crt.sh/?id=575914237
> www.vellastar.com,https://crt.sh/?id=493898204
> mail.iarg.com.au,https://crt.sh/?id=501369255
> www.iplacenotes.com,https://crt.sh/?id=487635287
> isiportalorders.com,https://crt.sh/?id=496718880
> www.ostsee-grundbesitz.de,https://crt.sh/?id=518520334
> invia-koeln.de,https://crt.sh/?id=489938629
> www.nikkihalliwell.com,https://crt.sh/?id=510581809
> 

Re: How do you handle mass revocation requests?

2018-03-01 Thread Ben Laurie via dev-security-policy
On 28 February 2018 at 21:37, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wed, 28 Feb 2018 20:03:51 +
> Jeremy Rowley via dev-security-policy
>  wrote:
>
> > The keys were emailed to me. I'm trying to get a project together
> > where we self-sign a cert with each of the keys and publish them.
> > That way there's evidence to the community of the compromise without
> > simply listing 23k private keys. Someone on Reddit suggested that,
> > which I really appreciated.
>
> That's probably me (tialaramex).
>
> Anyway, if it is me you're referring to, I suggested using the private
> keys to issue a bogus CSR. CSRs are signed, proving that whoever made
> them had the corresponding private key but they avoid the confusion
> that comes from DigiCert (or its employees) issuing bogus certs.
> Everybody reading m.d.s.policy can still see that a self-signed cert is
> harmless and not an attack, but it may be harder to explain in a
> soundbite. Maybe more technically able contributors disagree ?
>

Seems to me that signing something that has nothing to do with certs is a
safer option - e.g. sign random string+Subject DN.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: How do you handle mass revocation requests?

2018-03-01 Thread Ben Laurie via dev-security-policy
On 28 February 2018 at 19:40, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> The end user agreed to the subscriber agreement, not Trustico. Our
> analysis follows what Peter B. posted – the subscriber is the “natural
> person or Legal Entity to whom a Certificate is issued and who is legally
> bound by a Subscriber Agreement or Terms of Use"—which in this case was
> Trustico’s customers.  In addition, we felt that given (1) the number of
> certificates Trustico was asking us to mass-revoke and (2) the lack of any
> substantiation of why Trustico thought the certs were “compromised,” we
> needed more information before revoking. At the minimum, it warranted
> alerting the contact for each certificate that revocation was imminent.
>
>
>
> I also agree that there’s no problem with the way or that the keys were
> provided to DigiCert for cert revocation.


Agree with who? Both asking for the keys and providing them seems weird to
me.

The more secure thing to do would be to ask for proof of possession of the
keys, e.g. by signing a random string with them...


> I certainly don’t want to discourage revocation of compromised certs!  My
> main question is how do you handle these things? The process at scale
> should not be different if a reseller requests revocation compared to any
> other security researcher. The question is how you handle the this volume
> of revocations when its happen? I’ve never received a revocation request of
> this magnitude before so I’m seeking the wisdom of the community in what we
> do.
>
>
>
> I’m happy to share any of the details I can.
>
>
>
> Jeremy
>
>
>
>
>
> From: Ryan Sleevi 
> Sent: Wednesday, February 28, 2018 11:58 AM
> To: Jeremy Rowley 
> Cc: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: How do you handle mass revocation requests?
>
>
>
>
>
>
>
> On Wed, Feb 28, 2018 at 12:37 PM, Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org  lists.mozilla.org> > wrote:
>
> On February 2nd, 2018, we received a request from Trustico to mass revoke
> all certificates that had been ordered by end users through Trustico.
> Unfortunately, the email was not sent to the appropriate certificate
> problem
> reporting channels and did not surface immediately so we're delayed in
> sharing the concerns and information. Once we were alerted, the team kicked
> off a debate that I wanted to bring to the CAB Forum. Basically, our
> position is that resellers do not constitute subscribers under the Baseline
> Requirement's definitions (Section 1.6.1). As such, we needed to confirm
> that either the key was compromised or that they revocation was authorized
> by the domain holder (the subscriber) prior to revoking the certificate.
> The
> certificates were not alleged as compromised at that time.
>
>
>
> I think there's a little nuance to this in the general case (e.g. consider
> "Resllers" who are also the hosting provider, and thus constitute the
> Applicant/Subscriber even when they're not the domain holder, but
> authorized by them), but based on this specific case, I think this sounds
> like a correct determination.
>
>
>
> I think the biggest question is who agreed to the terms - Trustico or the
> end-user - and that mostly impacts the rest of the decision here. Further,
> did Trustico warrant on behalf of the user that the user agreed to the
> terms (in which case, I would think it's a bit of a copout, and it's really
> Trustico agreeing, thus the Subscriber), or did DigiCert have direct
> communication with the user on the basis of Trustico's introduction (in
> which case, yeah, the Subscriber is the user)
>
>
>
> Anyway, just highlighting it here as perhaps not a uniform consensus, but
> perhaps not as material as what follows.
>
>
>
> On 2/27/2018, at my request for proof of compromise, we received a file
> with
> 23k private keys matched to specific Trustico customers. This definitely
> triggered our 24-hour revocation processing requirement under 4.9.1.1.3.
> Once we received the keys, we confirmed that these were indeed the matching
> private keys for the reported certificates. We will be revoking these
> certificates today (February 28th, 2018).
>
>
>
> I think all of this sounds reasonable, no different than a security
> researcher (or random member of the public) who were to claim compromise
> with no evidence of that.
>
>
>
> Currently, we are only revoking the certificates if we received the private
> keys. There are additional certificates the reseller requested to have
> revoked, but DigiCert has decided to disregard that request until we
> receive
> proof of compromise or more information about the cause of this incident.
>
>
>
> For the same reason that "Jane Random User" should not be able to cause
> revocation merely by assertion, I think that sounds reasonable.
>
>
>
> This raises a question about the MDSP policy and 

Re: Anomalous Certificate Issuances based on historic CAA records

2017-11-29 Thread Ben Laurie via dev-security-policy
On 29 November 2017 at 22:33, Paul Wouters <p...@nohats.ca> wrote:

>
>
> > On Nov 29, 2017, at 17:00, Ben Laurie via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > This whole conversation makes me wonder if CAA Transparency should be a
> > thing.
>
> That is a very hard problem, especially for non-DNSSEC signed ones.
>

Presumably only for non-DNSSEC, actually? For DNSSEC, you have a clear
chain of responsibility for keys, and that is relatively easy to build on.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Anomalous Certificate Issuances based on historic CAA records

2017-11-29 Thread Ben Laurie via dev-security-policy
This whole conversation makes me wonder if CAA Transparency should be a
thing.

On 29 November 2017 at 20:44, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> The Thawte records aren't showing any CAA record preventing wildcards
> either.
>
> Here's the Thawte CAA record logs for the domain:
>
> 2017-09-13 05:25:09.117 [pool-3058695-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - Lookup domain: trnava-vuc.sk type: 257 result: 4 lookupTimeout: 500
> 2017-09-13 05:25:09.117 [pool-3058693-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - Looking for alias for: trnava-vuc.sk
> 2017-09-13 05:25:09.117 [pool-3058696-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - Lookup domain: trnava-vuc.sk type: 5 result: 4 lookupTimeout: 750
> 2017-09-13 05:25:09.117 [pool-3058692-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - CAAResponse: CAAMatchCode : [32] : CAAInput : [trnava-vuc.sk] :
> CAAMatchMessage : [CAA record not found] : CAADNSRecords : [ ]
> 2017-09-13 05:25:09.118 [pool-3058691-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - Time taken in seconds for CAA check of trnava-vuc.sk is: 1
> 2017-09-13 05:25:09.118 [pool-3058693-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - CAAResponse: CAAMatchCode : [32] : CAAInput : [*.trnava-vuc.sk] :
> CAAMatchMessage : [CAA record not found] : CAADNSRecords : [ ]
> 2017-09-13 05:25:09.118 [pool-3058691-thread-2] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - Time taken in seconds for CAA check of *.trnava-vuc.sk is: 2
>
> Jeremy
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of
> douglas.beattie--- via dev-security-policy
> Sent: Wednesday, November 29, 2017 4:27 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Anomalous Certificate Issuances based on historic CAA records
>
> Hi Quirin,
>
> I'm curious about how you recorded the historical information from DNS,
> can you explain how this was requested and logged?
>
> We logged the data used for issuance of the GlobalSign certificate at the
> time of issuance and it's different from what you recorded.
>
> We logged that there was no “issuewild” entry and that "digicert.com", "
> globalsign.com", "letsencrypt.org" and "rapidssl.com" are all defined as
> “issue” at time of issuance.
>
> Doug
>
> On Friday, November 24, 2017 at 7:23:25 AM UTC-5, Gervase Markham wrote:
> > Hi Quirin,
> >
> > Thank you for your work on this topic. I would be grateful if you
> > could file Bugzilla bugs in the Misissuance component as follows,
> > giving your evidence of misissuance:
> >
> > On 22/11/17 23:50, Quirin Scheitle wrote:
> > > 1) Mix of wildcard and non-wildcard DNS names in SAN
> > > Batch: https://clicktime.symantec.com/a/1/
> 4dVQ4kGvYsWRmDR0QMfBBhhwpXEgvnl0A7TEgxMQx-Y=?d=rkGEi9PYD9VAuJcuuNl_
> 82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_
> 74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-
> IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noAPAfEow_
> 4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD
> 8H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_
> 01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_
> 6EcFLl2sGoNa120tlyjhfxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-
> D5Fa2kjOEax5n8dtFGFmTHF6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SB
> e=https%3A%2F%2Fmisissued.com%2Fbatch%2F32%2F
> > > Description: best confer
> > > https://clicktime.symantec.com/a/1/bRWz8YI8GaFJN5p0wMSlE_HKuFXeSpidx
> > > EosAdBNIhw=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTF
> > > qzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1B
> > > sUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noA
> > > PAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8
> > > H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt
> > > 1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjh
> > > fxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF
> > > 6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe=https%3A%2F%2Fgroups.google
> > > .com%2Fd%2Fmsg%2Fmozilla.dev.security.policy%2FO9HZPMvHMY8%2FHtXR8S-
> > > 1AAAJ
> >
> > One bug per CA, please.
> >
> > > 4) Apparent non-evaluation of CAA records
> > > Batch: https://clicktime.symantec.com/a/1/ZSn0R3LPoUJA--
> jAELl6kXSjRsrKYmYOKsgQn5Gve1U=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-
> CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgt
> uvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0Lh
> TmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__
> 1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHo
> xoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-
> J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4
> WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3C
>