Re: SSC Root Inclusion Request

175 views
Skip to first unread message

Ryan Sleevi

unread,
Aug 28, 2015, 9:17:25 PM8/28/15
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
On Wed, July 29, 2015 1:34 pm, Kathleen Wilson wrote:
> SSC has applied to include three root certificates as follows: enable
> the email trust bit for the “SSC GDL CA VS Root†certificate; enable
> the
> code signing and email trust bits for the “SSC GDL CA Root Aâ€
> certificate; and enable all three trust bits for the “SSC GDL CA Root
> Bâ€
> certificate. EV treatment is also requested for the “SSC GDL CA Root
> Bâ€
> certificate.
<SNIP>
> This begins the discussion of the request from SSC to include three root
> certificates as follows: enable the email trust bit for the “SSC GDL CA
> VS Root†certificate; enable the code signing and email trust bits for
> the “SSC GDL CA Root A†certificate; and enable all three trust bits
> for
> the “SSC GDL CA Root B†certificate. EV treatment is also requested
> for
> the “SSC GDL CA Root B†certificate.
>
> 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.
>
> Kathleen
>

Kathleen,

I've completed a thorough review of the relevant CP and CPS for SSC.

First, on a practical and procedural note, should Mozilla continue accept
certificates without the "Websites" trust bit? Considering that there are
not clear guidelines for how to process either code signing or email, and
considering their relevance (or lack thereof) to Mozilla, it would seem
wise to carefully consider both whether to accept new applications and
what to do with existing applications. My own personal suggestion is to
not accept new certificates, and to purge the existing ones.

I have not examined the CP or CPS for issues related to these two, and
only focused on the Website Trust bits - thus, relevant to the SSC GDL CA
Root B hierarchy.

I conducted my primary review against the (draft) 4.10 version of their
policy. Though it indicates there were versions 4.8 and 4.9, 4.7 is the
current (audited) policy, it would appear. The URL for this document is
https://bug379152.bmoattachments.org/attachment.cgi?id=8613560

== Good ==
* Section 4.1 clearly states the Subscriber Agreement includes a
requirement to consent to publish the certificate (for example, via
Certificate Transparency)
* Section 4.2.3 indicates that the maximum window between RA verification
of information and issuance is only five days.
* Section 4.4.3 provides a suitable carveout to allow SSC to publish
certificates via Certificate Transparency.
* Section 4.7 clearly identifies that other elements of a certificate,
beyond the Subject, may change during a renewal or rekey
* Section 4.9.3 clearly recognizes third-parties may request revocation /
provide information that may lead to revocation.

== Meh ==
* Section 3.1 implies that SSC will issue certificates with names encoded
using the TeletexString, BMPString, or UniversalString encodings. These
are all STRONGLY discouraged in RFC 5280, Section 4.1.2.4, except for
legacy interoperability cases. Based on the stated CP and CPS, it does not
seem necessary or wise to support these types.
* Section 3.1.1 uses a somewhat ad-hoc stringified form to represent
names, leaving it ambiguous as to the actual structure. While the
footnotes clearly indicate the relevant OIDs, perhaps the tabular form
employed by other CPSes (such as the recently completed WISeKey review)
may provide greater clarity to Relying Parties.

== Bad ==
* Section 3.2.2 leaves it ambiguous and underspecified how domain name
authorization is performed.
* Section 3.2.4 leaves it ambiguous about how email addresses are validated.
* Section 3.3.1 allows for rekey using previously validated information,
for a period greater than allowed by the EV guidelines (36 months in the
CPS, 13 months in the EVG)
* Section 4.1 includes a subscriber obligation to "install the ...
certificate only on the server accessible at a Domain Name indicated in
the certificate." This obligation is ambiguous (technically, any server is
accessible via any domain name, with the right configuration) and likely
unenforceable. Plus it's just weird :)
* Section 4.9 implies that DVCP/OVCP certificates may take 48 hours to
revoke, rather than the 24 hours required by the Baseline Requirements.
* Section 4.9.1 has a number of revocation reasons stated only for
EVCP/EVCP+, even though they are applicable to DVCP/OVCP.
* Section 4.9.9 omits OCSP for DVCP/OVCP.
* Section 6.1.6 lacks a robust definition of the key sizes and algorithm
parameters.
* Section 6.1.7 omits the keyEncipherment bit, potentially prohibiting
forward-secure key exchanges with RSA keys.
* Section 7.1 neither documents nor does the repository provide copies of
the Certificate Profiles. Section 7.1 of the CP appears to expressly
require this, so it would seem as if the CPS is not adhering to the CA's
CP.
* Section 7.2 links to a URL that does not provide the CRL profile,
despite being required by the CP.
* Section 7.3 does not include an OCSP profile, despite being required by
the CP.

== Questions ==
- From interpreting Section 3.1.1, it would appear that a TLS server
certificate (e.g. DVCP, OVCP, EVCP, EVCP+) will never have a commonName
field appear within the subject, as the commonName is expressly identified
as containing a legal person's identity. Is this correct?
- Section 3.1.2 suggests the formulation of the commonName is "firstname
lastname". Names come in many forms (e.g. Seal, Madonna, Sting), and in
many cultures, may not follow such a construct. If a Lithuanian citizen
legally changed their name to "google.com", would SSC issue such a
certificate?
- Section 3.1.5 indicates that names are unique, but the name form of
Section 3.1.1 does not provide enough disambiguators to guarantee this for
the case of non-qualified certificates. How does SSC handle this?
- I could not find any documentation within the CP or CPS regarding the
practices, procedures, and controls for the issuance of third-party
subordinate CAs. The information gathering document suggests this is
supported, but the absence of documentation is concerning.


I also briefly reviewed the CP, version 4.4 (
https://gdl.repository.ssc.lt/en/repository/documents/certificate-policy-ssc-gdl-ca-v4.4.pdf
), which largely defers to/sets stipulations for the CPS. Within this, I
found one area particularly concerning (i.e. "bad"), which is that Section
4.9.13 indicates Certificate Suspension may be supported.

>From the documents and repository, I was unable to locate suitable test
sites complying with Section 2.2 of the Baseline Requirements (v1.3.0).
Indeed, of the test sites provided (
https://gdl.repository.ssc.lt/en/repository/test-certificates/ ), two were
improperly configured (OV SSL Personal, OV SSL Legal Entity). The revoked
certificates were merely hosted as certificates, not as separate Web pages
using Subscriber certificates, as required by the BRs.

Perhaps most concerning of all in this application is that the CPS
indicates the issuance of DVCP/OVCP certificates, except no such audit has
been performed according to Tuvit. The ambiguity regarding much of the TLS
issuance practices, and in particular, the request for the "Website" trust
bits without a corresponding audit for the issuance practices related to
website trust bits (DVCP/OVCP, equivalent conceptually to the "Webtrust
for CAs - SSL Baseline Requirements v2.0" documentation), give me strong
concern.

Remediation of this would be a significant undertaking to update the CP
and CPS to provide appropriate guidance and statements as to the adherence
to the BRs and Mozilla Policy. In many cases, it simply incorporates by
reference, which concerns me that SSC may not have properly implemented
controls to actually follow the BRs.

I would encourage SSC to review the past several CA inclusion requests,
including the most recent of WISeKey, and the areas of concern flagged
there, many of which are applicable here. Similarly, examining the CP and
CPS in the context of the CA/Browser Forum's Baseline Requirements, v1.3.0
will provide ample guidance as to the expected assertions, many of which
were absent or incorporated by reference, which give significant concern.

Moudrick M. Dadashov

unread,
Aug 31, 2015, 6:47:06 PM8/31/15
to ryan-mozde...@sleevi.com, Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
Dear Ryan,

thank you for your constructive criticism, suggestions and recommendations.

This is just a short confirmation that we are working on the feedback
which we expect to post in a couple of days.

All the best,
M.D.
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

Moudrick M. Dadashov

unread,
Sep 8, 2015, 11:56:16 AM9/8/15
to ryan-mozde...@sleevi.com, Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
Thank you for your comments.

Let me start with your questions first.

RS-Q1:

"From interpreting Section 3.1.1, it would appear that a TLS server
certificate (e.g. DVCP, OVCP, EVCP, EVCP+) will never have a commonName
field appear within the subject, as the commonName is expressly
identified as containing a legal person's identity. Is this correct"?

SSC:

Section 3.1.1 of the CPS says "Whether the Subject of a certificate
issued under this CPS is a human, organization, device or service can be
discovered by Subject DN as indicated in the EN 319 412 1-5 series
standards."

The drafts of the standards mentioned above are already under their
Approval Procedure (until 16 October 2015), below is the list of
standards (with commonName related clarifications):

- 319
412-1<http://www.etsi.org/deliver/etsi_en/319400_319499/31941201/01.00.00_20/en_31941201v010000a.pdf>:
Overview and common data structures
- 319
412-2<http://www.etsi.org/deliver/etsi_en/319400_319499/31941202/02.00.15_20/en_31941202v020015a.pdf>:
Certificate profile for certificates issued to natural persons:

5.2.6 Subject
The subject field shall include the following attributes as specified in
Recommendation ITU-T X.520 [7]:
• countryName;
• choice of (givenName and surname) or pseudonym; and
• commonName.
If these mandatory attributes are not sufficient to ensure Subject name
uniqueness within the context of the issuer, then the serialNumber shall
be present. The subject field shall not contain more than one instance
of commonName and countryName.

- 319
412-3<http://www.etsi.org/deliver/etsi_en/319400_319499/31941203/01.00.00_20/en_31941203v010000a.pdf>:
Certificate profile for certificates issued to legal persons:

4.1 Generic requirements
All certificate fields and extensions shall comply with ETSI EN 319
412-2 [2] with the amendments specified in the present document.
4.2 Basic certificate fields
4.2.1 Subject
The subject field shall include at least the following attributes as
specified in Recommendation ITU-T X.520 [1]:
• countryName;
• organizationName;
• organizationIdentifier; and
• commonName.

The commonName attribute value shall contain a name commonly used by the
subject to represent itself. This name needs not be an exact match of
the fully registered organization name.

- 319
412-4<http://www.etsi.org/deliver/etsi_en/319400_319499/31941204/01.00.00_20/en_31941204v010000a.pdf>:
Certificate profile for web site certificates issued to organisations:

4.1 Generic profile requirements
All certificate fields and extensions shall comply with requirements on
subscriber certificates stated in the Certificate Content and Profile
(clause 9 and appendix B) of the CA/Browser Forum Baseline Requirements
for the Issuance and Management of Publicly-Trusted Certificates [2], or
extended validation certificates [3], with the amendments specified in
clauses 4.2 and 4.3 for qualified certificates.

So, the answer to your question would be "No".

RS-Q2:

"Section 3.1.2 suggests the formulation of the commonName is "firstname
lastname". Names come in many forms (e.g. Seal, Madonna, Sting), and in
many cultures, may not follow such a construct. If a Lithuanian citizen
legally changed their name to "google.com", would SSC issue such a
certificate"?

SSC:

To answer this question correctly we needed some clarification from our
state agency responsible for human name registration (as it takes more
time to get their feedback, here is how it'd work according to our
recent policy):

If an applicant. whose name according to his/her ID is "google.com" (we
are still waiting to get some clarification if "google.com" can be a
legally registered name), then the application will pass our initial
verification (section 3.2.3 of CPS) however further processing of the
application will be suspended according to section 4.1 of CPS (high risk
application). Final decision for issuing such a certificate assumes
written communication with the holder
(http://www.google.com/about/company/) of the high risk name "google.com".

RS-Q3:

"Section 3.1.5 indicates that names are unique, but the name form of
Section 3.1.1 does not provide enough disambiguators to guarantee this
for the case of non-qualified certificates. How does SSC handle this"?

SSC:

As mentioned in RS-Q1 above, uniqueness of names is ensured by the
combination of semantic identifier/serialNumber.

RS-Q4:

"I could not find any documentation within the CP or CPS regarding the
practices, procedures, and controls for the issuance of third-party
subordinate CAs. The information gathering document suggests this is
supported, but the absence of documentation is concerning".

SSC:

Here is what the information gathering document for all three Roots says:

Externally Operated SubCAs: None, and none planned.
Cross Signing: None, and none planned.

RS-M1:

"Section 3.1 implies that SSC will issue certificates with names encoded
using the TeletexString, BMPString, or UniversalString encodings. These
are all STRONGLY discouraged in RFC 5280, Section 4.1.2.4, except for
legacy interoperability cases. Based on the stated CP and CPS, it does
not seem necessary or wise to support these types".

SSC:

This is now in our "must see" list.

RS-M2:

Section 3.1.1 uses a somewhat ad-hoc stringified form to represent
names, leaving it ambiguous as to the actual structure. While the
footnotes clearly indicate the relevant OIDs, perhaps the tabular form
employed by other CPSes (such as the recently completed WISeKey review)
may provide greater clarity to Relying Parties.

SSC:

With the upcoming EN approval SSC will review/update its CP/CPS, the
recommendation is now in our "must fix" list.

RS-B1:

"Section 3.2.2 leaves it ambiguous and underspecified how domain name
authorization is performed".

SSC:

Section 3.2.2 is for Authentication of organization identity, domain
name authentication is in Section 3.2.5 (Service authentication):

If the Subject of certificate is a service offered via a network, the
Applicant must provide identifying information and an acceptable proof
of ownership which shall include unique software or service name (e.g.
DNS name), service attributes to be included in the certificate, if any,
and owner's contact information.
The CA shall validate that the Applicant is:
(a) authorized to request a certificate for the service;
(b) the real owner of the service (through an appropriate reliable 3rd
party database);
(c) able to demonstrate control of the domain (by manipulating DNS
records and server configuration).

Also:
Section 4: For digital assets whose identifiers are maintained by third
parties (e.g. email addresses, domain names etc.) the RA verifies
operational existence by directly accessing/using the resource (e.g. a
server) or communicating through the resource (e.g. email address) and
legal existence - by obtaining independent ownership conformation from
the associated registrar.

RS-B2:

"Section 3.2.4 leaves it ambiguous about how email addresses are validated".

SSC:

Section 3.2.4 is for Device authentication.

CPS section 3.2.6: Information about the Subject, including email
address, is included in certificates only after it is reliably verified.

CPS section 4: For digital assets whose identifiers are maintained by
third parties (e.g. email addresses, domain names etc.) the RA verifies
operational existence by directly accessing/using the resource (e.g. a
server) or communicating through the resource (e.g. email address) and
legal existence - by obtaining independent ownership conformation from
the associated registrar.

Also, we maintain a separate document "Identity registration for
certificate issuing and Subscriber support" where we specify all
identity verification related procedures in detail. This document is
subject to audit and has to be explicitly listed in the Evaluation report.

4.5 VERIFICATION OF EMAIL ADDRESS OF A NATURAL PERSON

Verification of email addresses can be performed under two following cases:

1. The domain name part of the email address matches one of the domain
names controlled by the physical person.
2. The domain name part of the email address doesn't match any of the
domain names controlled by the physical person.

In case of SSL/TLS certificate application the Subject's
ownership/control of the domain name performed as described in section
6.1. and then an email request is sent to the address indicated in the
application form. The request has to be confirmed by the recipient by
clicking on the verification link in the email. In case if the
confirmation email doesn't arrive within the specified time frame, the
subscriber is automatically contacted by one of email addresses
associated with the domain name.

If the domain name part of the email address of physical person doesn't
match with any other domain names owned/controlled by the physical
person, and the confirmation email doesn't arrive within the specified
time frame, the registration process is suspended until a reliable
contact with the Subject has been reestablished through an alternative
communication channel.

To ensure validity of Subject's email address after the certificate
issuance within its validity time frame, an automatic email verification
procedure performed at least once in 12 month.

The procedure above is similar to verification of email address
ownership/control by the representative of a legal person. In later case
the challenge-response procedure provides more options for contacting
the subscriber/applicant in case if confirmation email is not received.

RS-B3:

Section 3.3.1 allows for rekey using previously validated information,
for a period greater than allowed by the EV guidelines (36 months in the
CPS, 13 months in the EVG)

SSC:

More precisely, Section 3.3.1 is about "reestablishing the identity"
which we consider a wider term than "use of previously validated
information".

According to the "Identity registration for certificate issuing and
Subscriber support" mentioned above, "use of previously validated
information" has two different considerations: 1) the CA's sole decision
to use previously validated information for issuing a certificate (falls
under limitations of BRs and EVGs) and 2) Subscriber's ***action*** for
reusing of his own previously submitted/verified document. The later is
an accepted method of submitting/confirming a Subscriber document.

This is now in our "must see" list, we'll try to clarify what
"reestablishing the identity" means.

RS-B4:

Section 4.1 includes a subscriber obligation to "install the certificate
only on the server accessible at a Domain Name indicated in the
certificate." This obligation is ambiguous (technically, any server is
accessible via any domain name, with the right configuration) and likely
unenforceable. Plus it's just weird.

SSC:

This is now in our "must see" list, the intention was to disclaim the
CA's responsibility for improperly installed certificate.

RS-B5:

Section 4.9 implies that DVCP/OVCP certificates may take 48 hours to
revoke, rather than the 24 hours required by the Baseline Requirements.

SSC:

Section 4.9: "The maximum delay between receipt of a revocation request
and the revocation status update available to all relying parties is 48
hours".

48 hours includes the time needed to authenticate the requester and
verify his/her authorization. ("Requests and reports relating to
revocation are processed on receipt, authenticated and checked to be
from an authorized source. Such reports and requests are confirmed as
required under SSC GDL CA's procedures").

RS-B6:

Section 4.9.1 has a number of revocation reasons stated only for
EVCP/EVCP+, even though they are applicable to DVCP/OVCP.

SSC:

This is now in our "must see" list for further clarification if needed.

RS-B7:

Section 4.9.9 omits OCSP for DVCP/OVCP.

SSC:

This is now in our "must fix" list.

RS-B8:

Section 6.1.6 lacks a robust definition of the key sizes and algorithm
parameters.

SSC:

6.1.6 Public key parameters generation and quality checking SSC GDL CA
public key parameters are defined in accordance with the appropriate
ETSI, FIPS and other reliable sources [51] of information.

[51] ECRYPT II Yearly Report on Algorithms and Key sizes, Katholieke
Universiteit Leuven, 2012.

Also please see other the key size and algorithm related statements in CPS:

6.1.1

b) CA-generated Subject keys are of a key length and for use with a
public key algorithm which are recognized by industry (Guidance on
algorithms and their parameters according to TS 102 176-1.);

7.1.3 Algorithm object identifiers

10.1 Normative references

[ALGO] ETSI SR 002 176 - Electronic Signatures and Infrastructures
(ESI); Algorithms and Parameters for Secure Electronic Signatures.

RS-B9:

Section 6.1.7 omits the keyEncipherment bit, potentially prohibiting
forward-secure key exchanges with RSA keys.

SSC:

This is now in our "must see" list. Also, please NOTE: The most recent
test run for evssl.gdl.ssc.lt (by Qualys SSL Labs) reports: Forward
Secrecy Yes (with most browsers) ROBUST (more info).

RS-B10:

Section 7.1 neither documents nor does the repository provide copies of
the Certificate Profiles. Section 7.1 of the CP appears to expressly
require this, so it would seem as if the CPS is not adhering to the CA's CP.

SSC:

Since the first drafts of new ETSI standards (ENs) were published more
than two years ago, like many other EU CAs, we've been updating our
system software to support the new profiles (documenting the profiles
is the last stage of this process). We are waiting now for the new ENs
to be officially published. Until then, for those interested in our
profiles (EE certificates, CRLs or OCSP responses), we suggest to review
our demo/test certs:

https://gdl.repository.ssc.lt/en/repository/test-certificates/

This is now in our "must fix" list as soon as ENs are oficially
published we will disclose our working profiles.

RS-B11:

Section 7.2 links to a URL that does not provide the CRL profile,
despite being required by the CP.

SSC:

This is now in our "must fix" list as in RS-B10.

RS-B12:

Section 7.3 does not include an OCSP profile, despite being required by
the CP.

SSC:

The same as above in RS-B10.

RS:

I also briefly reviewed the CP, version 4.4
(https://gdl.repository.ssc.lt/en/repository/documents/certificate-policy-ssc-gdl-ca-v4.4.pdf),
which largely defers to/sets stipulations for the CPS. Within this, I
found one area particularly concerning (i.e. "bad"), which is that
Section 4.9.13 indicates Certificate Suspension may be supported.

SSC:

The CP says:

4.9.13 Circumstances for suspension
CA MAY provide a certificate suspension service. Unlike the revocation,
suspension allows to re-enable the certificate. The expiry date of
suspended certificate remains unchanged.

And the CPS says:

4.9.13 Circumstances for suspension
Not applicable.

This is the compromise when "suspension" is defined by el. signature
Law. BTW when the eIDAS comes into full effect, we will no longer need this.

RS-O1

From the documents and repository, I was unable to locate suitable test
sites complying with Section 2.2 of the Baseline Requirements (v1.3.0).
Indeed, of the test sites provided
(https://gdl.repository.ssc.lt/en/repository/test-certificates/ ), two
were improperly configured (OV SSL Personal, OV SSL Legal Entity). The
revoked certificates were merely hosted as certificates, not as separate
Web pages using Subscriber certificates, as required by the BRs.

SSC:

We are now updating all DV, OV and EV test certificates, which we should
make available in 24 h from now:

https://gdl.repository.ssc.lt/en/repository/test-certificates/

RS-O2:

Perhaps most concerning of all in this application is that the CPS
indicates the issuance of DVCP/OVCP certificates, except no such audit
has been performed according to Tuvit. The ambiguity regarding much of
the TLS issuance practices, and in particular, the request for the
"Website" trust bits without a corresponding audit for the issuance
practices related to website trust bits (DVCP/OVCP, equivalent
conceptually to the "Webtrust for CAs - SSL Baseline Requirements v2.0"
documentation), give me strong concern.

SSC:

As discussed earlier ETSI audits are cumulative, meaning that higher
level audit (e.g. EV) assumes conformance to all lower level
requirements (e.g. DV, OV).

RS- O3:

Remediation of this would be a significant undertaking to update the CP
and CPS to provide appropriate guidance and statements as to the
adherence to the BRs and Mozilla Policy. In many cases, it simply
incorporates by reference, which concerns me that SSC may not have
properly implemented controls to actually follow the BRs.

SSC:

Following is the collection of 0 CP statements that might have been
treated as references:

-.

Following is the collection of 4 CPS statements that might have been
treated as references:

3.2.
Verification of identity information for issuing EVCP and EVCP+
certificates is conducted according to [CABF-EV].

3.2.2 Authentication of organization identity
For certificates issued under EVCP and EVCP+ certificates verification
of Applicant’s Identity, including its assumed name, legal, physical and
operational existence and Domain Name ownership is performed according
to the requirements indicated in [CABF-EV].

4.1 Certificate Application
For EVCP and EVCP+ certificates extra verification measures are taken as
defined in [CABF-EV] to ensure the Subscriber's legal [27], physical
[28] and operational existence. Proof of representation and authority
to act on behalf of the Applicant has to be demonstrated in order to
authenticate the signatures on EVCP and EVCP+ certificate application
forms[29].

[27] The RA checks that the organization is the legal holder of its name
by mapping the information provided in the Extended Validation
certificate application with information of official Government
Registers (Legal entity DB, TAX payers DB, Social Security DB) that
confirms the existence of the organization.
[28] The RA checks the official postal address of the applicant along
with Applicant's main business phone number.
[29] In case a technical contact is also the certificate requester with
no approval rights, the certificate application form has to be signed by
an authorized certificate approver, whose signature has to be verified.
The RA communicates with the Certificate signer by phone to ensure
validity of authorization. The RA may also communicate with the
Certificate signer by postal mail sent to the applicant's place of business.

9.6 Representations and warranties
SSC GDL CA by issuing EVCP and EVCP+ certificates makes the EV
Certificate Warranties to Subscribers, Subjects, Application Software
Suppliers and Relying parties that it has followed the requirements of
[CABF-EV] in issuing, managing and verifying the accuracy of EVCP and
EVCP+ certificates.

ETSI TS 102 042 states:

ETSI - Electronic Signature and Infrastructure (ESI) - includes in the
present document provisions consistent with the requirements for issuing
Extended Validation Certificates (EVC), as specified in the above
mentioned CAB Forum EVC Guidelines (EVCG [16]) as well as Publicly
trusted TLS/SSL certificates, as specified in the mentioned CAB Forum
PTC guidelines (BRG [19]) As a consequence, EVC and PTC issued by CAs
operating in compliance with the EVC and PTC related provisions as
indicated in the present document can be assessed as meeting the
requirements specified by the CAB Forum in their EVCG [16] and BRG [19]
plus recognised good practice for CA's issuing certificates.

Besides, as a member of CAB Forum SSC maintains a procedure that ensures
timely update of policy/operations and associated documents including
CP/CPS in a timely manner.

RS-O4:

I would encourage SSC to review the past several CA inclusion requests,
including the most recent of WISeKey, and the areas of concern flagged
there, many of which are applicable here. Similarly, examining the CP
and CPS in the context of the CA/Browser Forum's Baseline Requirements,
v1.3.0 will provide ample guidance as to the expected assertions, many
of which were absent or incorporated by reference, which give
significant concern.

SSC:

Thank you for your time and recommendations. We've carefully reviewed
the past CA inclusion requests (SECOM, WoSign, KIR S.A., LuxTrust) and
have identified following items for further consideration: M-WK2, M-WK5,
B-WK1, B-WK5, B-WK6, Q-WK10, Q-WK11.

Thanks,
Reply all
Reply to author
Forward
0 new messages