On Tue, Sep 11, 2018 at 07:22:18AM -0700, josselin.allemandou--- via
dev-security-policy wrote:
> It is important to remember that our CA is also subject to compliance with
> national standards (e.g. RGS) which are more stringent for some controls
> than ETSI standards or BRs. These standards
在 2018年9月1日星期六 UTC+8上午7:19:49，Wayne Thayer写道：
> * The CP/CPS documents contain version histories, but they didn’t describe
> what changed in each version. SHECA began including this information in the
> latest versions of these documents.
> * The non-EV CP and CPS section 6.1 seem to permit CA
Hello,
Thank you for your contribution. We hope that the returns below will allow you
to better understand our past practices that led to the creation of this ticket.
It is important to remember that our CA is also subject to compliance with
national standards (e.g. RGS) which are more
On Tue, Sep 11, 2018 at 12:34:34AM -0700, josselin.allemandou--- via
dev-security-policy wrote:
> This failure is related to our old practices that led to a control of the
> DNS CAA records with automatic alerts for the Registration Officers, but
> the blocking of the certificate request was not
Hello,
Thanks Wayne and Devon for your reply.
We took the time to respond because we wanted to verify through an audit that
the SSL certificate requests processed since September 8th were in compliance
with the CA/B Forum requirements for DNS CAA record checks.
In general, this has been the
The audit of our previous CAA check practices ensured that the CA/B Forum
requirements were met except for a single certificate for which the CA was not
authorized to issue according to the DNS CAA record.
This failure is related to our old practices that led to a control of the DNS
CAA
6 matches
Mail list logo
