Re: wosign and letsencrypt.cn / letsencrypt.com.cn

Well, based on the previous deception of WoSign before, during and after Mozilla's investigation, I'm not remotely surprised to see this. On Friday, December 16, 2016 at 10:18:27 AM UTC-8, tde...@gmail.com wrote: > It seams that wosign has registered the domains letsencrypt.cn and >

Re: Policy 2.4 Proposal: Use language of capability throughout

Gervase Markham wrote: > On 10/12/16 21:25, Brian Smith wrote: >> Again, it doesn't make sense to say that the forms of names matter for >> name constraints, but don't matter for end-entity certificates. If an >> end-entity certificate doesn't contain any names of the forms

Re: Policy 2.4 Proposal: Require OCSP responses to be signed by certs with lifetime longer than response

On Fri, Dec 16, 2016 at 7:15 AM, Gervase Markham wrote: > When an OCSP response signing certificate expires before the OCSP > responses signed by the certificate expire, multiple websites break, > particularly sites that use OCSP stapling. Make it a requirement that > every OCSP

Re: Policy 2.4 Proposal: Use language of capability throughout

On Fri, Dec 16, 2016 at 09:41:08AM -0800, Ryan Sleevi wrote: > > Not trying to be snarky - just that if we're going to act upon your > comment, actionable data and concerns are needed. > > Put more concretely: > - Hypotheticals ("What about software foo?") should not be considered > unless

Re: SHA-1 exception First Data

By the way Gerv, in your flurry of posts to CA/B Forum public you comment "If I were going to calculate a SHA-1 collision, the certificate of a machine handling tens or hundreds of thousands of credit cards a day would be a reasonably obvious target, ISTM." This would need a second pre-image

Re: Policy 2.4 Proposal: Use language of capability throughout

On Fri, Dec 16, 2016 at 09:41:08AM -0800, Ryan Sleevi wrote: > On Fri, Dec 16, 2016 at 7:24 AM, Kurt Roeckx wrote: > > On 2016-12-16 15:45, Gervase Markham wrote: > >> > >> But secondly, I'm not banning the use of anyEKU, because Firefox doesn't > >> trust cert chains that rely on

wosign and letsencrypt.cn / letsencrypt.com.cn

It seams that wosign has registered the domains letsencrypt.cn and letsencrypt.com.cn in 2014 after the public announce of Let's Encrypt : whois letsencrypt.cn Domain Name: letsencrypt.cn ROID: 20141120s10001s72911711-cn Domain Status: clientTransferProhibited Registrant ID: k35-n2041486_00

Re: Audit Archiving in CCADB

Den 15-12-2016 kl. 00:12 skrev Kathleen Wilson: 1) Salesforce (in cloud) is using the default Java root store, which is smaller than Mozilla's root store. This accounts for the "sun.security.validator.ValidatorException: PKIX path building failed:" errors. We're not yet sure how to tell the

Re: Policy 2.4 Proposal: Use language of capability throughout

On Fri, Dec 16, 2016 at 7:24 AM, Kurt Roeckx wrote: > On 2016-12-16 15:45, Gervase Markham wrote: >> >> But secondly, I'm not banning the use of anyEKU, because Firefox doesn't >> trust cert chains that rely on it, so there's no need to ban it. Is there? > > > Can I point out

Re: Policy 2.4 Proposal: Use language of capability throughout

On 2016-12-16 15:45, Gervase Markham wrote: But secondly, I'm not banning the use of anyEKU, because Firefox doesn't trust cert chains that rely on it, so there's no need to ban it. Is there? Can I point out again that Firefox (or NSS) is not the only user of the root store? Kurt

Policy 2.4 Proposal: Define or remove the word "misused"

The word "misused" in the policy could do with clarifying. The Maintenance Policy states: "2. CAs must revoke Certificates that they have issued upon the occurrence of any of the following events: ... the CA obtains reasonable evidence that the subscriber’s private key (corresponding to the

Policy 2.4 Proposal: Update entropy requirements for EE certificates

Currently, the policy says: "all new end-entity certificates must contain at least 20 bits of unpredictable random data (preferably in the serial number)." We should require the random data to be in the serial number, and also update the number of bits required. BRs 1.3.7 and later say:

Policy 2.4 Proposal: Require OCSP responses to be signed by certs with lifetime longer than response

When an OCSP response signing certificate expires before the OCSP responses signed by the certificate expire, multiple websites break, particularly sites that use OCSP stapling. Make it a requirement that every OCSP response must have a nextUpdate field that is before or equal to the notAfter date

Re: Policy 2.4 Proposal: Require open licensing of CPs and CPSes

On 14/12/16 23:13, Eric Mill wrote: > Sure, that works. Is the "in writing" part necessary? You might say instead > "publicly accepted by Mozilla.", which would imply text on m.d.s.p or > bugzilla that would necessarily be in writing, while also ensuring better > visibility. I'm not sure what you

Re: Policy 2.4 Proposal: Require open licensing of CPs and CPSes

On 08/12/16 20:48, Gervase Markham wrote: > Require CAs to publish their CPs and CPSes under one of the following > Creative Commons licenses: CC-BY, CC-BY-SA or CC-BY-ND. > > This is so that there is no legal impediment to their proper storage, > scrutiny etc. by relying parties. > > Proposal:

Re: Policy 2.4 Proposal: Require all OCSP responses to have a nextUpdate field

On 08/12/16 20:47, Gervase Markham wrote: > Proposal: update the second bullet in point 3 of the Maintenance section > so that the last sentence reads: > > OCSP responses from this service must have a defined value in the > nextUpdate field, and it must be no more than ten days after the >

Re: Policy 2.4 Proposal: Use language of capability throughout

On 10/12/16 21:25, Brian Smith wrote: > Again, it doesn't make sense to say that the forms of names matter for > name constraints, but don't matter for end-entity certificates. If an > end-entity certificate doesn't contain any names of the forms dNSName, > iPAddress, SRVName, rfc822Name, then it

Re: Policy 2.4 Proposal: Use language of capability throughout

On 10/12/16 21:14, Brian Smith wrote: > "Unable to issue" means "unable to sign with the private key" which > can only happen if they don't have the private key. But they do have > the private key so they're always able to issue certificates with any > contents they want. Thus "unable to issue" is

Re: SHA256 for OCSP response issuer hashing

On 16/12/2016 12:22, Hanno Böck wrote: On Fri, 16 Dec 2016 02:51:47 +0100 Jakob Bohm wrote: [Snip: Discussion of potential odd client bug] ... I wonder if Let's Encrypt ever issued SHA-1 certificates, and if any of those are non-expired. Almost certainly not. Given

Re: SHA256 for OCSP response issuer hashing

On 16/12/2016 13:34, Jürgen Brauckmann wrote: Hanno Böck schrieb: I believe the potential problem is a different one: Systems that accept SHA256 on certificate signatures, but not on OCSP responses. I don't know if such systems exist, but if I had to make a bet I'd say they do. Roland does

Re: SHA256 for OCSP response issuer hashing

Hanno Böck schrieb: > I believe the potential problem is a different one: Systems that accept > SHA256 on certificate signatures, but not on OCSP responses. I don't > know if such systems exist, but if I had to make a bet I'd say they do. Roland does not talk about signature algorithms. He is

Re: SHA256 for OCSP response issuer hashing

On Fri, 16 Dec 2016 02:51:47 +0100 Jakob Bohm wrote: > I believe it would cause a problem with legacy systems that don't > understand SHA-256 signatures at all, noting that such systems will > only ever trust SHA-1 (and older) certificates, thus SHA-1 signing can > be