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/CAErg%3DHEV50mCD_6QtV7%2BLYTqZaqC2_kLDWhsP7Xve4yv5eH3zQ%40mail.gmail.com.
