Dear Ben, We have completed the revision of the new version of CP/CPS and are going through the internal release process, which will be updated to our official website for review within a week.
Regards, vTrus Team 在2021年9月1日星期三 UTC+8 上午11:56:30<[email protected]> 写道： > Dear vTrus Team, > Do we have an estimate for when you might have an updated CPS ready for > another review? > Thanks, > Ben > > On Wed, Aug 25, 2021 at 12:48 AM yutian zheng <[email protected]> > wrote: > >> Hi Ryan, >> >> Thank you very much for these questions, and we have checked our CP/CPS >> and corresponding business for these items, the answers are as follows: >> >> *1. **Although the CCADB Policy does not require CAs make their >> CP/CPS authoritative in English, it does require that the CA attest the >> information is not materially different. In their CPS, 1.2, they clearly >> state that the English version is not authoritative, and that in any >> conflicts, the Chinese version prevails, but there's no such assurance >> about equivalence.* >> >> iTrusChina’s CP/CPS has a strict Chinese and English correspondence, >> which can ensure that there is no substantial difference in information. We >> will modify the description here in the new version of CP/CPS. >> >> *New description: *The Chinese version of this CPS is issued. iTrusChina >> sincerely guarantees that there is no materially difference between the >> Chinese and English versions of the information. >> >> >> >> *2. **Section 3.1.6 states both that "Certificates issued by >> iTrusChina does not contain any trademarks or other information which may >> infringe other parties' rights" and that "iTrusChina don't validate >> trademark right or legal disputes when processing applications", which... >> seems to be conflicting.* >> >> We will modify the description in the next version of CP/CPS. >> >> *New description: *iTrusChina does not verify an Applicant’s right to >> use a trademark and does not resolve trademark disputes. >> >> >> >> *3. **Section 3.2.2.6 has an interesting statement regarding which >> entities are allowed to obtain wildcards; seemingly preventing them from DV >> certificates. This seems unfortunate and unnecessary, and while not >> prohibited, is at least something that stands out as perhaps misaligned in >> goals / understanding of the purpose of TLS certificates.* >> >> The description of 3.2.2.6 is indeed ambiguous and we will modify it. In >> fact, we are issuing DV wildcard certificates. >> >> *New description: *Regarding a wildcard domain name, iTrusChina verifies >> the domain name on the right side of the wildcard to ensure that the domain >> name is clearly owned by the applicant. >> >> >> >> *4. **Section 3.2.2.6 also includes an interesting clause "If >> necessary, iTrusChina needs to adopt other independent authentication >> methods to confirm the ownership of a domain name." It's unclear if that's >> meant in addition to 3.2.2.4, or in lieu of 3.2.2.4.* >> >> We only use the domain verification method mentioned in 3.2.2.4, so we >> think our description is indeed ambiguous, and we will delete it in the >> next version of CP/CPS. >> >> >> >> *5. **Section 3.2.2.8 has a real red flag: "If the tag 'iodef' >> exists in CAA records, iTrusChina will determine whether to issue the >> certificate after communicating with the applicant".* >> >> *It's unclear if they're treating this as permission to issue >> if the tag exists, which would be a BR violation.* >> >> It*'s unclear if they're redefining the semantics of iodef >> (which is used for exception reports / violations, not for permission)* >> >> Our description of iodef is incorrect and will be revised in the next >> version of CP/CPS. >> >> *New description: *When the certificate requests or issuances violate >> the security policy of the Issuer or the FQDN holder，if the tag "iodef" >> exists in CAA records, iTrusChina will dispatch reports of such issuance >> requests to the contact(s) stipulated in the CAA iodef record(s). >> >> >> >> *6. **Section 6.1.1.1 has a similar red flag "Since China has >> strict administration requirements on cryptographic products, FIPS 140-2 >> Standard is not a standard approved and supported by the State Cryptography >> Administration, FIPS 140-2 Standard is only enforced as a reference, >> selectively applicable on the premise of passing the evaluation and >> certification of the State Cryptography Administration and being licensed >> by national cryptography administration policies."* >> >> *This reasonably calls into question the safety and security of the >> CAs' private keys. Similar remarks are found within Section 6.2.1.* >> >> China has corresponding technology and testing standards for HSM. For >> compliance reasons, we must use HSM products from manufacturers licensed by >> the State Cryptography Administration. This requirement is also applicable >> to other licensed CAs in China. Our supplier's HSM products obtained FIPS >> 140-2 level 3 certification in 2019 (see attachment). If necessary, we can >> replace HSM later. >> >> >> >> *7. **Section 6.1.1.2 "If a subscriber submits a PKCS#10 file of a >> weak algorithm during application, iTrusChina will reject the application >> and recommend the user to generate a new key pair" - this proof of >> possession provides no benefit in the context of TLS, and so this is a >> rather silly check. This has been discussed in the past here on m.d.s.p.* >> >> There are some problems with our statement here. What we meant to express >> is that we will reject the application if we find that the subscriber is >> using a Debian weak key (as described in BR6.1.1.3), we will modify it in >> the next version CP/CPS. >> >> >> >> *8. **Section 6.3.2 makes it clear that intermediates are generated >> very long (25 years), while the clear trend of industry has been moving >> towards shorted lived intermediates, and regularly rotating them, to ensure >> necessary certificate agility and robustness.* >> >> At present, we have not formulated a policy for regular replacement of >> intermediate roots. Considering the agility and robustness of the >> certificate, we will issue new intermediate root certificates with a >> shorter age in the future. >> >> >> >> *9. **Section 7.1.2 is not that useful (e.g. the EKU for >> intermediates just says (paraphrased) "We'll put something here after >> 2019-01-01"). Similarly the notBefore/notAfter remarks.* >> >> iTrusChina plans to generate some intermediate CA certificates after >> 2019-01-01, and the intermediate certificates generated before this do not >> contain the EKU extension. According to the requirements of Mozilla's Root >> policy, the intermediate certificate generated after 2019-01-01 needs to >> include the EKU extension, so we have added this description. >> >> >> >> 10. Regarding the issue of EV Certificates Registration Agency >> Disclosure, the data sources we disclose are not only EV certificates, but >> also information sources for all other types of SSL certificates. The >> Unified Social Credit Code Certificate and Dun and Bradstreet are used for >> the Subject field of the SSL certificate, iTrusChina's SSL business is >> currently only carried out in China, and D&B is only used to query >> applicants' English names. The third chapter of our document is dedicated >> to EV Certificates Registration Agency Disclosure. >> >> 11. In addition, regarding >> https://bugzilla.mozilla.org/show_bug.cgi?id=1712664, we will complete >> the coding of the monitoring system this week, and then start the system >> test next week. We are very grateful to Andrew for raising the question and >> Ryan's suggestions for improvement. These are very helpful to us. >> >> Regards， >> vTrus Team >> 在2021年8月24日星期二 UTC+8 上午6:51:57<Ryan Sleevi> 写道： >> >>> Hi Ben, >>> >>> I'm using the CP/CPS they updated in >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1554846#c33 and >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1554846#c34 >>> >>> There are a few things I wanted to call out and flag for further >>> discussion/consideration: >>> >>> - Although the CCADB Policy does not require CAs make their CP/CPS >>> authoritative in English, it does require that the CA attest the >>> information is not materially different. In their CPS, 1.2, they clearly >>> state that the English version is not authoritative, and that in any >>> conflicts, the Chinese version prevails, but there's no such assurance >>> about equivalence. >>> - Section 3.1.6 states both that "Certificates issued by iTrusChina >>> does not contain any trademarks or other information which may infringe >>> other parties' rights" and that "iTrusChina don't validate trademark >>> right >>> or legal disputes when processing applications", which... seems to be >>> conflicting. >>> - Section 3.2.2.6 has an interesting statement regarding which >>> entities are allowed to obtain wildcards; seemingly preventing them from >>> DV >>> certificates. This seems unfortunate and unnecessary, and while not >>> prohibited, is at least something that stands out as perhaps misaligned >>> in >>> goals / understanding of the purpose of TLS certificates. >>> - Section 3.2.2.6 also includes an interesting clause "If necessary, >>> iTrusChina needs to adopt other independent authentication methods to >>> confirm the ownership of a domain name." It's unclear if that's meant in >>> addition to 3.2.2.4, or in lieu of 3.2.2.4. >>> - Section 3.2.2.8 has a real red flag: "If the tag 'iodef' exists in >>> CAA records, iTrusChina will determine whether to issue the certificate >>> after communicating with the applicant". >>> - It's unclear if they're treating this as permission to issue if >>> the tag exists, which would be a BR violation. >>> - If's unclear if they're redefining the semantics of iodef >>> (which is used for exception reports / violations, not for permission) >>> - Section 6.1.1.1 has a similar red flag "Since China has strict >>> administration requirements on cryptographic products, FIPS 140-2 >>> Standard >>> is not a standard approved and supported by the State Cryptography >>> Administration, FIPS 140-2 Standard is only enforced as a reference, >>> selectively applicable on the premise of passing the evaluation and >>> certification of the State Cryptography Administration and being >>> licensed >>> by national cryptography administration policies." >>> - This reasonably calls into question the safety and security of >>> the CAs' private keys. Similar remarks are found within Section 6.2.1. >>> - Section 6.1.1.2 "If a subscriber submits a PKCS#10 file of a weak >>> algorithm during application, iTrusChina will reject the application and >>> recommend the user to generate a new key pair" - this proof of >>> possession >>> provides no benefit in the context of TLS, and so this is a rather silly >>> check. This has been discussed in the past here on m.d.s.p. >>> - Section 6.3.2 makes it clear that intermediates are generated very >>> long (25 years), while the clear trend of industry has been moving >>> towards >>> shorted lived intermediates, and regularly rotating them, to ensure >>> necessary certificate agility and robustness. >>> - Section 7.1.2 is not that useful (e.g. the EKU for intermediates >>> just says (paraphrased) "We'll put something here after 2019-01-01"). >>> Similarly the notBefore/notAfter remarks. >>> >>> Since they also issue EV certificates, and since it's mentioned in the >>> CP/CPS, I also checked out their disclosure of EV validation sources, in >>> https://www.itrus.com.cn/uploads/soft/210401/2-2104011K954.pdf >>> >>> It's difficult to see this complying with 11.1.3 - rather than >>> disclosing each Incorporating Agency / Registration Agency and associated >>> meta-data, they appear to have broken each field down into possible >>> permutations, leaving it unclear if it's subjected to combinatorial >>> explosion here. It also appears to demonstrate some confusion about how the >>> jurisdiction fields of an EV certificate work, judging by the >>> disclosure, although this could be my own confusion with respect to >>> jurisdictional issues in China. Without prejudice or opinion, it notes that >>> one of the sources is the Unified Social Credit Code Certificate. It also >>> lists Dun and Bradstreet as a source, which is highly questionable with >>> respect to EV certificates and the use of qualified information sources. >>> >>> Andrew previously noted >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1712664 during the public >>> discussion, and that led to an opportunity for the CA to demonstrate its >>> incident detection and response capabilities. In the course of that issue, >>> it was determined that iTrusChina is running in-house developed CA software >>> and that the issue was caused by bugs within that software. Within the bug, >>> we see the unfortunately common struggle for CAs to go beyond simply >>> "respond to the symptom", and instead perform a deeper analysis for the >>> systems and processes that failed, and how to improve or strengthen them. >>> >>> Although some of the issues highlighted above may very well be >>> communication issues, there certainly are unmistakable elements of red >>> flags of concern worth carefully consdering. >>> >>> On Wed, Aug 18, 2021 at 4:03 PM Ben Wilson <[email protected]> wrote: >>> >>>> Thanks to iTrusChina for providing a budget document. I will take a >>>> closer look at it. Meanwhile, do we have any additional comments or >>>> questions from the Mozilla Community? >>>> Ben >>>> >>>> On Wed, Aug 18, 2021 at 1:53 AM yutian zheng <[email protected]> >>>> wrote: >>>> >>>>> Hi Ben, >>>>> >>>>> We added a document on our budget 2018-2021. >>>>> >>>>> >>>>> attachment.cgi (bug1554846.bmoattachments.org) >>>>> <https://bug1554846.bmoattachments.org/attachment.cgi?id=9236778> >>>>> >>>>> Regards, >>>>> vTrus Team >>>>> >>>>> >>>>> 在2021年8月13日星期五 UTC+8 上午2:17:48<[email protected]> 写道： >>>>> >>>>>> All, >>>>>> >>>>>> Here is my summary of iTrusChina's value justification. Please >>>>>> provide any clarifications or additional comments you may have. >>>>>> >>>>>> *Ownership-Management Structure* >>>>>> >>>>>> iTrusChina (iTC) was established in 2000 as the Beijing Tianwei >>>>>> Chengxin Electronic Commerce Service Co., Ltd. ( >>>>>> https://m.itrus.com.cn/about/history/). It was approved by the >>>>>> Chinese Ministry of Industry and Information Technology and State >>>>>> Cryptography Administration. The company is owned by four natural >>>>>> persons >>>>>> and one partnership. Here is what I have been able to glean about the >>>>>> governance structure from iTC's value justification - >>>>>> https://bugzilla.mozilla.org/attachment.cgi?id=9229617: >>>>>> >>>>>> Board of Directors >>>>>> >>>>>> | >>>>>> >>>>>> Security Policy Administration Committee >>>>>> >>>>>> | | | | | | >>>>>> >>>>>> Compliance R&D Authentication Business O&M Product Dept. >>>>>> >>>>>> The Security Policy Administration Committee (SPAC) is the lead >>>>>> department for security and compliance issues, and is responsible for >>>>>> the >>>>>> overall coordination of the iTC's internal resources. It determines >>>>>> priorities for the product and R&D departments and reviews and approves >>>>>> rectification results. The SPAC conducts two-person review of all >>>>>> operations performed by operating team. >>>>>> >>>>>> *User Base* >>>>>> >>>>>> iTC users account for more than half of Chinese market of personal >>>>>> and corporate certificates (480 million). Main customers are Alibaba, >>>>>> Tencent, JD.com, Industrial and Commercial Bank of China, Bank of China, >>>>>> and China Construction Bank. >>>>>> >>>>>> *Finances - Budgeting* >>>>>> >>>>>> iTC originally invested $3.09 million in 2001. It invested 2 million >>>>>> yuan in 2017 for WebTrust audits and compliance transformations of its >>>>>> facilities. Continuous investment in fixed assets and operating expenses >>>>>> is >>>>>> about US$310,000 per year. >>>>>> >>>>>> iTC's compliance budget includes personnel costs, audit costs, >>>>>> infrastructure construction and renovation costs, and is determined >>>>>> annually based on factors such as risk assessment, audit status, and >>>>>> software improvement plans for R&D. >>>>>> >>>>>> With the increase in the number of certificates issued each year, iTC >>>>>> will increase the investment in compliance each year, including the >>>>>> investment budget for the training of personnel familiar with CABF and >>>>>> IETF >>>>>> standards and legal-related training. When faced with compliance issues, >>>>>> if >>>>>> the overall budget set at the beginning of the year is exceeded, it will >>>>>> be >>>>>> approved by the board. >>>>>> >>>>>> Personnel Expense (R&D/O&M/security/verification/customer >>>>>> service/compliance teams) >>>>>> >>>>>> 2018 2019 2020 2021 (5 months) >>>>>> >>>>>> $0.83M $1.07M $1.17M $0.68M >>>>>> >>>>>> R&D team consists of 66 people (incl. 18 for CA system development, 3 >>>>>> for testing, and 6 for WebTrust business and authentication system >>>>>> development). >>>>>> >>>>>> *CA System and System Development* >>>>>> >>>>>> iTC operates a fully self-developed CA software system with a replica >>>>>> test environment for development and testing to ensure compliance. iTC’s >>>>>> CA >>>>>> system is designed based on CA/Browser Forum requirements and the RFCs >>>>>> and >>>>>> conforms to the Specification of cryptograph and related security >>>>>> technology for certificate authentication systems of the National >>>>>> Cryptographic Standards Committee of China (GB/T 25056-2018 Information >>>>>> Security Technology) and "GM/T 0037-2014 Certificate authority system >>>>>> test >>>>>> specification". >>>>>> >>>>>> iTC designs product and system changes in accordance with privacy, >>>>>> security, and compliance requirements. iTC uses an agile (scrum) >>>>>> development process. Each iteration cycle is generally 1-4 weeks. >>>>>> >>>>>> *Compliance Team and Personnel* >>>>>> >>>>>> iTC’s Compliance team follows domestic and foreign compliance >>>>>> standards and specifications, and regularly updates internal >>>>>> documentation. >>>>>> There are two bilingual persons who follow changes in the CA industry >>>>>> requirements on a daily basis. The compliance team summarizes Bugzilla >>>>>> CA >>>>>> incidents quarterly and circulates an industry dynamic tracking report >>>>>> to >>>>>> relevant personnel every month. iTC conducts self-inspections and trains >>>>>> personnel to avoid similar errors. Going forward, iTC will train more >>>>>> compliance personnel and conduct more regular training for team members >>>>>> of >>>>>> authentication, R&D, and business departments. >>>>>> >>>>>> iTC has 20 years of risk compliance experience and personnel with >>>>>> comparable management experience and appears to have a sufficient number >>>>>> of >>>>>> key personnel familiar with CABF and IETF standards. >>>>>> >>>>>> *Authentication Team* >>>>>> >>>>>> This team conducts monthly training on authentication procedures and >>>>>> industry standards, and conducts compliance audits on internal >>>>>> documents, >>>>>> certificate issuance and revocation records on a monthly basis. >>>>>> >>>>>> *R&D Team* >>>>>> >>>>>> This team integrates lint tests in the CA system for certificate >>>>>> issuance compliance inspection. R&D team inspects CA system at design >>>>>> level >>>>>> and performs unit testing and examines results of other testing >>>>>> processes. >>>>>> >>>>>> *Operation Team* >>>>>> >>>>>> This team operates and monitors the availability of all CA-related >>>>>> services. >>>>>> >>>>>> *Monitoring and Alerting* >>>>>> >>>>>> iTC has continuous automatic monitoring to detect and alert on any >>>>>> changes to the CA/RA system, and it responds to and solves the problem >>>>>> within 24 hours after receiving the alert. iTC uses three kinds of lint >>>>>> tests: zlint, certlint, x509lint. iTC conducts automatic inspection of >>>>>> CAA, >>>>>> blacklist, and high-risk list before the issuance of the certificate. >>>>>> The >>>>>> fortress machine records operations, and operation records are reviewed >>>>>> on >>>>>> a monthly basis. >>>>>> >>>>>> *Logs and backups* >>>>>> >>>>>> iTC logs/backs up: >>>>>> >>>>>> 1. Any CA operation and maintenance process in a bastion machine log. >>>>>> The log server backs up and archives every day and saves 2 backups, 1 >>>>>> remote backup, and 1 different device backup. >>>>>> >>>>>> 2. All business logs of CA, RA, etc. are backed up to the log server >>>>>> in real time. >>>>>> >>>>>> 3. regular CRL generation >>>>>> >>>>>> *Compliance Incidents* >>>>>> >>>>>> When a compliance incident occurs, the compliance team coordinates >>>>>> with the relevant business personnel to quickly initiate the >>>>>> investigation >>>>>> process within 24 hours and submit a problem report to Mozilla. The >>>>>> certificate that needs to be revoked after the investigation will be >>>>>> revoked within 24 hours after the incident. >>>>>> >>>>>> *Vulnerability Assessments* >>>>>> >>>>>> iTC conducts a vulnerability scan of the CA system every 3 months and >>>>>> a penetration test every year. Based on audit results, iTC also conducts >>>>>> vulnerability assessments of the system, physical site, operation >>>>>> management, and takes measures to reduce operational risks. >>>>>> >>>>>> *Risk Assessment* >>>>>> >>>>>> iTC's annual risk assessment is carried out by the operation and >>>>>> maintenance, product, development, and compliance teams. All internal >>>>>> and >>>>>> external audits include risk assessments. iTC's risk control refers to >>>>>> BR >>>>>> Chapter 5, including physical control, program control, personnel >>>>>> control, >>>>>> audit log program and other dimensions, and meets the WT audit >>>>>> requirements. iTC also follows the Chinese Ministry of Industry and >>>>>> Information Technology and the State Cryptography Administration’s >>>>>> formulated risk assessment and inspection standards. >>>>>> >>>>>> Risk Control Team rates the risks, evaluate the impact on the >>>>>> business, and after the approval of the Security Policy Administration >>>>>> Committee, decides whether to undertake the risk and formulates a >>>>>> corresponding commitment plan. >>>>>> >>>>>> *Audits* >>>>>> >>>>>> The internal control team conducts WebTrust internal audits on a >>>>>> quarterly basis. External audits include: >>>>>> >>>>>> · WebTrust audit by pwc >>>>>> >>>>>> · ISO9001 >>>>>> >>>>>> · ISO27001 >>>>>> >>>>>> After reviewing iTrusChina's value justification, I would like to >>>>>> examine the compliance aspects of its budget a little closer, and I am >>>>>> wondering whether iTrustChina can provide something similar (or better) >>>>>> to >>>>>> that provided by TunTrust? See >>>>>> https://bugzilla.mozilla.org/attachment.cgi?id=9228562 >>>>>> >>>>>> Sincerely yours, >>>>>> >>>>>> Ben >>>>>> >>>>>> On Tue, Aug 10, 2021 at 9:20 AM Ben Wilson <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> All, >>>>>>> Are there any additional comments? >>>>>>> Thanks, >>>>>>> Ben >>>>>>> >>>>>>> On Sun, Jul 4, 2021 at 7:11 PM yutian zheng <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi All， >>>>>>>> >>>>>>>> iTrusChina submitted a document to answer a series of questions in >>>>>>>> Quantifying Value： >>>>>>>> >>>>>>>> attachment.cgi (bug1554846.bmoattachments.org) >>>>>>>> <https://bug1554846.bmoattachments.org/attachment.cgi?id=9229617> >>>>>>>> >>>>>>>> Regards, >>>>>>>> vTrus team >>>>>>>> >>>>>>>> 在2021年4月21日星期三 UTC+8 上午2:19:41<[email protected]> 写道： >>>>>>>> >>>>>>>>> Hi Ryan, >>>>>>>>> Kathleen and I discussed iTrusChina's and TunTrust's root >>>>>>>>> inclusion applications this morning and agreed that we should extend >>>>>>>>> the >>>>>>>>> public discussion period and leave them open for discussion beyond >>>>>>>>> April >>>>>>>>> 30th. Meanwhile, I will work on follow-up questions for them >>>>>>>>> regarding >>>>>>>>> their added value to users vs. added risk. >>>>>>>>> Thanks, >>>>>>>>> Ben >>>>>>>>> >>>>>>>>> On Wed, Apr 7, 2021 at 1:52 PM Ryan Sleevi <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Thanks for clarifying. >>>>>>>>>> >>>>>>>>>> In a personal capacity, while I can understand that Mozilla may >>>>>>>>>> have reached a level of confidence that they can handle processing >>>>>>>>>> these >>>>>>>>>> requests in parallel, I don't believe it's reasonable to expect the >>>>>>>>>> same of >>>>>>>>>> the community, since these public discussions may be the first time >>>>>>>>>> a >>>>>>>>>> number of members of the community are examining CAs in depth. This >>>>>>>>>> practically impacts both the quality and depth of review, as it >>>>>>>>>> effectively >>>>>>>>>> requires the community make larger and larger time commitments to >>>>>>>>>> handle >>>>>>>>>> all such reviews, or reduces the amount of time and effort focused >>>>>>>>>> on an >>>>>>>>>> individual CA. >>>>>>>>>> >>>>>>>>>> Wearing a Google hat, Honestly, I don't think we'll be able to >>>>>>>>>> offer feedback here for both CAs in a parallel (time-gated) review. >>>>>>>>>> We'll >>>>>>>>>> examine the available data to help prioritize against our own stated >>>>>>>>>> policies, but I think realistically, we may request that the CA that >>>>>>>>>> does >>>>>>>>>> not align most with the priorities undergoes an additional public >>>>>>>>>> discussion when we're ready to proceed. We see significant risk to >>>>>>>>>> our >>>>>>>>>> users from trying to include CAs too quickly, and so want to make >>>>>>>>>> sure as >>>>>>>>>> much as possible that all CAs receive the same level of attention >>>>>>>>>> and >>>>>>>>>> thoroughness by dedicating specific time to focus on just a single >>>>>>>>>> CA. >>>>>>>>>> >>>>>>>>>> It's an entirely reasonable goal, but the effect of running these >>>>>>>>>> in parallel does not mean both CAs undergo three weeks of review; it >>>>>>>>>> means >>>>>>>>>> both CAs undergo a week and a half, or less, since these processes >>>>>>>>>> do not >>>>>>>>>> linearly scale, nor should they. >>>>>>>>>> >>>>>>>>>> On Wed, Apr 7, 2021 at 3:39 PM Ben Wilson <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Ryan, >>>>>>>>>>> Yes, I think it is an intentional effort to process multiple >>>>>>>>>>> applications simultaneously. As I was moving CA applicants through >>>>>>>>>>> the >>>>>>>>>>> queue these two just seemed to both be ready at about the same >>>>>>>>>>> time. It was >>>>>>>>>>> more efficient for me to handle these two at once. Note that we >>>>>>>>>>> also have >>>>>>>>>>> Asseco/Certum with public discussion closing next week (4/14/2021). >>>>>>>>>>> I'll >>>>>>>>>>> repost that to this list right now so that there is continuity on >>>>>>>>>>> this >>>>>>>>>>> list. Let's see how this goes. If it presents a problem, then we >>>>>>>>>>> can >>>>>>>>>>> adjust. >>>>>>>>>>> Ben >>>>>>>>>>> >>>>>>>>>>> On Wed, Apr 7, 2021 at 1:01 PM Ryan Sleevi <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Apr 7, 2021 at 2:49 PM Ben Wilson <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> This is to announce the beginning of the public discussion >>>>>>>>>>>>> phase of the Mozilla root CA inclusion process for iTrusChina’s >>>>>>>>>>>>> vTrus Root >>>>>>>>>>>>> CA and its vTrus ECC Root CA. See >>>>>>>>>>>>> https://wiki.mozilla.org/CA/Application_Process#Process_Overview, >>>>>>>>>>>>> (Steps 4 through 9). >>>>>>>>>>>>> >>>>>>>>>>>>> These Root CAs are operated by iTrusChina Co., Ltd. >>>>>>>>>>>>> >>>>>>>>>>>>> This current CA inclusion application has been tracked in the >>>>>>>>>>>>> CCADB and in Bugzilla– >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000431 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1554846 >>>>>>>>>>>>> >>>>>>>>>>>>> These new root CA certificates are valid from 2018 to 2043, >>>>>>>>>>>>> and they are proposed for inclusion with the websites bit and EV >>>>>>>>>>>>> enabled. >>>>>>>>>>>>> >>>>>>>>>>>>> Mozilla is considering approving iTrusChina’s request. This >>>>>>>>>>>>> email begins the 3-week comment period, after which, if no >>>>>>>>>>>>> concerns are >>>>>>>>>>>>> raised, we will close the discussion and the request may proceed >>>>>>>>>>>>> to the >>>>>>>>>>>>> approval phase (Step 10). >>>>>>>>>>>>> >>>>>>>>>>>>> *Root Certificate Information:* >>>>>>>>>>>>> >>>>>>>>>>>>> *vTrus Root CA *(RSA) >>>>>>>>>>>>> >>>>>>>>>>>>> crt.sh - >>>>>>>>>>>>> >>>>>>>>>>>>> https://crt.sh/?q=8A71DE6559336F426C26E53880D00D88A18DA4C6A91F0DCB6194E206C5C96387 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Download – >>>>>>>>>>>>> >>>>>>>>>>>>> http://wtca-cafiles.itrus.com.cn/ca/vTrusRootCA.cer >>>>>>>>>>>>> >>>>>>>>>>>>> *vTrus ECC Root CA *(ECC) >>>>>>>>>>>>> >>>>>>>>>>>>> crt.sh – >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://crt.sh/?q=30FBBA2C32238E2A98547AF97931E550428B9B3F1C8EEB6633DCFA86C5B27DD3 >>>>>>>>>>>>> >>>>>>>>>>>>> http://wtca-cafiles.itrus.com.cn/ca/vTrusECCRootCA.cer >>>>>>>>>>>>> >>>>>>>>>>>>> *CP/CPS:* >>>>>>>>>>>>> >>>>>>>>>>>>> iTrusChina’s current CPS is v.1.4.4 / Dec. 19, 2020 >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.itrus.com.cn/uploads/soft/201223/2-201223110436.pdf >>>>>>>>>>>>> >>>>>>>>>>>>> Repository location: >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.itrus.com.cn/repository >>>>>>>>>>>>> >>>>>>>>>>>>> *iTrusChina's 2021 BR Self-Assessment* (PDF) is located here: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://bugzilla.mozilla.org/attachment.cgi?id=9209938 >>>>>>>>>>>>> >>>>>>>>>>>>> *Audits:* >>>>>>>>>>>>> >>>>>>>>>>>>> iTrusChina’s WebTrust auditor is PricewaterhouseCoopers Zhong >>>>>>>>>>>>> Tian LLP, and the most recent audit reports are dated March 24, >>>>>>>>>>>>> 2021. These >>>>>>>>>>>>> audit reports may be downloaded by clicking on the WebTrust seals >>>>>>>>>>>>> at the >>>>>>>>>>>>> bottom of iTrusChina’s repository page >>>>>>>>>>>>> <https://www.itrus.com.cn/repository/>. >>>>>>>>>>>>> >>>>>>>>>>>>> *Incidents: * >>>>>>>>>>>>> >>>>>>>>>>>>> I was not able to find any incidents involving iTrusChina, no >>>>>>>>>>>>> misissuances were found under the iTrusChina root CAs, and the >>>>>>>>>>>>> issuing CAs >>>>>>>>>>>>> appeared to be properly formatted. >>>>>>>>>>>>> >>>>>>>>>>>>> Thus, this email begins a three-week public discussion period, >>>>>>>>>>>>> which I’m scheduling to close on or about 30-April-2021. >>>>>>>>>>>>> >>>>>>>>>>>>> A representative of iTrusChina must promptly respond directly >>>>>>>>>>>>> in the discussion thread to all questions that are posted. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Ben, >>>>>>>>>>>> >>>>>>>>>>>> I'm not used to parallel discussions for adding CAs. May I >>>>>>>>>>>> request that you put this discussion on hold until the conclusion >>>>>>>>>>>> of >>>>>>>>>>>> TunTrust? Or is this an intentional attempt to parallelize more, >>>>>>>>>>>> despite >>>>>>>>>>>> the limited resources? >>>>>>>>>>>> >>>>>>>>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "[email protected]" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaasiS84aMHBw-qbsTDxko%3DahU-DjrhV84-v_HGpt1pchw%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaasiS84aMHBw-qbsTDxko%3DahU-DjrhV84-v_HGpt1pchw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/cf2c4864-0caa-4215-bc60-fe7aa2a883f5n%40mozilla.org.
