Re: Anomalous Certificate Issuances based on historic CAA records

On Wed, 29 Nov 2017 22:37:08 + Ben Laurie via dev-security-policy wrote: > 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. For DNSSEC a CA could (and

Re: Anomalous Certificate Issuances based on historic CAA records

On 29 November 2017 at 22:33, Paul Wouters 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

Re: Anomalous Certificate Issuances based on historic CAA records

> On Nov 29, 2017, at 17:00, Ben Laurie via dev-security-policy > 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. Paul

RE: Anomalous Certificate Issuances based on historic CAA records

Yes, CAA transparency should exist. Right now CAA is only a point-in-time check by the CA with no way to verify what the CA saw or what was processed. This was one of the limitations raised during the discussions about adoption. Without some transparency, the reliance is on the CA to ensure the

Re: Anomalous Certificate Issuances based on historic CAA records

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

Re: Warning about posting via Google Groups

On Monday, November 20, 2017 at 7:51:59 AM UTC-8, Gervase Markham wrote: > Dear m.d.s.p., > > We appear to again have a problem with messages posted via the Google > Groups web UI making it to all subscribers on the list: > https://bugzilla.mozilla.org/show_bug.cgi?id=1412993 > > Until that

Re: test - please ignore this thread

On Wednesday, November 29, 2017 at 1:39:54 PM UTC-8, Kathleen Wilson wrote: > Please ignore this email thread. > > In order for folks to debug the problem of posts to > mozilla.dev.security.policy not getting propagated to Google Groups, they > need email headers that are less than 8 days old.

test - please ignore this thread

Please ignore this email thread. In order for folks to debug the problem of posts to mozilla.dev.security.policy not getting propagated to Google Groups, they need email headers that are less than 8 days old. Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=1412993 Thanks, Kathleen

Re: Mozilla RSA-PSS policy

On Wed, Nov 29, 2017 at 1:09 PM, Hubert Kario wrote: > > The extent of the argument for flexibility, so far, has been OpenSSL's > > behaviour to produce RSA-PSS signatures with a maximal salt length. These > > same clients are also incapable of parsing RSA-PSS SPKIs (that only

RE: Anomalous Certificate Issuances based on historic CAA records

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

Re: Mozilla RSA-PSS policy

On Wednesday, 29 November 2017 17:00:58 CET Ryan Sleevi wrote: > On Wed, Nov 29, 2017 at 7:55 AM, Hubert Kario via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > Because I do not consider making the salt length rigid (one value allowed > > for > > every hash) to be of

Re: Mozilla RSA-PSS policy

On Wed, Nov 29, 2017 at 7:55 AM, Hubert Kario via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > > The fact that this new NSS implementation does not properly validate the > > well-formedness of these signatures is somewhat in conflict with your > > statement: > > ""it

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