Hi, Watson ,
Please see in lines.
[email protected] 在 2021年8月5日 星期四下午1:20:15 [UTC+8] 的信中寫道：
> On Tue, Aug 3, 2021 at 8:00 AM Ben Wilson <[email protected]> wrote:
> >
> > Chunghwa Telecom
> >
> > This is to announce the beginning of the public discussion phase of the
> Mozilla root CA inclusion process for Chunghwa Telecom’s request to include
> the HiPKI Root CA - G1 Certificate in the root store as an TLS/SSL-only
> root CA. See
> https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps
> 4 through 9).
> >
>
> I have a number of questions related to statements in the CP and CPS
> that hopefully can be cleared up. There's a number of small
> infelicities,likely due to my misunderstanding or ignorance.
>
> The CP refesr to security levels from 1 to 4. However any CA can
> issue a certificate for any domain name: is there a minimum security
> level CAs will be obliged to meet for signing?
First of all, we have defined 4 identity assurance levels (IAL), not
security levels, in HiPKI CP like NIST SP800-63, and each subscriber
certificate will have a CP OID defined by CABF and may have an identity
assurance level(IAL) OID arc in it.
>From HiPKI CP, Section 1.2:
If any part is not regulated under the documents of CA/Browser Forum, the
rule of assurance level 1 is applicable for CAs that issue DV TLS/SSL
certificates, and the rule of assurance level 3 is applicable for CAs that
issue EV and OV TLS/SSL certificates. For CAs that issue self-signed,
self-issued, and cross-certified certificates, the rule of assurance level
4 is always applicable.
As you can see in Sections 3.2.2 and 3.2.5 of HiPKI CP, we will made the
authentication of organization identity and validation of authority prior
to the issuance of any certificates. In practice, CP OIDs and certificate
profile are set for each CA as a mean of asserting compliance with our
HiPKI CP.
>
>
> In section 6.6. of the CP 2 it's stated that level 4 means Webtrust
> security practices must be followed, but then in section 8 it says
> that a compliannce audit with Webtrust must be conducted for every
> Level 2 or higher CA. These seem at odds to me.
Thank you for your comments, we found that a paragraph was missed in
Section 6.6.2 after translation from original and a typo was happened in
Section 8.
Here is the changes to these two paragraph:
(a) In Section 6.6.2,
We will add “(4) CAs shall perform security management controls that comply
with WebTrust for CA” in the right column corresponding Assurance Level 1
to 3.
(b) In Section 8,
“The CA that issues assurance level 2 or higher certificates ...”
will be changed to
“The CA that issues assurance level 1 or higher certificates…”
>
>
> For the CPS of the intermediate CA I see that section 3.2.5.2 lists a
> number of ways to validate domain control. I'd like to understand what
> risk assessment has been done of each of these methods, some of which
> seem more amenable to automation than others. There doesn't seem to be
> any statement about automating this process.
We have done a risk assessment, including keep pay attention to the
discussions in Validation Subcommittee of the Server Certificate Working
Group of CA/B Forum. These methods are acceptable methods that we think we
can bear the risks after evaluation, and surely CAs need to be equipped
with some verification mechanisms to prevent malicious behavior and other
requests. As for domain control methods, of course we will continue to work
hard to make these methods more automated in our RA system, and we have
more resource to support than other CAs because our company is a domain
name registrar of the base domain name and a telecommunications company as
well. I think these designs are depends for each CAs where BR didn’t ask
CAs to mention this and it’s real hard to do so by wording in fact.
> Section 4.2.1.1 is a bit
> funny: I agree it's the right result to get the applicant to fix their
> busted CAA record, and after confirming its correct issue the EV cert
> (assuming all other checks went through) but it does seem a bit funny
> to me in the way its worded.
This is a bad case, and the sentences below will be deleted in our CPS.
“If the DNS resource record of CAA exists, and has not named HiPKI EV TLS
CA as the CA to authorize the issuance of the EV TLS/SSL certificate, HiPKI
EV TLS CA will deem that the certificate application agrees to authorize
HiPKI EV TLS CA to issue the EV TLS/SSL certificate for that complete
domain name, and require the subscriber to visit the DNS for updating the
DNS resource record of CAA, in order to have HiPKI EV TLS CA included in
the record, and the EV TLS/SSL certificate will be issued afterwards.”
Thanks again for your comments, which help us a lot.
Li-Chun
Chunghwa Telecom Co., Ltd.
>
>
--
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/95365183-9119-428a-b736-98b306176c1bn%40mozilla.org.
