在 2018年9月1日星期六 UTC+8上午10:24:35，David E. Ross写道： > On 8/31/2018 4:19 PM, Wayne Thayer wrote [in part]: > > * A few unrevoked certificates with IP Addresses encoded as DNSName type in > > the SAN [4]. I reported these to SHECA in this bug and they said that they > > would revoke them, but as of this writing they are still valid. > > This public comment period should be extended until the affected > certificates are indeed revoked. SHECA has evaluated the affect and security risk, we conducted an Delayed Revocation Report. I will update the report and communication evidence on Monday(don't have them on my hand now).
basically, the subscriber of these certificates is a financial institution, their coding and system update workflow is very strict and complicated. We have informed them repeatedly that the certificates have security risk, and need to be revoked and replaced by updated ones according to CABF requirement. They claim that revocation can only be done during system update or there will be important affect to their service operation. As of this comment, the subscriber still has not taken any action to upgrade their system. SHECA is planning to send a final notification letter next week, if they don't have update plan in one week, we will directly take revocation action. > > > * Version 1.3 of the Global G2 Root CP and version 3.6 of the Global G2 > > Root CPS were published more than a year after the prior versions in > > violation of Mozilla policy section 3.3. > > How do we know this will not happen again? While we do maintain CP/CPS update at least once annually but this time we ignorant the 365 days gap limitation between each version. To avoid this issue happen again, we are now adding this limitation into SHECA CP/CPS periodical review checklist. SHECA will publish CP/CPS Review Report in the repository (https://www.sheca.com/repository) of SHECA’s official website semi-annually. > > > * 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. > > Have the version histories been fixed to include all prior changes? How > do we know this will not happen again? We only include changes description of the latest version now. While we will add the prior changes description in next week. In addition, SHECA keep the historical versions CP/CPS accessible on our official website. All the previous version can be got in Previous Documents part in this link: https://www.sheca.com/repository > > > > * The non-EV CP and CPS section 6.1 seem to permit CA generation of key > > pairs for SSL certificates in violation of section 5.2 of Mozilla policy. > > SHECA states that they have never generated key pairs for Subscribers and > > revised this section of the CPS, but my interpretation is that the revision > > does not forbid SHECA from generating subscriber key pairs. > > This public comment period should be extended until the affected > documents make this clear enough to support an audit that verifies key > pairs are not be generated. No, I am not suggesting that such an audit > is required at this time. I am merely saying that the documents must > provide clear, objective statements against which an auditor can > determine if the Mozilla policy is being followed. > We definitely mean that SHECA don’t generate key pairs for subscribers by stating “Generation of subscriber signing key pair should be performed by subscribers” in section 6.1.1 of latest version. So as for the interpretation problem mentioned by Wayne, We can revise our CPS, emphasizing “For certificates issued by UCA Global G2 Root and UCA Extended Validation Root, SHECA must not generate key pair for subscribers.” Also we will clearly, objectively state in CP/CPS that the WebTrust auditor can determine that CA didn’t generate key pair of SSL certificate during every Audit Period (for SHECA, is May, last year to April，next Year), according to the CABF requirement. Regards, Toria Chen ---------------- Chen Xiaotong Dept. of Strategic Development Shanghai Electronic Certificate Authority Center Co.,Ltd. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
