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/CA%2B1gtaaMoTQ9KHtnfXXPoAoyt3votS5E6dJYVn838wjTWi4Vrw%40mail.gmail.com.
