Re: [cabfpub] Ballot SC 13 version 2

Nit: "for the" is incorrectly repeated in section 3.2.2.4.14: "See Appendix B for the for the format of the DNS TXT" From: Servercert-wg [mailto:servercert-wg-boun...@cabforum.org] On Behalf Of Tim Hollebeek via Servercert-wg Sent: Tuesday, November 20, 2018 10:17 AM To: CA/B Forum Server

Re: [cabfpub] [Servercert-wg] Ballot SC3: Improvements to Network Security Guidelines

That one I’m less sure about. I don’t think I would read that requirement as applying to one-time-use passwords, which I believe is what you’re describing. But perhaps there’s a way to make that more explicit if others disagree. I assume it wasn’t intentional to exclude such a use case.

Re: [cabfpub] [Servercert-wg] Ballot SC3: Improvements to Network Security Guidelines

I don’t think the proposed language has a requirement that the password NOT change. The requirement is that you don’t have a policy REQUIRING it to change simply based on its age, unless that time period is >= 2 years. Changing it more frequently than every 2 years in the event of an employee

Re: [cabfpub] Seeking Volunteers!

I'd be happy to volunteer for 3.2.2.4.6 (Agreed-Upon Change to Website). From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Tim Hollebeek via Public Sent: Tuesday, February 06, 2018 11:45 AM To: CA/Browser Forum Public Discussion List Subject: [cabfpub] Seeking Volunteers! I'm

Re: [cabfpub] Profiling OCSP & CRLs

Ah yes, good point. Both the private key of the responder cert AND the system used to generate the OCSP responses need to have comparable protections/controls to the private key of the associated online CA AND the system used to generate certificates from that CA. I believe if you achieve

Re: [cabfpub] Profiling OCSP & CRLs

Certainly the risk profile is greater for long-lived CRLs and long-lived OCSP responses than it is for long-lived OCSP responder certificates, since CRLs and OCSP responses could be replayed to hide a subsequent revocation without compromising the CA’s infrastructure, whereas doing bad things

Re: [cabfpub] Ballot 190

Peter’s examples are certainly cases for which we shouldn’t allow reuse. But I wonder if it is possible to constrain reuse based on things like this that we know are vulnerable, as opposed to blanket disallowing everything that doesn’t exactly follow the new rules. As a concrete example,

Re: [cabfpub] Mozilla SHA-1 further restrictions (v4)

>CAs may only sign SHA-1 hashes over issuing intermediates which chain >up to roots in Mozilla's program if the certificate to be signed is a >duplicate of an existing SHA-1 intermediate certificate with the only >change being the addition of an EKU to meet the requirements

Re: [cabfpub] Posted on behalf of customer

On 12/16/16, 9:27 AM, "Public on behalf of Gervase Markham via Public" wrote: >Well, _everyone's_ SHA-1 certificates which were issued in 2015 or 2016 > and which are part of the WebPKI expire at the latest on December 31st >