Re: Misissuance/non-compliance remediation timelines

2018-02-06 Thread Ryan Sleevi via dev-security-policy
So your view is the “carrot” is getting to use Mozilla’s brand as an endorsement, and the “stick” being that if you don’t get that endorsement for a while, you get kicked out? The assumption is that the branding of “best” is valuable - presumably, through the indirect benefit of being able to

RE: Misissuance/non-compliance remediation timelines

2018-02-06 Thread Tim Hollebeek via dev-security-policy
Absolutely not. I view the competition as being based as the “most best”. You cannot get an “A” (or even A- or B+) without significantly exceeding the minimum requirements, or demonstrating behaviors and practices that, while not required, are behaviors Mozilla wants to encourage.

Misissuance/non-compliance remediation timelines

2018-02-06 Thread Paul Kehrer via dev-security-policy
A bit over 5 months ago I reported a series of OCSP responders that were violating BRs (section 4.9.10) by returning GOOD on unknown serial numbers. Since that time the majority of those responder endpoints have been fixed, but several are still non-compliant; either with little communication or

Re: ComSign Root Renewal Request

2018-02-06 Thread Wayne Thayer via dev-security-policy
Yair, > Re Section 3.4, you seem to assume the domain holder is a ComSign > > subscriber. In case of misissuance, that may not be true. > >>> I understand, for that we added on the CPS on section 3.4 the > following: > "For the handling of revocation requests by other than the Subscriber or >

Re: Japan GPKI Root Renewal Request

2018-02-06 Thread apca2.2013--- via dev-security-policy
Below is the answer to the pointed out earlier. == Bad == * CPS docs are not assigned a version number (Mozilla policy 3.3) We had set up CP / CPS version number assignment rules. Based on this, at present CP / CPS Root version is Ver. 1.05 and CP / CPS Sub version is 1.07. We attached CP /

Re: Certificates with 2008 Debian weak key bug

2018-02-06 Thread Kurt Roeckx via dev-security-policy
On 6/02/2018 17:10, Ryan Sleevi wrote: The BRs actually seem to allow this, which at least looks like a bug in the BRs to me. It is allowed, and it's not a bug. It's specifically called out in 3.2.2 of the BRs. It seems that under 3.2.2.3 (b) they can just copy the ccTLD from the domain

Re: Certificates with 2008 Debian weak key bug

2018-02-06 Thread Ryan Sleevi via dev-security-policy
On Tue, Feb 6, 2018 at 10:48 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 5/02/2018 17:08, Hanno Böck wrote: > >> https://crt.sh/?id=308392091=ocsp >> > > It has: > Subject: > commonName= ftp.gavdi.pl >

Re: Certificate for com and it

2018-02-06 Thread Kurt Roeckx via dev-security-policy
On 6/02/2018 16:52, Kurt Roeckx wrote: On 6/02/2018 12:20, Hanno Böck wrote: Issuer is "Intesa Sanpaolo CA Servizi Esterni Enhanced", which is a subca of Baltimore Cybertrust, which belongs to Digicert. That certificate is revoked, not trusted by Mozilla or chrome. I should probably more

Re: Certificate for com and it

2018-02-06 Thread Kurt Roeckx via dev-security-policy
On 6/02/2018 12:20, Hanno Böck wrote: Issuer is "Intesa Sanpaolo CA Servizi Esterni Enhanced", which is a subca of Baltimore Cybertrust, which belongs to Digicert. That certificate is revoked, not trusted by Mozilla or chrome. Kurt ___

Re: Certificates with 2008 Debian weak key bug

2018-02-06 Thread Kurt Roeckx via dev-security-policy
On 5/02/2018 17:08, Hanno Böck wrote: https://crt.sh/?id=308392091=ocsp It has: Subject: commonName= ftp.gavdi.pl countryName = PL This looks like a combination that's not allowed. Either it's domain validated, in which case it should

Certificate for com and it

2018-02-06 Thread Hanno Böck via dev-security-policy
This certificate https://crt.sh/?id=282908507 is issued for the names "com" and "it". It also contains other suspicious hostnames: sip.fideuram sip.consule sip.consultant.fideura I don't think these TLDs exist. Issuer is "Intesa Sanpaolo CA Servizi Esterni Enhanced", which is a subca of

Re: ComSign Root Renewal Request

2018-02-06 Thread YairE via dev-security-policy
On Monday, February 5, 2018 at 6:03:55 PM UTC+2, Julien Cristau wrote: > Re Section 3.4, you seem to assume the domain holder is a ComSign > subscriber. In case of misissuance, that may not be true. >>> I understand, for that we added on the CPS on section 3.4 the following: "For the handling of

Re: Validation Summit

2018-02-06 Thread Kim Nguyen via dev-security-policy
Am Montag, 5. Februar 2018 22:31:46 UTC+1 schrieb Wayne Thayer: > Gerv and I have made, and the CA/Browser Forum has accepted a proposal to > convene a "Validation Summit" on Tuesday March 6th during the next > regularly scheduled CA/Browser Forum face-to-face meeting that will be held > in the