Closed Bug 408949 Opened 17 years ago Closed 14 years ago

Add Hongkong Post Root Certificates

Categories

(CA Program :: CA Certificate Root Program, task)

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: stephen_choy, Assigned: kathleen.a.wilson)

References

Details

(Whiteboard: In Firefox 3.6.2)

Attachments

(7 files, 1 obsolete file)

a Bank-Cert (Personal) certificate from LDAP
1.01 KB, application/octet-stream
Details
Completed Information Gathering Document
115.00 KB, application/msword
Details
Completed Information Gathering Document
89.38 KB, application/pdf
Details
Sample server certificate
965 bytes, application/x-zip-compressed
Details
Subordinate CA certificate for signing server certificates
919 bytes, application/x-zip-compressed
Details
WebtrustCA-2016.pdf
124.86 KB, application/pdf
Details
WebTrust-BR-2016.pdf
648.95 KB, application/pdf
Details 
User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: 

This is an enhancement request to include the Root Certificates of the Hongkong Post Certification Authority into Mozilla's default set of root certificates, and to enable the trust-bits for SSL verification.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.



CA Name: Hongkong Post Certification Authority
Website: http://www.hongkongpost.gov.hk/index.html

Hongkong Post CA is a recognized CA under the law of Hong Kong Special Administrative Region (HKSAR) of China, and has been issuing digital certificates, under the brand name "e-Cert" to individuals and organisations of HKSAR since January 2000.  [https://secure1.info.gov.hk/ogcio/eng/caro/esub41.htm].

The Root certificate is called "Hongkong Post Root CA 1", which has only one direct subordinate, "Hongkong Post e-Cert CA 1". "Hongkong Post e-Cert CA 1" is the signer key and is used to issue different types of recognized e-Cert to individuals and organisations.  In particular, the Hongkong Post e-Cert (Server) certificate is for SSL server certificate.

Audit Type (WebTrust, ETSI etc.): WebTrust
Auditor:  PricewaterhouseCoopers
Auditor Website: http://www.pwc.com/
Audit Document URL(s): http://cert.webtrust.org/SealFile?seal=125&file=pdf


Root Certificate Details
------------------------
Certificate Name: Hongkong Post Root CA 1
  This root certificate has only one direct subordinate, "Hongkong Post e-Cert CA 1"
Certificate HTTP URL (on CA website): 
  http://www.hongkongpost.gov.hk/product/download/root/img/smartid_rt.cacert
Version: X.509v3
SHA1 Fingerprint: D6:DA:A8:20:8D:09:D2:15:4D:24:B5:2F:CB:34:6E:B2:58:B2:8A:58
MD5 Fingerprint: A8:0D:6F:39:78:B9:43:6D:77:42:6D:98:5A:CC:23:CA
Modulus Length (a.k.a. "key length"): 2048
Valid From (YYYY-MM-DD): 2003-05-15
Valid To (YYYY-MM-DD): 2023-05-15
CRL HTTP URL: N/A
LDAP URL: ldap://ldap1.hongkongpost.gov.hk/cn=Hongkong Post Root CA 1,o=Hongkong Post,c=HK
OCSP URL: N/A
Class (domain-validated, identity-validated or EV): identity-validated and domain-validated
Certificate Policy URL: http://www.hongkongpost.gov.hk/product/cps/index.html
CPS URL: http://www.hongkongpost.gov.hk/product/cps/index.html
Requested Trust Indicators (email and/or SSL and/or code): SSL


Certificate Name: Hongkong Post e-Cert CA 1
  The signer key for different types of end-entity e-Cert certificates.
Certificate HTTP URL (on CA website):
  http://www.hongkongpost.gov.hk/product/download/root/img/smartid_ca.cacert
Version: 3
SHA1 Fingerprint: 0A:51:EE:71:01:B5:35:AB:C9:F3:94:14:A9:3C:76:E7:DC:76:8C:7B
MD5 Fingerprint: B1:F0:A3:09:31:09:59:51:37:98:9E:3C:C3:5C:4F:F5
Modulus Length (a.k.a. "key length"): 2048
Valid From (YYYY-MM-DD): 2003-05-15
Valid To (YYYY-MM-DD): 2013-05-15
CRL HTTP URL: http://crl1.hongkongpost.gov.hk/crl/eCertCA1CRL1.crl
OCSP URL: N/A
Class (domain-validated, identity-validated or EV): identity-validated and domain-validated
Certificate Policy URL: http://www.hongkongpost.gov.hk/product/cps/index.html
CPS URL: http://www.hongkongpost.gov.hk/product/cps/index.html
Requested Trust Indicators (email and/or SSL and/or code): SSL
LDAP repository: ldap://ldap1.hongkongpost.gov.hk
Isn't this a duplicate of bug 373537 ?
This is the formal submission from Hongkong Post.
Yes, it is formal submission. So, bug 373537 is duplicated
How's the status of this issue?
Is there any update to the issue?
Summary: Hongkong Post Root Certificates inclusion → Add Hongkong Post Root Certificates
For your information, the Hongkong Post e-Cert CA has attained the Webtrust certification status. For information, you can refer to the following link for details:

https://cert.webtrust.org/ViewSeal?id=125

Please do not hesitate to let us know if there is anything further that you would need for incorporating the CA cert into Mozilla. Thanks in advance.

Please let me know if there is anything that you need further for approving the request. Thanks in advance.

Accepting this bug and putting it into the queue with the other CA requests. At present I cannot say for certain when we will be able to process this.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Is there any update regarding the application? I would be more than anxious to know about the status so far.

In case there is further information that you would need from us, please let us know.
Would that be possible for us to know about the status of the application? I would like to make sure that things are moving in the pipeline.

In case there is anything further that you would need from us, please do not hesitate to let us know. Thanks in advance.
I would like to let you know that the Hongkong Post e-Cert CA is a recognised CA in Hong Kong under the Electronic Transaction Ordinance. We have relying parties supporting various functions in e-government and e-commerce applications.

Due to the changes to the CA certificate verification routine on Firefox 3.0, it is causing a number of issues from the user experience perspective.

This case was first submitted by Dec 18, 2007 with all of the requested information provided for approval. I would sincerely hope that the Mozilla Foundation can help reviewing the application. In case there is additional information that you need for moving forward, please do not hesitate to let us know. Thanks in advance.
Hi Alex, have you also submitted similar requests to Opera and Apple?

http://www.opera.com/docs/ca/
http://www.apple.com/certificateauthority/ca_program.html
Accepting this bug so I can do the information gathering and verification phase.

Kathleen
Assignee: hecker → kathleen95014
Attached file Initial Information Gathering Document (obsolete) — 
Attached is the initial Information Gathering document which summarizes the information that has been gathered and verified.  The text highlighted in yellow in the attached document shows the information that needs to be clarified. I will summarize my questions below.

Please note that only root certificates are included in Mozilla's NSS database, so the information gathering/verification is being done for the root “Hongkong Post Root CA 1”.

1) Are there subordinate CAs under the “Hongkong Post e-Cert CA 1” subordinate CA? If so, please provide general cert hierarchy and description.  

I believe the cert hierarchy looks like the following, but please confirm/correct. Also, I wasn’t sure if e-Cert CA 1 issued all end-entity certs directly, or if there are subordinate CAs for each type of cert.

Hongkong Post Root CA 1
 -> Hongkong Post e-Cert CA 1
      -> Hongkong Post e-Cert (Personal)
      -> Hongkong Post e-Cert (Organisational)
      -> Hongkong Post e-Cert (Encipherment)
      -> Hongkong Post e-Cert (Server)
      -> Hongkong Post Bank-Cert (Bank of East Asia-Corporate) certificate
      -> Hongkong Post Mobile e-Cert (Personal) certificate
      -> Hongkong Post Mobile e-Cert (Organisational) certificate
      -> Hongkong Post Mobile e-Cert (Server) certificate
      -> Hongkong Post Bank-Cert (Shanghai Commercial Bank-Personal) certificate
      -> Hongkong Post Bank-Cert (Shanghai Commercial Bank-Corporate) certificate

2)  In regards to: “HKPCA operations have been outsourced to E-Mice Solutions”
Which CAs does this apply to?

3) For testing purposes, please provide a URL to a website whose certificate chains up to this root. 

Thanks,
Kathleen
The cert hierarchy 

Hongkong Post Root CA 1
 -> Hongkong Post e-Cert CA 1
      -> Hongkong Post e-Cert (Personal)
      -> Hongkong Post e-Cert (Organisational)
      -> Hongkong Post e-Cert (Encipherment)
      -> Hongkong Post e-Cert (Server)
      -> Hongkong Post Bank-Cert (Bank of East Asia-Corporate) certificate
      -> Hongkong Post Mobile e-Cert (Personal) certificate
      -> Hongkong Post Mobile e-Cert (Organisational) certificate
      -> Hongkong Post Mobile e-Cert (Server) certificate
      -> Hongkong Post Bank-Cert (Shanghai Commercial Bank-Personal) certificate
      -> Hongkong Post Bank-Cert (Shanghai Commercial Bank-Corporate) certificate

is correct.  e-Cert CA 1 is the signer certificate.  

The public LDAP Repository: ldap1.hongkongpost.gov.hk, base: c=hk
an e-Cert to prove the hierarchy.
For testing purposes, please use the following website:
https://www.hongkongpost.gov.hk/
Stephen, I understand that Hongkong Post issues certificates that can be used for email signing (personal/organisational), but you didn't specify to enable that trust indicator. Was that intended?
Sorry, my personal comment comment #17 is not correct.
The information about LDAP should be correct.

Should the official give the reply?
Hi,

Thank you all for your interest in this request. 

I need Stephen Choy or another representative of Hongkong Post to provide the official response to items #1 and #2 of comment #16. For item #3, we can use the url that Stephen Chu provided. 

In regards to comment #20, I will need Stephen Choy or another representative of Hongkong Post to request that the email trust bit also be enabled, if that is what they want. In making this decision, please note that if the email trust bit is enabled we need to ensure that the CPS complies with section 7 of http://www.mozilla.org/projects/security/certs/policy/ "for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf"  I did not find this in Hongkong Post's CPS.

Thanks,
Kathleen
Thank you for Kathleen's questions.  Please find our responses below:
 
Regarding to Comment #16 Item #1 & #2,
1) Are there subordinate CAs under the "Hongkong Post e-Cert CA 1" subordinate CA? If so, please provide general cert hierarchy and description.
 
The certificate hierarchy is:
 
Hongkong Post Root CA 1
 -> Hongkong Post e-Cert CA 1
      -> Hongkong Post e-Cert (Personal)
      -> Hongkong Post e-Cert (Organisational)
      -> Hongkong Post e-Cert (Encipherment)
      -> Hongkong Post e-Cert (Server)
      -> Hongkong Post Bank-Cert (Bank of East Asia-Corporate) certificate
      -> Hongkong Post Bank-Cert (Shanghai Commercial Bank-Personal) certificate
      -> Hongkong Post Bank-Cert (Shanghai Commercial Bank-Corporate) certificate 
 
Hongkong Post e-Cert CA 1 issued all end-entity certs directly and there is no subordinate CA under Hongkong Post e-Cert CA 1.
 
2)  In regards to: "HKPCA operations have been outsourced to E-Mice Solutions". Which CAs does this apply to?
 
Hongkong Post has appointed E-Mice Solutions (HK) Limited ("E-Mice") as its agent to operate the e-Cert services related to "Hongkong Post Root CA 1" and all its subordinate CA certificates and end-entity certificates.
 
 
Regarding to Comment #20,
 
the personal/organisational certificates issued by Hongkong Post CA support email signing, if email address is provided by the applicant in the application of certificate. Hongkong Post CA will verify the name of the subscriber and the organisation name for organisational certificates. Although Hongkong Post CA will not verify the email account associated with the email address in the certificate that is owned by the subscriber, the email recipient can check the certificate of the sender to identify the subject name, and organisation name for organisational certificate, of the email signer to consider to trust the email or not. Therefore, it is also our intention to enable the trust indicator for email signing for the personal/organisational certificates, which are generated by the same Hongkong Post CA root certificate, if that meets Mozilla CA certificate policy.
Thank you for the clarification of cert hierarchy and operations of this root.

Enabling the email trust bit means that I must find text in the CPS or related document that demonstrates: "the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf" as per section 7 of http://www.mozilla.org/projects/security/certs/policy/.

Comment #23 states: "Although Hongkong Post CA will not verify the email account associated with the email address in the certificate that is owned by the subscriber, the email recipient can check the certificate of the sender to identify the subject name, and organisation name for organisational certificate, of the email signer to consider to trust the email or not."

I do not see how this meets the Mozilla CA certificate policy.

I believe the options for moving forward with this request are:
1) Do not request that the email trust bit be enabled in Mozilla
or
2) Update the CPS and practices to include verification of email address for certs to be used for signing/encryption.

Please let me know how you would like to proceed.

Thanks,
Kathleen
Thank you for your response and clarification.  In order to move forward, please proceed with the request for enabling the SSL trust bit for Hongkong Post Root CA 1 certificate.  Inform us if you need further information to proceed with this request.

Thanks,
Stephen Choy
I have added your request to the Pending list at
http://www.mozilla.org/projects/security/certs/pending/
Please verify the information. 

I noticed that the CRL for end-entity e-Certs does not load correctly in Firefox.
http://crl1.hongkongpost.gov.hk/crl/eCertCA1CRL2.crl
results in the following error in Firefox:
The application cannot import the Certificate Revocation List (CRL).
Error Importing CRL to local Database. Error Code:ffffe095
Please ask your system administrator for assistance.

Do you happen to have the CDP (CRL distribution point) extension flagged as "critical" for this CRL?
Mozilla browsers do not presently implement the CrlDP extension because it is patented. So, Mozilla browsers do not presently honor CRLs with critical CrlDP extensions.

Thanks,
Kathleen
Yes, the CRL distribution point extension of http://crl1.hongkongpost.gov.hk/crl/eCertCA1CRL2.crl is flagged as "critical".  We note that this CRL cannot be loaded into the local database of Firefox as you mentioned, but it seems that the server certificate of the https web site can be verified correctly by the browser, and the "lock icon" is displayed without flagging any error.  Thus, despite the issue of loading the CRL in the local database, is it possible to fulfill our request to enable the SSL trust bit for Hongkong Post Root CA 1 certificate?

Thanks,
Stephen
The Information Gathering phase of this request is complete, with the following two items of note:

1)  The operation of this root and all of its subordinate CAs has been outsourced to E-Mice Solutions Limited. This information is provided in the CPS and Management Assertions. The WebTrust audit includes both E-Mice operations and Hongkong Post operations.

2)  The CRL for end-entity e-Certs does not load correctly in Firefox.
http://crl1.hongkongpost.gov.hk/crl/eCertCA1CRL2.crl
results in Error Code:ffffe095
The NSS team is now working on implementing the code that will understand and use the CIDP. There will also have to be changes in Firefox to make this work. I don't currently know of the schedule for this work to be completed, but it may be at least six months.
Would it be reasonable for you to remove the critical flag from the CRL?
In the meantime, we can proceed to the public discussion phase.
Attachment #340017 - Attachment is obsolete: true
This request is ready for the public discussion phase, and will be prioritized and scheduled as per https://wiki.mozilla.org/CA:Schedule
Assignee: kathleen95014 → hecker
Whiteboard: Information confirmed complete
Reference comment #28, item 2:  Is this a bug?  If so, what is the bug number?
Yes, see bug 321755
Thank you for your update on the arrangement.
 
Regarding the critical flag of the CRL distribution point extension, it has been set to critical, and this design has been in use for years.  For the time being, it is not feasible to remove the critical flag from the CRL.
Understand that this request has completed information gathering document and put into public discussion phase. According to schedule, it will be evaluated and priortized by Mozilla Foundation.

Would that be possible for us to know about the status of the application?
Happy New Year! Is there any update on this issue? I would be more anxious to
know about the status so far such that I can plan ahead the related activities in 2009.
https://wiki.mozilla.org/CA:Schedule has been converted into a queue. I will try to introduce a request into public discussion each week. Accordingly, this request should enter public discussion in a couple of weeks.

In the meantime, would you please see the updated info in regards to the critical CIDP?
https://wiki.mozilla.org/CA:Problematic_Practices#CRL_with_critical_CIDP_Extension

Please consider:
"Our recommendation is to not put critical CIDP extensions into full CRLs, and to make full CRLs available for download when practical."
Thank you for your update.

Exactly, our design of full CRL is inline with your recommendation. Our full CRL (http://crl1.hongkongpost.gov.hk/crl/eCertCA1CRL1.crl) does not carry the CIDP extensions.
Converting from msword format to pdf.

I plan to put this request into public discussion in two weeks as per the queue
shown at https://wiki.mozilla.org/CA:Schedule
I am now opening the first public discussion period for this request from Hongkong Post to add the Hongkong Post Root CA 1 root certificate to Mozilla.

Public discussion will be in the mozilla.dev.tech.crypto newsgroup and the
corresponding dev-tech-crypto@lists.mozilla.org mailing list.

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-tech-crypto

Please actively review, respond, and contribute to the discussion.
Man Ho, I have one questions concerning your application:

How exactly do you perform domain control or domain ownership validation according to the CPS section 3.1.1.4 e-Cert (Server) certificates, c) ?

Thank you!
Thanks for your question.

We will check that the owner of the domain name is the same as the one in the Business Registration of Hong Kong via the WHOIS service, e.g. for .com.hk and .hk...etc, we'll use WHOIS of Hong Kong Domain Name Registration Co. (https://www.hkdnr.hk/whois/whois.jsp), for other domains, checkdomain.com or networksolutions.com will be used.

The validity of such domain name will also be checked.
Thank you! I believe that this is not an automated process and you perform the validation manually, correct?
Yes, you're correct. We do it manually.
Man Ho, thank you and good luck!
The public comment period for this request is now over. 

This request has been evaluated as per sections 1, 5 and 15 of the official CA policy at

 http://www.mozilla.org/projects/security/certs/policy/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

To summarize, this assessment is for the request to add a new root CA certificate for Hongkong Post Root CA 1. 

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by Hongkong Post, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

There were some concerns expressed in the comment period regarding Hongkong Post’s use of both a full CRL and a partitioned CRL. Currently Firefox handles full CRLs, but not partitioned CRLs. Hongkong Post maintains a full CRL that works correctly when manually loaded into Firefox. The end-entity certs chaining up to this root include a cRLDistributionPoints extension that references the URL for a partitioned CRL. The end-entity certs chaining up to this root work in Firefox today, and people who want revocation checking can import the full CRL to enable it. In this respect they are no different than any other non-EV CA not supporting OCSP. Recommendations have been provided in the discussion thread in regards to how Hongkong Post can avoid the potential problems in the future. Hongkong Post is strongly encouraged to continue investigation into this. However, this concern is not considered a show-stopper in regards to inclusion of this root.

Section 6 [Relevancy and Policy]. Hongkong Post appears to provide a service relevant to Mozilla users: It is a national government CA under the law of Hong Kong Special Administrative Region of China.

Policies are documented in the documents published on their website and listed in the entry on the pending applications list; the main document of interest is the Certificate Practice Statement for e-Certs, which is provided in English.

http://www.hongkongpost.gov.hk/product/cps/ecert/img/cps_en23.pdf

Section 7 [Validation]. Hongkong Post appears to meet the minimum requirements for subscriber verification, as follows:

* Email: Not applicable. Hongkong Post is not requesting that the email trust bit be enabled.

* SSL: For SSL certs, Hongkong Post verifies the Subscriber Organization and requires that the Subscriber Organization prove the ownership of the domain name to be identified in the e-Cert certificate. Hongkong Post checks that the owner of the domain name is the same as the one in the Business Registration of Hong Kong via the WHOIS service. In the case that an e-Cert is issued with a validity of 2 years, Hongkong Post will verify again the existence of the Subscriber Organization and the ownership of the domain name identified in the certificate, approximately at the end of the first year of the validity period. 

* Code: Not applicable. Hongkong Post is not requesting that the code signing trust bit be enabled.

Section 8-10 [Audit]. Section 8-10 [Audit]. 
* Hongkong Post has appointed E-Mice Solutions (HK) Limited as its agent to operate the e-Cert services related to this root and all its subordinate CA certificates and end-entity certificates. This information is provided in the CPS and Management Assertions. The WebTrust audit includes both E-Mice operations and Hongkong Post operations.
* Hongkong Post and E-Mice have undergone WebTrust CA audits by PricewaterhouseCoopers. The audits are current, and the most recent audit statement from February, 2009, is posted on WebTrust.org.

Section 13 [Certificate Hierarchy]. This root, Hongkong Post Root CA 1, has only one subordinate, Hongkong Post e-Cert CA 1, which issues different types of e-Certs to individuals and organizations.  Only the websites trust bit has been requested at this time.

Other: Hongkong Post issues its CRLs 3 times per day.

Potentially problematic practices: There are two known potentially problematic practices associated with Hongkong Post Root CA 1 and its associated CA hierarchy. They are:
1) The operation of this root and its subordinate CA has been outsourced to E-Mice Solutions Limited. See details above.
2) Hongkong Post provides both a full CRL and a partitioned CRL. See details above.

Based on this assessment I recommend that Mozilla approve this request to add the Hongkong Post Root CA 1 Certificate Authority root certificate to NSS.
I want to attempt to clarify (or seek clarification) on the full/partial 
CRL issue.  IMO, the problem is not that "Hongkong Post provides both a 
full CRL and a partitioned CRL", but rather (as I understand it) that the 
CrlDP extensions in the certs they issue only contain distribution points 
for the partial CRLs and not for the full CRL.  That makes the full CRL
undiscoverable.  

(Aside: CRLs update 3x per day!  Just imagine all those FF users hitting 
that server multiple times each day!  Clearly we need a minimum time bound
between successive attempts to fetch CRLs.)
Nelson: Yes, your description is accurate. Hongkong Post includes only the URL for the partitioned CRL in its CRLDP extensions, so the URL for the full CRL is not discoverable via the CRLDP mechanism (though it could be found out-of-band and hand-loaded by knowledgable users). As noted in my posts to m.d.t.crypto, in anticipation of CRLDP support in Firefox et.al., Hongkong Post should correct this, e.g., by including an alternate distribution point referencing the URL for the full CRL. However I don't consider that a showstopper for approval at this time, and am willing to give HKP the opportunity to correct the problem prior to our shipping Firefox, et.al., with CRLDP support.
To Kathleen: Thank you for your work on this request.

To the representatives of Hongkong Post: Thank you for your cooperation and your patience.

To all others who have commented on this bug: Thank you for volunteering your time to assist in reviewing this CA request.

I have reviewed the summary and recommendation in comment #44, and on behalf of
the Mozilla project I approve this request from Hongkong Post to add the following root certificates to NSS, with trust bits set as indicated:

* Hongkong Post Root CA 1 (SSL use only)

My approval is subject to the caveat in comment #46 (and elsewhere), that prior to the future implementation of CRLDP support in NSS (and thus in Firefox an other Mozilla-based products), Hongkong Post needs to make the full CRL for its certificates discoverable via CRLDP, since support for partitioned CRLs will almost certainly not be present in NSS at the time CRLDP support is first implemented.

Kathleen, I'm re-assigning this bug to you for the final steps. Could you please do the following:

1. File the necessary bugs against NSS and PSM.
2. Mark the PSM bug as dependent on the NSS bug.
3. Mark this bug as dependent on the PSM bug.
4. When those bugs are complete, change the status of this bug to RESOLVED FIXED.

Thanks in advance!
Assignee: hecker → kathleen95014
Whiteboard: Information confirmed complete → Approved
Frank, we may have CRLDP support before the end of the month.  (No promises)
The remaining problem to be solved is the problem of repetitive fetches of 
CRLs that we reject upon download, the very problem that this CA's CRLs will
present.

So, the window of opportunity for HKP "to correct the problem prior to our shipping Firefox, et.al., with CRLDP support" may be very short.
Frank, 
I'm not sure you saw my previous comment, but let me put it another way.

I understand your desire is to see CRLDP fetching go into FF ASAP.
We are very close to having a solution that will work adequately for all CAs 
whose CDP extensions include a URL for a full CRL.  There is a lot more work 
to be done to be ready for a CA whose CDPs bear ONLY partitioned CRLs.  

So, IMO, the choice you have today is:
a) Bar CAs that advertise only partitioned CRLs in their certs from admission
to the product, but get the CRLDP code in very soon, or 
b) Admit such CAs now, and delay the introduction of CRLDP fetching.
If the inclusion of a CA would delay the support for CRL fetching I would object. We've long enough waited to for this to happen and I'm very glad to see the patches being applied for CRLDP. Please lets not delay it any further.
My understanding (please correct me if I’m wrong) is that there are two action items that Hongkong Post needs to complete before inclusion of this CA can proceed.

1) Hongkong Post needs to make the full CRL for its certificates discoverable via CRLDP.

2) Hongkong Post needs to reduce the frequency of updating the full CRL from 3 times per day to 1 time per day, except when there is a revocation.

Other:  It sounds like there should be a bug created to track the issue of having CRLs served up multiple times each day. Eg. “need a minimum time bound between successive attempts to fetch CRLs” or “the problem of repetitive fetches of CRLs that we reject upon download”. Would someone knowledgeable about what this means please create the bug? I expect that some serious thought needs to be put into this before a solution is implemented.
(In reply to comment #49)
> Frank, 
> I'm not sure you saw my previous comment, but let me put it another way.
> I understand your desire is to see CRLDP fetching go into FF ASAP.
> We are very close to having a solution that will work adequately for all CAs 
> whose CDP extensions include a URL for a full CRL.  There is a lot more work 
> to be done to be ready for a CA whose CDPs bear ONLY partitioned CRLs.  
> So, IMO, the choice you have today is:
> a) Bar CAs that advertise only partitioned CRLs in their certs from admission
> to the product, but get the CRLDP code in very soon, or 
> b) Admit such CAs now, and delay the introduction of CRLDP fetching.

If my understanding to CRLDP fetching is correct, the introduction of CRLDP fetching will have impact on our system and network capacity to serve both the partitioned CRLs and the full CRL anyway, regardless of whether Hongkong Post root certificate is included in FF. In view of this, we definitely have to look into this impact and ensure our system and network is able to support the increased traffic of accessing our CRLs. I believe it shouldn't be a major issue or concern to this matter because the power of hardware and internet bandwidth is much advance nowadays.

On the other hand, we are also seriously considering to replace the CRLDP in our EE certificates by our full CRL. But please understand that Hongkong Post issued over 1 million of EE certificates and majority with a maximum validity period of 3 years. For the SSL certificates, the maximum validity is 2 years.

I don't quite understand why we need to reduce the frequency of updating the full CRL because it doesn't seem to be relevant to CRLDP fetching. I believe more frequent update of CRL is better to the end user.
(In reply to comment #52)
> I don't quite understand why we need to reduce the frequency of updating the
> full CRL because it doesn't seem to be relevant to CRLDP fetching. I believe
> more frequent update of CRL is better to the end user.

How big are your (full) CRLs? Too frequent not only would put a burden on your infrastructure but also delay access to sites and email by the client. I think that an update frequency of every 12 -48 hours to be reasonable. Also upon revocation CRLs are usually updated too.
(In reply to comment #53)
> (In reply to comment #52)
> > I don't quite understand why we need to reduce the frequency of updating the
> > full CRL because it doesn't seem to be relevant to CRLDP fetching. I believe
> > more frequent update of CRL is better to the end user.
> How big are your (full) CRLs? Too frequent not only would put a burden on your
> infrastructure but also delay access to sites and email by the client. I think
> that an update frequency of every 12 -48 hours to be reasonable. Also upon
> revocation CRLs are usually updated too.

Our full CRL is about 110kB and the largest partitioned CRL is about 57kB.

What I mean is, in our case, upon revocation CRLs are updated by 3 times per day. So, in fact, more frequent update is preferrable. However, if the implementation of CRLDP fetching depends on the "Next update" attribute of our CRLs, it won't actually fetch so frequent because it is set to one month after the issuing date of CRL.
With update frequency we mean usually until next update. One month is too long, I suggest to reduce it to about 48 hours perhaps. 

Note to Kathleen: We should better ask for the nextUpdate advertised in the CRL instead of when the CRLs are updated. In this case a user might not fetch the CRL for one month - that's a long time these days.
One month may be a long time these days, but still work fine in our market. Well, of course, I'd believe that software developers traditionally ignore such attribute in the CRL and decide on their own update frequency. I'm just wondering: Should the decision of how long this nextUpdate attribute in the CRL be left to the CA rather than mandated by Mozilla? And if the current setting does not cause delay access to sites and email by the client for Mozilla software, should we separate this issue from the request and continue?
Do the CRL issues need to be resolved before I can create the bug for NSS inclusion?

The issues appear to be:

1) Make the full CRL for Hongkong Post certificates discoverable via CRLDP.
Comment #52: …we are also seriously considering to replace the CRLDP in our EE certificates by our full CRL. But please understand that Hongkong Post issued over 1 million of EE certificates and majority with a maximum validity period of 3 years. For the SSL certificates, the maximum validity is 2 years.

Does the action item to make the full CRL discoverable via CRLDP have to be completed before inclusion in NSS?  

2) nextUpdate in the Hongkong Post CRLs is one month 

Based on what I’ve seen, it is usually 24 to 48 hours. I have also seen 3 days and one week. Is there a requirement in the Mozilla policy about what this should be? What is acceptable to Mozilla?

Does the CRL nextUpdate have to be reduced before inclusion in NSS?
(In reply to comment #57)
> Do the CRL issues need to be resolved before I can create the bug for NSS
> inclusion?

IMO, yes.  The request to add the cert to NSS should come only after all 
impediments have been removed.
Creation of the NSS inclusion bug is on hold, pending resolution to the concerns about CRLs. 

Please update this bug to indicate when solutions have been implemented.
For some operational reasons, the shortest period of nextUpdate in Hongkong Post CRLs could be 72 hours. Is it acceptable for this request?
In reply to comment 60, do your servers that serve the CRLs have enough
bandwidth to handle the demand that will be created by such short periods?
Nelson, there are CAs which have shorter periods. I guess Mr. Ho meant if it's short enough and I believe it is. Longer updates would be less useful when considering that no OCSP exists for now, right?
Dears, thank you all for your patient. I have only one outstanding question at the moment - and I'm hoping that is the last one - to finalize everything on my side. 

Hongkong Post CA issues certificates to person, organization unit or server under the same root. If for the purpose of this request, we just change the CRLDP of server certificate (i.e. the SSL certificate) to the full CRL (but not the others), will it suffice to resolve the issue #1?
> Hongkong Post CA issues certificates to person, organization unit or server
> under the same root. If for the purpose of this request, we just change the
> CRLDP of server certificate (i.e. the SSL certificate) to the full CRL (but 
> not the others), will it suffice to resolve the issue #1?

Yes, I believe so. This request is only for the enablement of the websites trust bit, so I believe that only the CRL corresponding to the server certificates is relevant.
(In reply to comment #62)
> Nelson, there are CAs which have shorter periods. I guess Mr. Ho meant if it's
> short enough and I believe it is. Longer updates would be less useful when
> considering that no OCSP exists for now, right?

Sorry for keeping you waiting. It had been a long journey on my side to pursue a shorter period of nextUpdate in Hongkong Post CRLs. There was certain reservation from my side that the period should be set to 72 hours. Notwithstanding we've got sufficient bandwidth and server capacity to support the shorter period of nextUpdate, our relying parties whose systems rely on our certificates raised out their concerns too. I think you'll agree that this change imposed impact on their systems.

Having said that, I'm still holding a view that the period of nextUpdate should be as short as possible and acceptable from an international practice. So, I just wonder what is an acceptable period of nextUpdate provided that other renown CAs, such as Verisign and Thawte, are maintaining a 14-days of nextUpdate in their CRLs. Would 14 days be a de-facto standard?
>> Would 14 days be a de-facto standard?

I don't think so. 14 days is probably the maximum nextUpdate.

This request isn't for enabling EV, but it is worth noting the EV guidlines in regards to this: "CRLs MUST be updated and reissued at least every seven days, and the nextUpdate field value SHALL NOT be more ten days;"
Thanks for your reply. Issuing EV certificate is definitely our next goal in future, but not in this request.

>> CRLs MUST be updated and reissued at least every seven days,
Sure, we currently issue CRLs three times a day. 

>> and the nextUpdate field value SHALL NOT be more ten days
In order to pave way toward our goal for EV, we will set the nextUpdate field value to 10 days.
I'd like to let you know that Hongkong Post has set out a plan for:

1) changing the CRLDP of server certificate (i.e. the SSL certificate) to the full CRL; and

2) setting the nextUpdate field value of the full CRL to 10 days;

tentatively with effect from someday in March 2010.

May I know the tentative schedule for the next release of Firefox with Hongkong Post root certificate included?
Thank you for the update on your plan to resolve the concerns about CRLs.

As per Comment #47 and Comment #59, Creation of the NSS inclusion bug is on hold, pending resolution to the concerns about CRLs.

The NSS bug is where the actual changes to include the root certificate happen. Here’s an overview of the process after the NSS bug is created:

Once the NSS bug is created, within 3 months (depending on developer schedules), a Mozilla representative will create a test build of NSS with the new certificate, and attach nssckbi.dll to the NSS bug. A representative of the CA must then test and provide feedback into the NSS bug.

After the change has been made and tested, the Mozilla representative will check the certificate into the NSS store, and mark the NSS bug RESOLVED FIXED.

At some time after that, various Mozilla products will move to using a version of NSS which contains the certificate. This process is mostly under the control of the release drivers for those products. For Firefox this can take about 2 months.
Whiteboard: Approved → Approved - awaiting resolution of CA CRL issue
Thank you for your explanation on the process of including the Hongkong Post root certificate into the next release of Firefox.

I noticed that Firefox 3.5 has changed its advice to users who visit a SSL encrypted website that is not recognized as being "trusted" by Mozilla.  Specifically, Firefox will:
1.  inform a user that the connection is UNTRUSTED and then assume that he/she would exit the website by clicking the "Get me out of here!" button; 2.  advise the user "Don't add an exception unless you (the user) know there's a good reason why this site doesn't use trusted identification." if he/she elects to proceed; and 3.  finally warn the user that "Legitimate banks, stores, and other public sites will not ask you to do this". if its previous warning is ignored. 

I think you will agree that such forceful warnings have a very negative impact on real websites operated by legitimate organisations such as our customers, including Government departments as well as non-Government entities in Hong Kong.  Given the growing volume of complaints from our legitimate server certificate customers, is there anything that can be done to re-phrase and "tone down" the severity of your warnings?  As you know, we have been discussing our request to include the Hongkong Post root certificate into Mozilla products for a long time, and the outstanding concerns about CRLs are technical in nature rather going to the issue of trustworthiness. 

At the same time, I hope to expedite the overall process for securing "trusted" recognition for the Hongkong Post root certificate by sending you some new server certificates in January 2010, even though mass production will only begin from March 2010.  If I do that, can the release date of Firefox with Hongkong Post root certificate included be advanced to, say, Q1 of 2010?
Man Ho, please note that the connection is not trusted, not the organization or individual running the web sites. As such, I don't think that digital certificates ever say something about trust, rather identify specific parameters spelled out in the certificate.
(In reply to comment #71)
> Man Ho, please note that the connection is not trusted, not the organization or
> individual running the web sites. As such, I don't think that digital
> certificates ever say something about trust, rather identify specific
> parameters spelled out in the certificate.

Eddy, sorry but I can't agree with you on this. In PKI, the role of CA is to ensure the digital certificate holders are really who they are. That's what we call "trust" in PKI context, which is more than some parameters spelled out in the certificate. That's also why in the very beginning we explained the importance of checking the ownership of a domain name by ourselves. Secondly "connection" must imply somebody to whom you're connecting. Our legitimate server certificate customers are exactly complaining about such forceful but confusing warnings. I'm hoping that something can be done to re-phrase or "tone down" the severity of such warnings.
> Eddy, sorry but I can't agree with you on this. In PKI, the role of CA is to
> ensure the digital certificate holders are really who they are.

Exactly, it has nothing to do about how trustworthy a certificate holder is, it may confirm the identity of the holder of the certificate (and the other attributes like the domain name). Hence the connection (point-to-point and its encryption can be trusted). For EV certificates, Mozilla also trusts the verifications the CA performs in order to also show the verified attributes like name and locality.

> I'm hoping that something can be done to re-phrase or "tone
> down" the severity of such warnings.

This is not something we can discuss in this bug, for this Mozilla has UI and security specialists which deal exactly with those questions. There are also already various bugs in this regard. I believe the current implementation really wants to protect the user and not allow the simple click-once warnings. Eventually also your subscribers will be better protected once your root is supported here.
> At the same time, I hope to expedite the overall process for
> securing "trusted" recognition for the Hongkong Post root 
> certificate by sending you some new server certificates in 
> January 2010, even though mass production will only begin from 
> March 2010.  If I do that, can the release date of Firefox with
> Hongkong Post root certificate included be advanced to, say, Q1 of 2010?

As per Comment #69, it can take 5 months after the NSS bug has been created before the root will show up by default in Firefox. I have not yet created the NSS bug, because I've been waiting for resolution of the CRL issues. The sooner you can demonstrate the updates that resolve the CRL issues, the better.

    
    

    
  
Hongkong Post e-Cert CA 1 - 10 will issue all end-entity certs directly when
it's in production. And again, there is no subordinate CA under Hongkong Post
e-Cert CA 1 - 10.

As per your comment #16, only root certificates are included in Mozilla's NSS
database. I believe that the new subordindate CA certificate wouldn't bother
you.

Thank you again to taking this request forward.

    
    

    
  
Thank you for the update. Please clarify the differences between the “Hongkong Post e-Cert CA 1” and “Hongkong Post e-Cert CA 1 - 10” sub-CAs.

Just to make sure I understand… Please correct as needed.

“Hongkong Post Root CA 1” root now has two subordinate CAs:
“Hongkong Post e-Cert CA 1” and “Hongkong Post e-Cert CA 1 - 10”

The root and both of these sub-CAs are operated by E-Mice Solutions.
Copied from Comment #44:
Section 8-10 [Audit]. Section 8-10 [Audit].  
* Hongkong Post has appointed E-Mice Solutions (HK) Limited as its agent to operate the e-Cert services related to this root and all its subordinate CA certificates and end-entity certificates. This information is provided in the CPS and Management Assertions. The WebTrust audit includes both E-Mice operations and Hongkong Post operations. 
* Hongkong Post and E-Mice have undergone WebTrust CA audits by PricewaterhouseCoopers. The audits are current, and the most recent audit statement from February, 2009, is posted on WebTrust.org. 


The test server cert chains up to “Hongkong Post e-Cert CA 1 - 10” which chains up to the “Hongkong Post Root CA 1” root.  The test server cert has the following CRL Distribution Point URI:
http://crl1.hongkongpost.gov.hk/crl/eCertCA1-10CRL1.crl
This CRL imports into Firefox without error.  Next Update: 10 days

    
    

    
  
Yes, you're exactly correct. The two sub-CAs are virtually the same since "Hongkong Post e-Cert CA 1 - 10" will replace "Hongkong Post e-Cert CA 1" to issue all EE cert when its in production. The root and both of the sub-CAs are operated by E-Mice Solutions.

The CRL for the new server cert. can import into Firefox without error.

    
    

    
  
As per comments #44 and #47 this request by Hongkong Post to include the "Hongkong Post Root CA 1" root certificate (SSL use only) has been approved pending completion of the action items to resolve the CRL issues.

As per Comment #51, the action items were:
1) Hongkong Post needs to make the full CRL for its certificates discoverable
via CRLDP.
2) Hongkong Post needs to reduce the frequency of updating the full CRL from 3
times per day to 1 time per day, except when there is a revocation.

I confirm that both of those action items have been completed.

I will create the NSS bug for the inclusion of this "Hongkong Post Root CA 1" root certificate.

    
  
Depends on: 541499

    
    

    
  
I have filed bug 541499 against NSS for the actual changes.
Whiteboard: Approved - awaiting resolution of CA CRL issue → Approved - awaiting NSS

    
    

    
  
Excuse me. May I ask when and what version of Firefox should I expect this
enhancement be included in Firefox?

    
  
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: Approved - awaiting NSS → In Firefox 3.6.2

    
    

    
  

      
      
      
      

        Attached file
          
        WebtrustCA-2016.pdf
        — 
      

    


  
From the CA: 
"Please find the attached Webtrust audit report of Hongkong Post Certification Authority 2016 prepared by the auditor, Ernst & Young ("EY"), for your record. Posting of the Webtrust seal is being processed via the auditor.

BTW, we have already arranged the auditor to conduct WebTrust SSL baseline audit. It should be completed in March 2016 (this month). I will submit the audit report to you when our auditor has issued the report."

    
    

    
  

      
      
      
      

        Attached file
          
        WebTrust-BR-2016.pdf
        — 
      

    


  

    
    

    
  
As per Mozilla's process, I have exchanged email with the auditor to confirm the authenticity of these audit statements.

    
  
Product: mozilla.org → NSS
Product: NSS → CA Program

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: