First, let me clarify a mistake. In the previous comments, the version of SHECA's CPS was wrong. The latest version of the cps address is as follows: https://assets-cdn.sheca.com/documents/UniTrust%20Certification%20Practice%20Statement%20v3.7.8.pdf In CPS, Section 3.2.2.5 describes the rules for IP address verification, and the content is consistent with what I described above.
On Sunday, June 23, 2024 at 1:33:21 AM UTC+8 Alvin Wang wrote: > On behalf of SHECA, I am responding to the points that need clarification > in this discussion. > > Thank you, Aaron Gable, for your attention. SHECA immediately reviewed our > CPS content after seeing your comment. The latest CPS from SHECA can be > found at: > https://assets-cdn.sheca.com/documents/sheca-certification-practice-statement-en-v3.6.3.pdf > . > > In the CPS, section 3.2.6 describes the rules for IP address verification: > > - 1.Section 3.2.6 does not state the use of BR 3.2.2.5.4 for IP > verification because this method was prohibited on July 31, 2019. > - 2.The section describes SHECA's IP verification methods, where the > second item (1) and (2) corresponds to BR 3.2.2.5.1, and (3) corresponds > to > BR 3.2.2.5.3. > > > Huandu is SHECA's distributor (agent) and does not have any authority or > responsibility to issue or verify SSL certificates. SHECA's SSL certificate > issuance process strictly adheres to BR regulations. > All external disclosures regarding SSL certificate verification rules must > be conducted through SHECA's CPS, with no other disclosure channels. Huandu > published an inaccurate marketing article without SHECA's consent, > and we have urgently contacted Huandu to address this issue. > > *We hope this clarifies your concerns!* > > On Saturday, June 22, 2024 at 12:59:29 AM UTC+8 Aaron Gable wrote: > >> The BRs define an Authorized Port as "One of the following ports: 80 >> (http), 443 (https), 25 (smtp), 22 (ssh)". >> >> The UCA Global G2 Root is operated by SHECA, and their CPS >> <https://www.sheca.com/repository> says that they use method 3.2.2.5.1, >> as well as potentially method 3.2.2.5.4. (It also lists two other methods, >> labeled (2) and (3), which do not appear to correspond to BRs-approved >> methods.) >> >> The BRs say that IP address validation method 3.2.2.5.1 "Agreed-Upon >> Change to Website" must occur "via HTTP/HTTPS over an Authorized Port". It >> is unclear to me whether using HTTP/HTTPS over port 25 or 22 would be >> acceptable given the parenthetical nature of the protocol annotations, even >> setting aside the technical hurdle of actually doing so. >> >> If we assume that using HTTP/HTTPS over port 25 or 22 is allowed, then I >> believe the claim in the linked article could be both accurate and >> acceptable by the BRs. >> If we assume that using HTTP/HTTPS over port 25 or 22 is not allowed, or >> if the actual validation conducted by Huandu on behalf of SHECA occurs over >> a different port, then I believe the article's claim would not be >> acceptable by the BRs. >> >> Aaron >> >> On Fri, Jun 21, 2024 at 8:33 AM Arabella Barks <[email protected]> >> wrote: >> >>> I recently find a Chinese ssl reseller ihuandu.com says they provide a >>> ssl product which secures ip address and needn't 80/443 DCV. >>> >>> > The SSL certificate does not need to force the use of port 80 or 443 >>> to verify the public IP management permission, and has a more flexible >>> authentication port to help users obtain the SSL certificate of the public >>> IP in a relatively short time. >>> >>> https://www.ihuandu.com/pr/hddt/771.html >>> >>> Does it compliant BR? >>> The BR defines: >>> > 3.2.2.5 Authentication for an IP Address >>> > This section defines the permitted processes and procedures for >>> validating the Applicant’s ownership or control of an IP Address listed in >>> a Certificate. The CA SHALL confirm that prior to issuance, the CA has >>> validated each IP Address listed in the Certificate using at least one of >>> the methods specified in this section. Completed validations of Applicant >>> authority may be valid for the issuance of multiple Certificates over time. >>> In all cases, the validation must have been initiated within the time >>> period specified in the relevant requirement (such as Section 4.2.1 of this >>> document) prior to Certificate issuance. For purposes of IP Address >>> validation, the term Applicant includes the Applicant’s Parent Company, >>> Subsidiary Company, or Affiliate. After July 31, 2019, CAs SHALL maintain a >>> record of which IP validation method, including the relevant BR version >>> number, was used to validate every IP Address. >>> > >>> > 3.2.2.5.1 >>> > Agreed‑Upon Change to Website >>> > Confirming the Applicant’s control over the requested IP Address by >>> confirming the presence of a Request Token or Random Value contained in the >>> content of a file or webpage in the form of a meta tag under the >>> “/.well‐known/pki‐validation” directory, or another path registered with >>> IANA for the purpose of validating control of IP Addresses, on the IP >>> Address that is accessible by the CA via HTTP/HTTPS over an Authorized >>> Port. The Request Token or Random Value MUST NOT appear in the request. If >>> a Random Value is used, the CA SHALL provide a Random Value unique to the >>> certificate request and SHALL not use the Random Value after the longer of >>> i. 30 days or ii. if the Applicant submitted the certificate request, the >>> time frame permitted for reuse of validated information relevant to the >>> certificate (such as in Section 4.2.1 of this document). >>> > >>> > 3.2.2.5.2 >>> > Email, Fax, SMS, or Postal Mail to IP Address Contact >>> > Confirming the Applicant’s control over the IP Address by sending a >>> Random Value via email, fax, SMS, or postal mail and then receiving a >>> confirming response utilizing the Random Value. The Random Value MUST be >>> sent to an email address, fax/SMS number, or postal mail address identified >>> as an IP Address Contact. Each email, fax, SMS, or postal mail MAY confirm >>> control of multiple IP Addresses. The CA MAY send the email, fax, SMS, or >>> postal mail identified under this section to more than one recipient >>> provided that every recipient is identified by the IP Address Registration >>> Authority as representing the IP Address Contact for every IP Address being >>> verified using the email, fax, SMS, or postal mail. The Random Value SHALL >>> be unique in each email, fax, SMS, or postal mail. The CA MAY resend the >>> email, fax, SMS, or postal mail in its entirety, including re‐use of the >>> Random Value, provided that the communication’s entire contents and >>> recipient(s) remain unchanged. The Random Value SHALL remain valid for use >>> in a confirming response for no more than 30 days from its creation. The >>> CPS MAY specify a shorter validity period for Random Values, in which case >>> the CA MUST follow its CPS. pg. 36 >>> > >>> > 3.2.2.5.3 Reverse Address Lookup >>> > Confirming the Applicant’s control over the IP Address by obtaining a >>> Domain Name associated with the IP Address through a reverse‐IP lookup on >>> the IP Address and then verifying control over the FQDN using a method >>> permitted under Section 3.2.2.4. >>> > >>> > 3.2.2.5.4 >>> > Any Other Method >>> > Using any other method of confirmation, including variations of the >>> methods defined in Section 3.2.2.5, provided that the CA maintains >>> documented evidence that the method of confirmation establishes that the >>> Applicant has control over the IP Address to at least the same level of >>> assurance as the methods previously described in version 1.6.2 of these >>> Requirements. CAs SHALL NOT perform validations using this method after >>> July 31, 2019. Completed validations using this method SHALL NOT be re‐used >>> for certificate issuance after July 31, 2019. Any certificate issued prior >>> to August 1, 2019 containing an IP Address that was validated using any >>> method that was permitted under the prior version of this Section 3.2.2.5 >>> MAY continue to be used without revalidation until such certificate >>> naturally expires. 3.2.2.5.5 Phone Contact with IP Address Contact >>> Confirming the Applicant’s control over the IP Address by calling the IP >>> Address Contact’s phone number and obtaining a response confirming the >>> Applicant’s request for validation of the IP Address. The CA MUST place the >>> call to a phone number identified by the IP Address Registration Authority >>> as the IP Address Contact. Each phone call SHALL be made to a single >>> number. In the event that someone other than an IP Address Contact is >>> reached, the CA MAY request to be transferred to the IP Address Contact. In >>> the event of reaching voicemail, the CA may leave the Random Value and the >>> IP Address(es) being validated. The Random Value MUST be returned to the CA >>> to approve the request. The Random Value SHALL remain valid for use in a >>> confirming response for no more than 30 days from its creation. The CPS MAY >>> specify a shorter validity period for Random Values. >>> > >>> > 3.2.2.5.6 ACME “http‑01” method for IP Addresses >>> > Confirming the Applicant’s control over the IP Address by performing >>> the procedure documented for an “http‐01” challenge in RFC 8738. >>> > >>> > 3.2.2.5.7 ACME “tls‑alpn‑01” method for IP Addresses >>> > Confirming the Applicant’s control over the IP Address by performing >>> the procedure documented for a “tls‐alpn‐01” challenge in RFC 8738. >>> >>> And I am curious much about Does it compliant BR(which method are they >>> requiring)? >>> and how they conduct reviews to ensure that the IP website identity is >>> not being misused? >>> >>> Root CA: >>> CN = UCA Global G2 Root >>> O = UniTrust >>> C = CN >>> >>> Intermedia CA: >>> CN = KeepTrust OV TLS RSA CA G1 >>> O = Shanghai Huandu Info Tech Co. Ltd. >>> C = CN >>> >>> -- >>> 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/8f7dfd56-20dc-4a9f-bea2-1137d9289255n%40mozilla.org >>> >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/8f7dfd56-20dc-4a9f-bea2-1137d9289255n%40mozilla.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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/d7c366c2-9d4e-4a7d-a14e-20e75b7e754dn%40mozilla.org.
