1717044 - SECOM: CA Certificates Missing from Audit Reports

CA certificates that were audited as S/MIME CAs but not included in audit report (proposed by SECOM to be included in its next WebTrust audit in early September 2021):

SECOM Passport for Member PUB CA4

https://crt.sh/?q=0940451DFECB675B5204C8AE07189D4E4E90957CFD2BAFDCFF36DB20C279E91A

Other CA Certificates proposed by SECOM to be included in its next WebTrust audit in early September 2021:

NII Open Domain S/MIME CA

https://crt.sh/?q=D8DF7E1183D6DEF561D84D56E621A6F36A065DC717F3959BB3BAFC824556D48C

Certification Authority

https://crt.sh/?q=F937385B88F659840909407B80E4EB25F25C5B4AEAEF9EE279880EE0BF05EDEF

SECOM Passport for Member PUB CA10

https://crt.sh/?q=EE0204E34C0B4D45CC839CF3B9015CEEC946A3661CF2BF10972339426C60E809

Cross root certificate proposed by SECOM to be included in its next WebTrust audit in early September 2021:

Security Communication RootCA2

https://crt.sh/?q=C415CEBFA3FC2EF3C74092B84265BAD64C3FC9994C91177965667D7ABEE90588

Ben Wilson

Reporter

Updated

•

3 years ago

Assignee: bwilson → h-kamo

Status: NEW → ASSIGNED

Whiteboard: [ca-compliance]

Hisashi Kamo

Assignee

Comment 1

•

3 years ago

Ben-san,

The incident report is being created for this matter.
We are now planning to post it next week.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Hisashi Kamo

Assignee

Comment 2

•

3 years ago

Ben-san,

Please let us provide our incident report.

1.How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in the MDSP mailing list, a Bugzilla bug, or internal self-audit), and the time and date.*

Our CA became aware of the ALV error displayed in CCADB on March 17, 2021. Then we have begun planning the revocation and audit of intermediate CA certificates. SECOM has been planning and proceeding with revocation and audit of intermediate CA certificates in consultation with Ben-san of Mozilla.

2.A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.*

Time(UTC) - YYYY/MM/DD HH:MM	Action
2021/03/17	SECOM has started exchanging emails with Ben-san. We have started planning the revocation and audit of intermediate CA certificates.
2021/06/18	The bugzilla has been introduced.

3.Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.

JPRS Organization Validation Authority - G2
Issuance has already stopped.
JPRS has not issued a serverAuth certificate since August 1, 2019.

JPRS Domain Validation Authority - G2
Issuance has already stopped.
JPRS has not issued a serverAuth certificate since August 1, 2019.

Fuji Xerox Xnet CA – C
Issuance has not stopped. Only the clientAuth certificates are issued.

FUJIFILM Fnet CA – C
Issuance has not stopped. Only the clientAuth certificates are issued.

NII Open Domain CA - G4
Issuance has already stopped.

SECOM Passport for Member PUB CA7
Issuance has not stopped. Only the clientAuth or Document Signing certificates are issued.

SECOM TimeStamping CA2
Issuance has already stopped.

SMBC Certificate Authority CA2
Issuance has not stopped. Only the Document Signing certificates are issued.

SECOM Passport for Member PUB CA3
Issuance has not stopped. Only the clientAuth certificates are issued.

SECOM Passport for Member PUB CA2
Issuance has not stopped. Only the clientAuth certificates are issued.

SECOM Passport for Member PUB CA1
Issuance has not stopped. Only the clientAuth certificates are issued.

SECOM TimeStamping CA1
Issuance has already stopped.

SECOM Passport for Member PUB CA4
Issuance has not stopped. Only the clientAuth or emailProtection certificates are issued.

NII Open Domain S/MIME CA
Issuance has already stopped.

Certification Authority
Issuance has already stopped.

SECOM Passport for Member PUB CA10
Issuance has already stopped.

Security Communication RootCA2
Not related to issuance.

4.In a case involving certificates, a summary of the problematic certificates. For each problem: the number of certificates, and the date the first and last certificates with that problem were issued. In other incidents that do not involve enumerating the affected certificates (e.g. OCSP failures, audit findings, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help us measure the severity of each problem.

CA Name
date of issue(YYYY/MM/DD)

JPRS Organization Validation Authority - G2
2018/03/09

JPRS Domain Validation Authority - G2
2018/03/09

Fuji Xerox Xnet CA – C
2016/09/08

FUJIFILM Fnet CA – C
2016/09/08

NII Open Domain CA - G4
2014/12/25

SECOM Passport for Member PUB CA7
2017/03/24

SECOM TimeStamping CA2
2016/03/29

SMBC Certificate Authority CA2
2015/11/25

SECOM Passport for Member PUB CA3
2013/08/20

SECOM Passport for Member PUB CA2
2013/08/20

SECOM Passport for Member PUB CA1
2013/04/02

SECOM TimeStamping CA1
2011/06/28

SECOM Passport for Member PUB CA4
2013/11/20

NII Open Domain S/MIME CA
2016/12/21

Certification Authority
2017/03/24

SECOM Passport for Member PUB CA10
2018/08/10

Security Communication RootCA2
2015/03/24

5.In a case involving certificates, the complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.

JPRS Organization Validation Authority - G2
https://crt.sh/?q=DB2F0194EDCB78CBA9D1BAF4C3DBA8D56837D97B20233D617DD50B713BD313C8

JPRS Domain Validation Authority - G2
https://crt.sh/?q=C3F908A79CDD80C13025CB5323B111AC79099EB80122F999DBB22F1AA1662DDC

Fuji Xerox Xnet CA – C
https://crt.sh/?q=C23D01B8E9585613E260EC8EA485BFF8F5987298D5FC02C07064C5446223F9C7

FUJIFILM Fnet CA – C
https://crt.sh/?q=B6AB8DB110B5F6D35FD9A6B5FF7071D8426658126C425629BC7CDA31354F4CD0

NII Open Domain CA - G4
https://crt.sh/?q=6540CFCF743E84AB2D67866F2F13A53FE7AF2E8977A5C1681FE07A1869620DD1

SECOM Passport for Member PUB CA7
https://crt.sh/?q=9BDFB383F96B0A4B54B5D6C1C4CC1EA20582B9BEC2BBC633904CDE87EEAEDBD1

SECOM TimeStamping CA2
https://crt.sh/?q=225113CEDA68FBAB5E628E0214A15A651C47AA7EE7BBF476099B6E142EECC8EC

SMBC Certificate Authority CA2
https://crt.sh/?q=0027C852E6A0A74EAD844B5FAC2434CC24966853C84CE63212468881B616665D

SECOM Passport for Member PUB CA3
https://crt.sh/?q=4554C210C751AC8211B6E2046B79F68AFFC8082274AEA489038660620C4182DD

SECOM Passport for Member PUB CA2
https://crt.sh/?q=80E13A2E800847519E023D64F4F9CF20B43CADD1D46BA4811D26ACE31E295FBB

SECOM Passport for Member PUB CA1
https://crt.sh/?q=13EA1104449A11A1F81CB97D098C482EC12A2B609EB53C7E6155ED084AA8B093

SECOM TimeStamping CA1
https://crt.sh/?q=1D709B2884EC093E5D77A504971E887163044734F6DA70C923A4F3FF8D4E5B49

SECOM Passport for Member PUB CA4
https://crt.sh/?q=0940451DFECB675B5204C8AE07189D4E4E90957CFD2BAFDCFF36DB20C279E91A

NII Open Domain S/MIME CA
https://crt.sh/?q=D8DF7E1183D6DEF561D84D56E621A6F36A065DC717F3959BB3BAFC824556D48C

Certification Authority
https://crt.sh/?q=F937385B88F659840909407B80E4EB25F25C5B4AEAEF9EE279880EE0BF05EDEF

SECOM Passport for Member PUB CA10
https://crt.sh/?q=EE0204E34C0B4D45CC839CF3B9015CEEC946A3661CF2BF10972339426C60E809

Security Communication RootCA2
https://crt.sh/?q=C415CEBFA3FC2EF3C74092B84265BAD64C3FC9994C91177965667D7ABEE90588

6.Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

In the process of deciding which CAs are subject to external audits each year, we have confirmed the serverAuth certificates as the status of issuance over the past year.
At the moment, we understand that all intermediate CA certificates should be applied with the cradle-to-grave audit requirement, but last year our understanding was not good enough.
For the external audit, SECOM extracted the intermediate CA certificates to be the target, submitted them to the audit firm, and they were audited.

The serverAuth certificates were after shifting to be able to issue from another CA.
They were not included in the 2020 audit report because we had not issued serverAuth certificates in the last year.
JPRS Organization Validation Authority - G2
JPRS Domain Validation Authority - G2
We haven't issued serverAuth certificates in the last year, so we didn't include them in our audit report.
No valid serverAuth certificates exist.
Currently, they are CAs that issue clientAuth or Document Signing certificates.
Fuji Xerox Xnet CA – C
FUJIFILM Fnet CA – C
NII Open Domain CA - G4
SECOM Passport for Member PUB CA7
SECOM TimeStamping CA2
SMBC Certificate Authority CA2
SECOM Passport for Member PUB CA3
SECOM Passport for Member PUB CA2
SECOM Passport for Member PUB CA1
SECOM TimeStamping CA1
We had an external audit of the CA, but did not include this intermediate CA certificate in our audit report.
SECOM Passport for Member PUB CA4
We had issued emailProtection certificates in the past, but did not include these intermediate CA certificates in our audit report.
Valid emailProtection certificates exist.
NII Open Domain S/MIME CA
Certification Authority
SECOM Passport for Member PUB CA10
We could not realize the need to make the Cross Root Certificate an external audit target.
Security Communication RootCA2

7.List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.

Currently, the dedicated team established in May 2021 is checking the WebTrust audit target.
We have confirmed the requirements of the Mozilla Root Store Policy and are ready to conduct all external audits.
The CCADB ALV error should be resolved by the end of September 2021, so we believe that audit omissions will not occur in the future.
Please refer about the dedicated team as below:
https://bugzilla.mozilla.org/show_bug.cgi?id=1705480#c9

Timeline of remedial actions
Date - YYYY/MM/DD | Action
------------ | -------------
2021/09/01 | Intermediate CA certificate revocation scheduled to be completed
2021/09/03 | WebTrust audit report scheduled to be completed

・Intermediate CA Certificates to be revoked by September 1, 2021.
JPRS Organization Validation Authority - G2
JPRS Domain Validation Authority - G2

・Intermediate CA Certificates to be revoked by August 31, 2021.
Intermediate CA certificates included in its next WebTrust audit in early September 2021
Fuji Xerox Xnet CA – C
FUJIFILM Fnet CA – C
NII Open Domain CA - G4
SECOM Passport for Member PUB CA7
SECOM TimeStamping CA2
SMBC Certificate Authority CA2
SECOM Passport for Member PUB CA3
SECOM Passport for Member PUB CA2
SECOM Passport for Member PUB CA1
SECOM TimeStamping CA1
NII Open Domain S/MIME CA
Certification Authority
SECOM Passport for Member PUB CA10

・CA certificates that were audited as S/MIME CAs but not included in audit report (included in its next WebTrust audit in early September 2021):
SECOM Passport for Member PUB CA4

・Cross root certificate included in its next WebTrust audit in early September 2021:
Security Communication RootCA2

Thank you for your consideration.

Best regards,
Hisashi Kamo

Ben Wilson

Reporter

Updated

•

3 years ago

Flags: needinfo?(bwilson)

Ryan Sleevi

Comment 3

•

3 years ago

I'm not sure how SECOM sees this plan as meeting (long-standing) expectations of root programs, or the BRs (Section 8.1 and Section 8.6)

It appears SECOM has a number of CAs which are not audited. Including them in the next audit does nothing to address the security concerns that the public has no assurances for any of the historic practices (i.e. before the audit period). Unless these CAs were issued since the previous audit, the expectation is that every one of them needs to be revoked, not included in subsequent audits.

I'm concerned, because SECOM does not appear to have reviewed past CA incidents or communications regarding unaudited sub-CAs, in which multiple other CAs have been expected to, and have successfully, revoked these certificates. These appear to be TLS-capable CAs, and so it's unacceptable to have such CAs unaudited, and it's entirely unacceptable to simply claim "We haven't used these for TLS". That's something that has been addressed, at this point, for years.

SECOM also appears to be delaying revocation, which is a separate incident, but it seems there's a more fundamental misunderstanding about what it means to be a trusted CA, and until that's resolved, I'm not sure a separate incident report for delayed revocation would be any more productive.

SECOM has also been aware of this issue since March, it was only disclosed by Ben filing this issue in June, and SECOM is proposing to not take action until September. That's not encouraging behaviour from a CA.

Flags: needinfo?(h-kamo)

Ben Wilson

Reporter

Updated

•

3 years ago

Flags: needinfo?(bwilson)

Whiteboard: [ca-compliance] → [ca-compliance] Next update 2021-07-15

Ryan Sleevi

Comment 4

•

3 years ago

Ben: I’m still hoping SECOM can explain the answer to how they see this complying with the BRs (Comment #3), as this appears to be clear violation of the BRs and every root programs requirements, without any meaningful or substantive plan for remediation.

Is there additional information Mozilla has leading to the 07-15 next update, when there are outstanding questions? In the event it wasn’t clear:

How does the current situation comply with the BRs?
How does the proposed plan comply with the BRs?
Has SECOM reviewed the expectations of all CAs by root programs?
Has SECOM reviewed past CA incidents around similar omissions?
Why did SECOM fail to disclose anything about the ALV failures?

Ben Wilson

Reporter

Comment 5

•

3 years ago

•

Edited

Ryan,
You asked, "Is there additional information Mozilla has leading to the 07-15 next update, when there are outstanding questions?"
I was merely changing all SECOM bugs to a next update of 7-15. I am in the process of figuring out the situation with SECOM, including trying to understand why there is this misunderstanding/miscommunication leading them to omit these subordinate CA certificates in audit reports. There was no intention to skip over outstanding questions.
Also, I recommend that SECOM take this extra time to write a more thorough response, which can be posted next week, rather than rush with an attempt to respond this week.
Thanks,
Ben

Hisashi Kamo

Assignee

Comment 6

•

3 years ago

Thank you, Ben-san, Ryan-san.
We are now providing the answers.

Best regards,
Hisashi Kamo

Flags: needinfo?(h-kamo)

Hisashi Kamo

Assignee

Comment 7

•

3 years ago

Sorry, please let us retype.

<Not> providing the answers.
We are now preparing the answers.

Best regards,
Hisashi Kamo

Julien Cristau [:jcristau] (back April 22)

Comment 8

•

3 years ago

Restoring the needinfo for comment 3.

Flags: needinfo?(h-kamo)

Hisashi Kamo

Assignee

Comment 9

•

3 years ago

Ryan-san and Ben-san,

Please let us provide you with the current status of our response to the ALV errors for intermediate CA certificates in the CCADB. First note that all CA certificates mentioned in this bug will be included in our WebTrust audit for the period ending June 6, 2021. The WebTrust audit report will be made available in early September 2021. We are also taking action on the CA certificates as indicated below.

For Reference, here are the 2020 WebTrust Audit Reports:

-2020 WTCA

https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=241990

-2020 WTBR

https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=241992

-2020 WTEV

https://www.cpacanada.ca/generichandlers/CPACHandler.ashx?attachmentid=241994

CA Certificates to be Revoked and Keys Destroyed

The key material for the following CAs has always been controlled by SECOM and the infrastructure used for key management has been continuously audited with annual WebTrust audits. However, the following CA certificates will be revoked by September 1, 2021. After revocation, we will proceed with key destruction.

JPRS Organization Validation Authority - G2
https://crt.sh/?q=DB2F0194EDCB78CBA9D1BAF4C3DBA8D56837D97B20233D617DD50B713BD313C8

JPRS Domain Validation Authority - G2
https://crt.sh/?q=C3F908A79CDD80C13025CB5323B111AC79099EB80122F999DBB22F1AA1662DDC

Certification Authority
https://crt.sh/?q=F937385B88F659840909407B80E4EB25F25C5B4AEAEF9EE279880EE0BF05EDEF

SECOM Passport for Member PUB CA10
https://crt.sh/?q=EE0204E34C0B4D45CC839CF3B9015CEEC946A3661CF2BF10972339426C60E809

CA Certificates to be Revoked and Re-issued

Not only has the key material for these CAs always been controlled by SECOM, and the infrastructure used for key management has been continuously audited with annual WebTrust audits, but also these CAs have only issued end entity certificates with the following indicated EKUs. The CA certificates will be revoked on or before August 31, 2021, and we will issue new CA certificates for the same public key. These new CA certificates will all have EKU constraints (not the serverAuth EKU) and cannot be used to issue server certificates. (We are not backdating “not before”, so that “not before” will be in 2021. These new CA certificates will be included in the next WebTrust audit delivered in 2022.)

Fuji Xerox Xnet CA - C (clientAuth EKU)
https://crt.sh/?q=C23D01B8E9585613E260EC8EA485BFF8F5987298D5FC02C07064C5446223F9C7

FUJIFILM Fnet CA - C (clientAuth EKU)
https://crt.sh/?q=B6AB8DB110B5F6D35FD9A6B5FF7071D8426658126C425629BC7CDA31354F4CD0

NII Open Domain CA - G4 (clientAuth EKU)
https://crt.sh/?q=6540CFCF743E84AB2D67866F2F13A53FE7AF2E8977A5C1681FE07A1869620DD1

SECOM Passport for Member PUB CA7 (clientAuth and Document Signing EKUs)
https://crt.sh/?q=9BDFB383F96B0A4B54B5D6C1C4CC1EA20582B9BEC2BBC633904CDE87EEAEDBD1

SECOM TimeStamping CA2 (timestamping EKU)
https://crt.sh/?q=225113CEDA68FBAB5E628E0214A15A651C47AA7EE7BBF476099B6E142EECC8EC

SMBC Certificate Authority CA2 (Document Signing EKU)
https://crt.sh/?q=0027C852E6A0A74EAD844B5FAC2434CC24966853C84CE63212468881B616665D

SECOM Passport for Member PUB CA3 (clientAuth EKU)
https://crt.sh/?q=4554C210C751AC8211B6E2046B79F68AFFC8082274AEA489038660620C4182DD

SECOM Passport for Member PUB CA2 (clientAuth EKU)
https://crt.sh/?q=80E13A2E800847519E023D64F4F9CF20B43CADD1D46BA4811D26ACE31E295FBB

SECOM Passport for Member PUB CA1 (clientAuth EKU)
https://crt.sh/?q=13EA1104449A11A1F81CB97D098C482EC12A2B609EB53C7E6155ED084AA8B093

SECOM TimeStamping CA1 (timestamping EKU)
https://crt.sh/?q=1D709B2884EC093E5D77A504971E887163044734F6DA70C923A4F3FF8D4E5B49

NII Open Domain S/MIME CA (secure email and clientAuth EKUs)
https://crt.sh/?q=D8DF7E1183D6DEF561D84D56E621A6F36A065DC717F3959BB3BAFC824556D48C

CAs are already included in last year's audit and will not be revoked

SECOM Passport for Member PUB CA4 (CA public key pair has continuously been audited - see SKI of PUB CA4 on page 30 of 2020 WebTrust for CAs audit report and on page 37 of the 2020 WebTrust Baseline Requirements audit report)
https://crt.sh/?q=0940451DFECB675B5204C8AE07189D4E4E90957CFD2BAFDCFF36DB20C279E91A

Security Communication RootCA2 (the root CA public key pair has continuously been audited - see SKI of RootCA2 on page 29 of 2020 WebTrust for CAs audit report and on page 33 of the 2020 WebTrust Baseline Requirements audit report)
https://crt.sh/?q=C415CEBFA3FC2EF3C74092B84265BAD64C3FC9994C91177965667D7ABEE90588

How does the current situation comply with the BRs?

As explained below, there has been miscommunication and misunderstanding with SECOM and its auditor regarding the requirements for including non-SSL CAs. Before July 2021, we didn’t recognize that our audit report failed to meet newer requirements. However, after checking on the cases of other companies and comments of Ryan-san, we figured out the seriousness of the problem. Now we realize that intermediate CA certificates without EKUs needed to be audited, as in the current situation.

How does the proposed plan comply with the BRs?

We believe our proposal to revoke intermediate CA certificates without EKUs and replace them with CA certificates with constraining EKUs complies with the BRs.

The CA "SECOM Passport for Member PUB CA4" was included in the WebTrust audit, but the CA certificate pointed out was missing from the audit report. In other words, only a reissued CA certificate using the same key was described in the audit report, and the other was omitted. However, the same SKI is listed in the audit report, as indicated above, so the CA has been audited and, after thorough internal discussion, will not be revoked.

Similarly, the Root CA "Security Communication Root CA1" and "Security Communication Root CA2" listed in the cross-root certificate were evaluated in the previous annual WebTrust audit, and included in the scope of the audit based on the contract with the auditing firm. In other words, the cross-root certificate with "Security Communication Root CA1" for Issuer and "Security Communication Root CA2" for Subject are both Root CAs and were included in the audit report. For those reasons, after thorough internal discussion, we have decided not to revoke it.

One of the reasons why these CA certificates were not listed in the 2020 audit reports was miscommunication. The audit contract was a "CA Subject unit" contract. However, there was a misuse in the Japanese expressions indicating "CA having the same subject", "CA linked to a single Private key", and "each CA certificate", which caused miscommunication. (In Japan's certificate authority business, it is rather common to communicate using the words corresponding to "Certificate Authority" without clearly distinguishing these words.) As a result, we happened to omit the SHA256 Fingerprint of the cross-root certificate, which should have been included, in the audit report.

Regarding this incident, we confirmed the facts and related matters with the auditing firm. In this year's WebTrust annual audit, we confirmed with them that they will perform the same full evaluation as they did last year and that all CA certificates should be listed without any omission in the relevant parts of the audit report.

Again, in Japan, there are rather many cases where "Certificate Authority" and "Certificate for Certificate Authority" are confused and used, not only by the general public but also by those involved in certification business. One of the causes of the omission from the audit report through the exchange of information with the audit firm, is this confusion, we figured.

From now on, we are studying key management guidelines in Japan in order to disseminate them in order to deepen the correct understanding of certificate authorities among auditors, Japanese quasi-government agency officials, and others. We will begin to emphasize and clearly explain the differences between “Certificate Authority”, “Certificate”, “key material”, “metadata”, “binding of private key with metadata”, etc. to these groups so that they don’t get confused anymore.

Has SECOM reviewed the expectations of all CAs by root programs?

We have reviewed the contents of BRs and Mozilla Root Store Policy thoroughly again.
We will review the program requirements for Apple, Microsoft, and Google, too.
We’ll also review mozilla.dev.security.policy Mailing List communications again.

Has SECOM reviewed past CA incidents around similar omissions?

We have reviewed the similar cases of the past CA incidents.

TWCA: CA Certificate Missing from Audit Reports
https://bugzilla.mozilla.org/show_bug.cgi?id=1716670

E-Tugra: CA Certificate Missing from Audit Reports
https://bugzilla.mozilla.org/show_bug.cgi?id=1716843

Netlock: CA Certificate Missing from Audit Reports
https://bugzilla.mozilla.org/show_bug.cgi?id=1716874

Why did SECOM fail to disclose anything about the ALV failures?

We were made aware of the ALV failures by Ben-san of Mozilla, but we did not have an opportunity to disclose them before Ben-san filed this bug because our discussion was not fully done.

Let us summarize.
The misunderstanding for audit was due to our lack of awareness that all intermediate CA certificates needed to be included in audits until excluded from auditing by revocation or expiration.
Regarding audit, the dedicated team also conducted training for related parties to understand the “from the cradle to the grave” audit requirements.

The CCADB ALV failures can be resolved in September 2021, so that no audit omissions will occur in the future.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Flags: needinfo?(h-kamo)

Ben Wilson

Reporter

Updated

•

3 years ago

Whiteboard: [ca-compliance] Next update 2021-07-15 → [ca-compliance] Next update 2021-08-01

Ryan Sleevi

Comment 10

•

3 years ago

Thanks for the update. I've not fully examined each of the certificates to flag any matters for BR scope and compliance, but am assuming and expecting that relevant policies (such as Sections 7.1.2.2 and Section 8.1 of the BRs, as well as the expectations of root programs re: scope of audits and disclosures) will be followed.

(In reply to Hisashi Kamo from comment #9)

CA Certificates to be Revoked and Re-issued
(We are not backdating “not before”, so that “not before” will be in 2021. These new CA certificates will be included in the next WebTrust audit delivered in 2022.)

Note that there are no prohibitions on backdating sub-CA certificates, and there are potentially legitimate reasons (such as what we're discussing here - which is replacing an existing CA certificate with a more constrained version). To the extent that it may help keep existing (non-TLS) certificates viable, Google sees no concern with dating these new, constrained, replacement certificates to the original issuance date of their unconstrained versions.

Again, in Japan, there are rather many cases where "Certificate Authority" and "Certificate for Certificate Authority" are confused and used, not only by the general public but also by those involved in certification business. One of the causes of the omission from the audit report through the exchange of information with the audit firm, is this confusion, we figured.

This is not just a Japanese problem, and has been discussed in the CA/BF regarding terminology, to better clarify expectations (for CAs and auditors). :)

That said, it does sound like the current expectation, namely that all CA certificates are included, is at least appropriately understood going forward, even when multiple certificates exist for the same SPKI and/or same subject.

Hisashi Kamo

Assignee

Comment 11

•

3 years ago

Ryan-san,

Thank you for your comments.

Note that there are no prohibitions on backdating sub-CA certificates, and there are potentially legitimate reasons (such as what we're discussing here - which is replacing an existing CA certificate with a more constrained version).

Thank you again for your advice.
As a result of reexamination, we are not backdating “not before”, so that “not before” will be in 2021.

That said, it does sound like the current expectation, namely that all CA certificates are included, is at least appropriately understood going forward, even when multiple certificates exist for the same SPKI and/or same subject.

We are now understanding this matter correctly and describe it appropriately in the audit report.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Hisashi Kamo

Assignee

Comment 12

•

3 years ago

Ryan-san and Ben-san,

We'd like to report the updated status.

all CA certificates mentioned in this bug will be included in our WebTrust audit for the period ending June 6, 2021. The WebTrust audit report will be made available in early September 2021.

Now we are working with KPMG on WebTrust annual audit.
As mentioned in Comment 9, our dedicated team is taking the initiative to implement the reliable response.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Hisashi Kamo

Assignee

Comment 13

•

3 years ago

Ryan-san and Ben-san,

Regarding the previous comment below, we are in the process of responding to our WebTrust audit as planned schedule.

all CA certificates mentioned in this bug will be included in our WebTrust audit for the period ending June 6, 2021. The WebTrust audit report will be made available in early September 2021.

Now we are working with KPMG on WebTrust annual audit.
As mentioned in Comment 9, our dedicated team is taking the initiative to implement the reliable response.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Ben Wilson

Reporter

Updated

•

3 years ago

Whiteboard: [ca-compliance] Next update 2021-08-01 → [ca-compliance] Next update 2021-08-15

Hisashi Kamo

Assignee

Comment 14

•

3 years ago

Ryan-san and Ben-san,

Please let us update the current status of the WebTrust audit.

The auditor KPMG completed our on-site audit on August 11th.
We are steadily continuing to respond for making the WebTrust audit report available as planned schedule in early September 2021.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Ben Wilson

Reporter

Updated

•

3 years ago

Whiteboard: [ca-compliance] Next update 2021-08-15 → [ca-compliance] Next update 2021-09-06

Hisashi Kamo

Assignee

Comment 15

•

3 years ago

Ryan-san and Ben-san,

We'd like to update the current status.

all CA certificates mentioned in this bug will be included in our WebTrust audit for the period ending June 6, 2021. The WebTrust audit report will be made available in early September 2021.

Regarding our WebTrust audit, all evaluations by our auditor, KPMG have been completed.
KPMG submitted the WebTrust report to CPA Canada on September 3rd.
The report will be published on the WebTrust public site anytime soon.

CA Certificates to be Revoked and Keys Destroyed
CA Certificates to be Revoked and Re-issued

The revocations for all intermediate CA certificates have been completed, as planned in comment 9.

After the publication of the WebTrust report, we will update the audit information in CCADB, so that all ALV errors in CCADB will be resolved.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Ben Wilson

Reporter

Comment 16

•

3 years ago

Prior to receiving the Webtrust Seal files/URLs from CPA Canada, if you have drafts of the non-final audit reports, they can be uploaded as attachments to Bug 1313445 for advance ALV testing (created for this purpose). Also, I think you should now open your 2021 audit case in the CCADB and start working on it so that we can check those things that can be checked in advance.

Ben Wilson

Reporter

Updated

•

3 years ago

Whiteboard: [ca-compliance] Next update 2021-09-06 → [ca-compliance]

Hisashi Kamo

Assignee

Comment 17

•

3 years ago

Ryan-san and Ben-san,

Please let us update.

We have registered all of our WebTrust audit information on CCADB.
As a result, the ALV error has been resolved.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Hisashi Kamo

Assignee

Comment 18

•

3 years ago

Ryan-san and Ben-san,

There is nothing new to report this week.
We will be continuing to watch this Bugzilla.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Ben Wilson

Reporter

Comment 19

•

3 years ago

I will close this bug on or about Friday, 29-Oct-2021.

Flags: needinfo?(bwilson)

Ben Wilson

Reporter

Updated

•

3 years ago

Status: ASSIGNED → RESOLVED

Closed: 3 years ago

Flags: needinfo?(bwilson)

Resolution: --- → FIXED

Nobody; OK to take it and work on it

Updated

•

1 year ago

Product: NSS → CA Program

David Lawrence [:dkl]

Updated

•

1 year ago

Whiteboard: [ca-compliance] → [ca-compliance] [audit-failure]