Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: SECOM Request for EV Treatment
223 views
Skip to first unread message
Ryan Sleevi
Aug 25, 2015, 3:29:37 PM8/25/15
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
On Wed, August 5, 2015 2:51 pm, Kathleen Wilson wrote:
> SECOM has applied to enable EV treatment for the "Security Communication
> RootCA2" root certificate that was included in NSS via Bugzilla Bug
> #527419.
>
> SECOM is a Japanese commercial CA that provides SSL and client
> certificates for e-Government and participates in several projects for
> financial institutions to ensure the secured on-line transactions.
> This begins the discussion of the request from SECOM to enable EV
> treatment for the "Security Communication RootCA2" root certificate that
> is currently included in NSS.
>
> At the conclusion of this discussion I will provide a summary of issues
> noted and action items. If there are outstanding issues, then an
> additional discussion may be needed as follow-up. If there are no
> outstanding issues, then I will recommend approval of this request in
> the bug.
Hi Kathleen,
I've attempted to separately review this inclusion request and examine the
CP and CPS.
Overall, this was the most difficult review, given the lack of
availability of the policy documentation in English. While I attempted to
use Google Translate for most of it, I think it may be noteworthy to
consider requiring CAs to provide translated versions of their documents
in a future update of the Mozilla inclusion policy.
The most recent audit information for SECOM that I can find is not the
1717 seal you indicated, but Seal #1907,
https://cert.webtrust.org/SealFile?seal=1907&file=pdf
In examining that seal, we see that there are a variety of CP/CPSes
provided as part of in scope for the audit. Relevant to this discussion,
it appears, is the "Security Communications Root CA2 Certification
Practice Statement" [1], the "Security Communications Root CA2 CA
Certificate Policy" [2], and the "SECOM Passport for Web EV 2.0 CA" CP [3]
and [4].
Given that the SECOM Root CA2 is already included in Mozilla's Root
Program, I attempted to focus my efforts on reviewing documents [3] and
[4], as they were deemed most relevant for EV enablement.
While there are a several positive things noted within the CP/CPS,
overall, I'm concerned about the lack of information provided that makes
it difficult to impossible for the community to reliably inspect SECOM's
conformance to the relative policies, and leaves ambiguity with respect to
Mozilla's own ability to ensure that SECOM is operating in the public
interest.
Given that [3] largely defers to [4] for most sections, I will focus my
primary comments on [4], and then circle back.
https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf
Good things:
- Section 1.5.2 provides contact information for the public in the event
of the need to revoke a certificate immediately. This is quite useful for
relying parties and members of the public to raise concern, and many CAs
make this difficult to find.
- Section 7.1 provides an exhaustive list of the certificate profile,
fields, and values. This sort of documentation is what ideally all members
of the Mozilla Root Store would provide, and provides ways for the public
to detect non-conformance to the profile specified.
Mixed things:
- While Section 4.1 indicates that SECOM will examine CAA records, as
required by version 1.2.0 of the Baseline Requirements (as adopted by
Ballot 125), SECOM does not list which CAA records it will process or what
it would do if they mismatch. This may be seen as an incomplete adherence
to the Baseline Requirements, but I would rather see it as a reasonable
confusion related to expectations. An ideal resolution for this would be
for SECOM to indicate what CAA records it will expect to find (if CAA is
present) in order to issue, and what SECOM's process and procedures will
be for CAA records that fail to meet that (e.g. to deny the request, to
treat it as a High-Value request, to require some form of extended
validation, to allow a notarized letter on company letterhead to override,
etc)
Bad things:
- Section 2.2 of the CP fails to provide information in the repository for
testing certificates issued by these roots. While SECOM's audit was
conducted against the WebTrust SSL BRs 1.1 (themselves based on the CA/B
Forum's SSL BRs 1.1), this was required in Appendix C (normatively) of the
BRs, and has been incorporated in Section 2.2 of the BRs 1.3.0 (providing
a model policy for CAs to adopt). I consider this a major issue of
non-conformance, although it may be remediated relatively easily.
- Section 3.2.2 fails to comprehensively explain how domain name
validation works. This is unquestionably the most important part of a CAs
operation, and I had difficulty finding any such information provided in
any of the attested-to documents by the auditors. While Auditors are,
unfortunately, not required to examine the CP/CPS of CAs for conformance
to the BRs, this makes it difficult for the public to independently
verify.
Your own efforts in the tracking bug appear to have lead to documents
[5] and [6], which were translated in brief in your original email.
However, I could not find any reference to these documents being
incorporated into the CP/CPS. This is quite concerning, because changes
may be made to these documents inconsistent with respect to the
requirements of [7], notably that CAs update Mozilla when policies and
business practices change. It also suggests that these documents may be
exempted from the change control procedures required by the Baseline
Requirements.
To me personally, this represents a significant risk to the community,
and thus represents a major issue. Remediation for this should be to
comprehensively document the name validation and issuance verification
steps within the CA's CP/CPS, without reference to external
documentation, so that it may be validated by members of the public and
so that expectations regarding changes are clear. We've already seen one
CA be confused by such expectations (CNNIC, with respect to issuing
subordinate CAs), and I would be loathe to see another. This will
require a CP/CPS update, and I believe it's best to defer acceptance
until that's been completed and reviewed again during a public comment
period.
- Section 4.4.3 would potentially prohibit SECOM from publishing
information about certificates they issue using Certificate Transparency,
although I applaud them for clarifying in [3] that all information
presented in certificates is treated as non-confidential. I consider this
a minor issue worth noting, but not requiring remediation.
- Section 4.9.7 fails to clearly document the frequency of OCSP
publications or of the validity periods of the OCSP responses. I consider
this a major issue, but which may be easily remediated.
- Section 6.1.7 indicates the keyEncipherment usage, but that may be
inconsistent with the usage of EC keys. This is likely a minor issue, and
easily remediated, but may highlight some confusion on SECOM's part about
RFC 5280.
- Section 7.1.1 is somewhat inconsistent with respect to the SHA-1
signatures. While the other policy documentation indicates support for
SHA-2 signatures, it would seem non-conforming to their stated policies
for them to issue such certificates. I consider this a major issue that
the auditor should have flagged (as to inconsistent documentation).
- Section 7.3 fails to document an OCSP profile, as required. Other
documentation refers back to this section, so it's clearly insufficient.
https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CPS.pdf
Good things:
- As noted before, the CPS notes that the information contained within a
certificate is non-confidential, which is a positive step for CAs to note.
Bad things:
- The CPS was last updated in 2012. This suggests that SECOM may not be
following the changes in the Baseline Requirements. There is also
ambiguity with respect to the expectations of the BRs and annual
publications of such documents, and whether or not annual updates are
required.
Overall, I'm quite concerned about the inability to find (public)
documentation as to the practices of this CA. I recognize that the
information gathering process can be difficult, especially when language
barriers exist, but this also makes it difficult for members of the public
to independently evaluate the trustworthiness and conformance to Mozilla's
policies.
The inconsistencies within the documents, and the absence of information,
also represents a concern. While I can understand that the WebTrust Audit
Criteria do not require an auditor to independently examine the CP/CPS
(unfortunately), this does raise concern about the thoroughness and
attentiveness of the audit.
I would like to recommend that the inclusion request be deferred until
sufficient information is incorporated into the CP and CPS, as Mozilla has
demonstrated in the past the expectation of CAs to adhere to those stated
policies (c.f. CNNIC) and has documented requirements related to the
update, notification, and change of those policies (c.f. [7]). After
completing their updated documentation, I think it's reasonable to have
another public review phase related to these updates.
For SECOM's benefit, it may help to examine the CA/Browser Forum SSL
Baseline Requirements 1.3.0 [8], which provides a model RFC
3647-compatible enumeration of the Baseline Requirements expectations. By
examining their CP/CPS in this light, it would assist SECOM's management
that they have implemented and documented conformance to the SSL Baseline
Requirements.
While I would not request a new audit to the updated policies, I also
think it would be important to ensure that the next audit (eta June 2016)
would ensure SECOM's adherance to the updated policies.
[1] https://repository.secomtrust.net/SC-Root/SCRootCPS.pdf
[2] https://repository.secomtrust.net/SC-Root/SCRootCP1.pdf
[3] https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CPS.pdf
[4] https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf
[5] https://www.secomtrust.net/service/pfw/apply/ev/1_3.html
[6] https://www.secomtrust.net/service/pfw/apply/ev/sts_1.html
[7]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/
[8] https://cabforum.org/wp-content/uploads/CAB-Forum-BR-1.3.0.pdf
> SECOM has applied to enable EV treatment for the "Security Communication
> RootCA2" root certificate that was included in NSS via Bugzilla Bug
> #527419.
>
> SECOM is a Japanese commercial CA that provides SSL and client
> certificates for e-Government and participates in several projects for
> financial institutions to ensure the secured on-line transactions.
> This begins the discussion of the request from SECOM to enable EV
> treatment for the "Security Communication RootCA2" root certificate that
> is currently included in NSS.
>
> At the conclusion of this discussion I will provide a summary of issues
> noted and action items. If there are outstanding issues, then an
> additional discussion may be needed as follow-up. If there are no
> outstanding issues, then I will recommend approval of this request in
> the bug.
Hi Kathleen,
I've attempted to separately review this inclusion request and examine the
CP and CPS.
Overall, this was the most difficult review, given the lack of
availability of the policy documentation in English. While I attempted to
use Google Translate for most of it, I think it may be noteworthy to
consider requiring CAs to provide translated versions of their documents
in a future update of the Mozilla inclusion policy.
The most recent audit information for SECOM that I can find is not the
1717 seal you indicated, but Seal #1907,
https://cert.webtrust.org/SealFile?seal=1907&file=pdf
In examining that seal, we see that there are a variety of CP/CPSes
provided as part of in scope for the audit. Relevant to this discussion,
it appears, is the "Security Communications Root CA2 Certification
Practice Statement" [1], the "Security Communications Root CA2 CA
Certificate Policy" [2], and the "SECOM Passport for Web EV 2.0 CA" CP [3]
and [4].
Given that the SECOM Root CA2 is already included in Mozilla's Root
Program, I attempted to focus my efforts on reviewing documents [3] and
[4], as they were deemed most relevant for EV enablement.
While there are a several positive things noted within the CP/CPS,
overall, I'm concerned about the lack of information provided that makes
it difficult to impossible for the community to reliably inspect SECOM's
conformance to the relative policies, and leaves ambiguity with respect to
Mozilla's own ability to ensure that SECOM is operating in the public
interest.
Given that [3] largely defers to [4] for most sections, I will focus my
primary comments on [4], and then circle back.
https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf
Good things:
- Section 1.5.2 provides contact information for the public in the event
of the need to revoke a certificate immediately. This is quite useful for
relying parties and members of the public to raise concern, and many CAs
make this difficult to find.
- Section 7.1 provides an exhaustive list of the certificate profile,
fields, and values. This sort of documentation is what ideally all members
of the Mozilla Root Store would provide, and provides ways for the public
to detect non-conformance to the profile specified.
Mixed things:
- While Section 4.1 indicates that SECOM will examine CAA records, as
required by version 1.2.0 of the Baseline Requirements (as adopted by
Ballot 125), SECOM does not list which CAA records it will process or what
it would do if they mismatch. This may be seen as an incomplete adherence
to the Baseline Requirements, but I would rather see it as a reasonable
confusion related to expectations. An ideal resolution for this would be
for SECOM to indicate what CAA records it will expect to find (if CAA is
present) in order to issue, and what SECOM's process and procedures will
be for CAA records that fail to meet that (e.g. to deny the request, to
treat it as a High-Value request, to require some form of extended
validation, to allow a notarized letter on company letterhead to override,
etc)
Bad things:
- Section 2.2 of the CP fails to provide information in the repository for
testing certificates issued by these roots. While SECOM's audit was
conducted against the WebTrust SSL BRs 1.1 (themselves based on the CA/B
Forum's SSL BRs 1.1), this was required in Appendix C (normatively) of the
BRs, and has been incorporated in Section 2.2 of the BRs 1.3.0 (providing
a model policy for CAs to adopt). I consider this a major issue of
non-conformance, although it may be remediated relatively easily.
- Section 3.2.2 fails to comprehensively explain how domain name
validation works. This is unquestionably the most important part of a CAs
operation, and I had difficulty finding any such information provided in
any of the attested-to documents by the auditors. While Auditors are,
unfortunately, not required to examine the CP/CPS of CAs for conformance
to the BRs, this makes it difficult for the public to independently
verify.
Your own efforts in the tracking bug appear to have lead to documents
[5] and [6], which were translated in brief in your original email.
However, I could not find any reference to these documents being
incorporated into the CP/CPS. This is quite concerning, because changes
may be made to these documents inconsistent with respect to the
requirements of [7], notably that CAs update Mozilla when policies and
business practices change. It also suggests that these documents may be
exempted from the change control procedures required by the Baseline
Requirements.
To me personally, this represents a significant risk to the community,
and thus represents a major issue. Remediation for this should be to
comprehensively document the name validation and issuance verification
steps within the CA's CP/CPS, without reference to external
documentation, so that it may be validated by members of the public and
so that expectations regarding changes are clear. We've already seen one
CA be confused by such expectations (CNNIC, with respect to issuing
subordinate CAs), and I would be loathe to see another. This will
require a CP/CPS update, and I believe it's best to defer acceptance
until that's been completed and reviewed again during a public comment
period.
- Section 4.4.3 would potentially prohibit SECOM from publishing
information about certificates they issue using Certificate Transparency,
although I applaud them for clarifying in [3] that all information
presented in certificates is treated as non-confidential. I consider this
a minor issue worth noting, but not requiring remediation.
- Section 4.9.7 fails to clearly document the frequency of OCSP
publications or of the validity periods of the OCSP responses. I consider
this a major issue, but which may be easily remediated.
- Section 6.1.7 indicates the keyEncipherment usage, but that may be
inconsistent with the usage of EC keys. This is likely a minor issue, and
easily remediated, but may highlight some confusion on SECOM's part about
RFC 5280.
- Section 7.1.1 is somewhat inconsistent with respect to the SHA-1
signatures. While the other policy documentation indicates support for
SHA-2 signatures, it would seem non-conforming to their stated policies
for them to issue such certificates. I consider this a major issue that
the auditor should have flagged (as to inconsistent documentation).
- Section 7.3 fails to document an OCSP profile, as required. Other
documentation refers back to this section, so it's clearly insufficient.
https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CPS.pdf
Good things:
- As noted before, the CPS notes that the information contained within a
certificate is non-confidential, which is a positive step for CAs to note.
Bad things:
- The CPS was last updated in 2012. This suggests that SECOM may not be
following the changes in the Baseline Requirements. There is also
ambiguity with respect to the expectations of the BRs and annual
publications of such documents, and whether or not annual updates are
required.
Overall, I'm quite concerned about the inability to find (public)
documentation as to the practices of this CA. I recognize that the
information gathering process can be difficult, especially when language
barriers exist, but this also makes it difficult for members of the public
to independently evaluate the trustworthiness and conformance to Mozilla's
policies.
The inconsistencies within the documents, and the absence of information,
also represents a concern. While I can understand that the WebTrust Audit
Criteria do not require an auditor to independently examine the CP/CPS
(unfortunately), this does raise concern about the thoroughness and
attentiveness of the audit.
I would like to recommend that the inclusion request be deferred until
sufficient information is incorporated into the CP and CPS, as Mozilla has
demonstrated in the past the expectation of CAs to adhere to those stated
policies (c.f. CNNIC) and has documented requirements related to the
update, notification, and change of those policies (c.f. [7]). After
completing their updated documentation, I think it's reasonable to have
another public review phase related to these updates.
For SECOM's benefit, it may help to examine the CA/Browser Forum SSL
Baseline Requirements 1.3.0 [8], which provides a model RFC
3647-compatible enumeration of the Baseline Requirements expectations. By
examining their CP/CPS in this light, it would assist SECOM's management
that they have implemented and documented conformance to the SSL Baseline
Requirements.
While I would not request a new audit to the updated policies, I also
think it would be important to ensure that the next audit (eta June 2016)
would ensure SECOM's adherance to the updated policies.
[1] https://repository.secomtrust.net/SC-Root/SCRootCPS.pdf
[2] https://repository.secomtrust.net/SC-Root/SCRootCP1.pdf
[3] https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CPS.pdf
[4] https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf
[5] https://www.secomtrust.net/service/pfw/apply/ev/1_3.html
[6] https://www.secomtrust.net/service/pfw/apply/ev/sts_1.html
[7]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/
[8] https://cabforum.org/wp-content/uploads/CAB-Forum-BR-1.3.0.pdf
h-k...@secom.co.jp
Sep 11, 2015, 1:02:56 AM9/11/15
to mozilla-dev-s...@lists.mozilla.org
2015年8月26日水曜日 4時29分37秒 UTC+9 Ryan Sleevi:
Dear Ryan-san,
Thank you for your comments.
We Secom are now preparing the entire CP and CPS into English and also the answers.
Thanks again for your time and consideration.
Best regards,
Hisashi Kamo
Thank you for your comments.
We Secom are now preparing the entire CP and CPS into English and also the answers.
Thanks again for your time and consideration.
Best regards,
Hisashi Kamo
h-k...@secom.co.jp
Oct 15, 2015, 8:14:03 PM10/15/15
to mozilla-dev-s...@lists.mozilla.org
2015年8月26日水曜日 4時29分37秒 UTC+9 Ryan Sleevi:
The SECOM CP and CPS have been translated into English and attached to
https://bugzilla.mozilla.org/show_bug.cgi?id=1096205
CP (English): https://bugzilla.mozilla.org/attachment.cgi?id=8674034
CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=8674035
The answers for Ryan-san questions are as follows.
> - While Section 4.1 indicates that SECOM will examine CAA records, as
> required by version 1.2.0 of the Baseline Requirements (as adopted by Ballot 125), SECOM does not list which CAA records it will process or what it would do if they mismatch.
> This may be seen as an incomplete adherence to the Baseline
> Requirements, but I would rather see it as a reasonable confusion
> related to expectations.
> - Section 2.2 of the CP fails to provide information in the repository
> for testing certificates issued by these roots.
> - Section 3.2.2 fails to comprehensively explain how domain name
> validation works.
https://www.secomtrust.net/service/pfw/apply/ev/1_3.html
https://www.secomtrust.net/service/pfw/apply/ev/sts_1.html
In order to clarify, we will add it in the CP how domain name validation works.
> - Section 4.9.7 fails to clearly document the frequency of OCSP publications > or of the validity periods of the OCSP responses.
> - Section 6.1.7 indicates the keyEncipherment usage, but that may be
> inconsistent with the usage of EC keys.
> - Section 7.1.1 is somewhat inconsistent with respect to the SHA-1
> signatures. While the other policy documentation indicates support for
> SHA-2 signatures,
"Table 7.1-1 SECOM Passport for Web EV CA Server Certificate Profile" is described for SHA-1 signature.
> - Section 7.3 fails to document an OCSP profile, as required. Other
> documentation refers back to this section, so it's clearly insufficient.
"Table 7.1-2 SECOM Passport for Web EV CA OCSP Server Certificate Profile" is described for SHA-1 signature.
Thank you for your time and consideration.
h-k...@secom.co.jp
Oct 27, 2015, 5:05:41 AM10/27/15
to mozilla-dev-s...@lists.mozilla.org
Dear Ryan-san and public discussion members,
The updated SECOM CP for Ryan-san's comment is attached to
https://bugzilla.mozilla.org/show_bug.cgi?id=1096205
CP (English): https://bugzilla.mozilla.org/attachment.cgi?id=8679302
The addition for the section 2.2, 3.2.7 and 4.9.9 addressed with proposed update to the English version of CP.
The corresponding section were made comprehensible by red characters.
Thank you for your consideration.
The updated SECOM CP for Ryan-san's comment is attached to
https://bugzilla.mozilla.org/show_bug.cgi?id=1096205
CP (English): https://bugzilla.mozilla.org/attachment.cgi?id=8679302
The addition for the section 2.2, 3.2.7 and 4.9.9 addressed with proposed update to the English version of CP.
The corresponding section were made comprehensible by red characters.
Thank you for your consideration.
h-k...@secom.co.jp
Oct 27, 2015, 5:06:53 AM10/27/15
to mozilla-dev-s...@lists.mozilla.org
0 new messages