{"text_format":"2","workbook":"xlsx","n_sheets":9,"sheets":["Instructions","Change History","Cover Sheet","CCADB Policy v. 1.1 Self Assess","TLS BRs v. 1.8.6 Self Assessmen","NCSSRs v. 1.7 Self Assessment","Chrome Root Program Policy v. 1","Mozilla Compliance Self Assessm","TLS EV v. 1.8.0 Self Assessment"],"not_rendered":{"charts":0,"images":0,"macros":0,"external_links":0,"defined_names":1,"comments":0,"pivot_tables":0},"unopened":[],"bounds":{"document_bytes":16777216,"sheet_cells":100000,"run_cost":"one","rows_first":2000,"rows_last":500,"rows_between":2000,"halvings":0,"cell_chars":16384,"cell_head_chars":4096},"cells_cut":0,"cells_raw":0,"read":"whole","date_system":"1900"}

{"sheet":"Instructions","index":0,"n_rows":12,"n_cols":1,"rows_kept":12,"cut":false,"hidden":false,"merged":[]}
["CCADB Self Assessment Instructions"]
["Step 1: Make a copy of this Workbook."]
["Step 2: Complete the \"Cover Sheet\" tab\n- Provide all requested data.\n- A single Self-Assessment may cover multiple CAs operating under both the same CP and CPS(s), or combined CP/CPS. \n- CAs not operated under the same CP and CPS(s) or combined CP/CPS must be covered in a separate Self-Assessment. \n- Each Self-Assessment submission must enumerate all CAs listed in the CA owner's CCADB CA hierarchy. If you are submitting multiple Self-Assessments, designate which CAs included in your CCADB CA hierarchy are out of scope for this particular submission, and provide a link to the Self-Assessment where these CAs are in scope. If a CA will not be included within the scope of a Self-Assessment, provide justification (i.e., certificate expired or was revoked prior to the beginning of the most recent audit period).\n- Add additional rows, as needed."]
["Step 3: Complete the \"CCADB Policy v. X.X Self Assessment\" tab.\n- Review each row included in the sheet, representing the requirements defined in the CCADB Policy.\n- For each requirement, submit an attestation that the CAs included within the scope of this Self-Assessment currently comply with and commit to ongoing compliance for as long as they are trusted by the applicable root stores by selecting the designated checkbox."]
["Step 4: Complete the \"TLS BR v. X.X.X Self Assessment (excludes EVGs)\" tab.\n- Review each row included in the sheet, representing the requirements defined in the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates\n- For each requirement:\n\nA) include the section of where the relevant requirement statement(s) are included in the corresponding CP or combined CP/CPS that adheres to the Baseline Requirements.\n- if the corresponding requirement is not applicable, include a comment designating such and provide a justification.\n\nB) include the section where the relevant practice statement(s) are included in the corresponding CPS or combined CP/CPS that satisfies the requirement defined in the CP (or Baseline Requirements, if a combined CP/CPS is in use).\n- if the corresponding requirement is not applicable, include a comment designating such and provide a justification (for example \"N/A: We do not support this domain validation method.\")"]
["Step 5: Complete the \"NCSSRs v. X.X\" tab. \n- Review each row included in the sheet, representing the requirements defined in the CA/Browser Forum Network Security Requirements (NCSSRs).\n- For each requirement, submit an attestation that the CAs included within the scope of this assessment currently comply with and commit to ongoing compliance for as long as they are trusted by the applicable root stores by selecting the designated checkbox."]
["Step 6: Complete the relevant Root Program-specific tabs, as described below.\n\n - Google Chrome: \n    - New applicants must provide a completed Self-Assessment during the application process.\n    - CA owners with certificates included in the Chrome Root Store must submit a completed Self-Assessment annually. See the Chrome Root Program policy for more detail.\n\n - Mozilla Firefox:\n    - New applicants must provide a completed Self-Assessment during the application process. See https://wiki.mozilla.org/CA/Compliance_Self-Assessment for more detail."]
["Step 7: Complete the \"TLS EV VX.X.X Self Assessment\" sheet (required only for EV-issuers, only).\n- Review each row included in the sheet, representing the requirements defined in the CA/Browser Forum EV Guidelines (EVGs).\n- For each requirement, submit an attestation that the CAs included within the scope of this assessment currently comply with and commit to ongoing compliance for as long as they are trusted by the applicable root stores by selecting the designated checkbox."]
["Reminders: "]
["- Bookmark this page! Whenever you are preparing to complete a Self-Assessment using this template, make sure you are using the latest version. \n- Contact support@ccadb.org with any general questions or concerns.\n- For questions specific to a particular Root Program (i.e., Chrome or Mozilla), please contact them directly (i.e., chrome-root-program@google.com or certificates@mozilla.org) "]
["General Recommendations: "]
["- The absence of requirements defined in the Baseline Requirements is not a satisfactory response for not describing your organization's policies or practices for a particular topic area. In the absence of requirements defined in the Baseline Requirements, we recommend CAs provide descriptions as detailed in RFC 3647 or NISTIR 7924. "]

{"sheet":"Change History","index":1,"n_rows":2,"n_cols":1,"rows_kept":2,"cut":false,"hidden":false,"merged":[]}
["CCADB CA Self Assessment Change History"]
["Version 1.0 (01/05/2023): Initial release\n"]

{"sheet":"Cover Sheet","index":2,"n_rows":53,"n_cols":6,"rows_kept":53,"cut":false,"hidden":false,"merged":[[2,0,2,1],[26,0,26,4],[51,0,51,5],[56,0,56,3]]}
["CCADB Self Assessment Framework Version #: ","1.0"]
[]
["Provide all of the following information"]
["CA Owner's Name:","Beijing Certificate Authority Co.,Ltd."]
["Date this Assessment was Completed:","2023-02-08"]
["Completed By (Name):","Peng Li"]
["Completed By (Title):","Operational Service Manager"]
["Completed By (Email):","lipeng@bjca.org.cn"]
["CP Used for Assessment (Title):","Beijing Certificate Authority Co., Ltd. Global Certificate Policy"]
["CP Used for Assessment (Version):","Version 1.0.6"]
["CP Used for Assessment (Last Update Date):","Jul 25,2022"]
["CP Used for Assessment (URL):","https://www.bjca.cn/u4d/%E8%AF%81%E4%B9%A6%E7%AD%96%E7%95%A5%EF%BC%88CP%EF%BC%89/files/%E5%8C%97%E4%BA%AC%E6%95%B0%E5%AD%97%E8%AE%A4%E8%AF%81%E8%82%A1%E4%BB%BD%E6%9C%89%E9%99%90%E5%85%AC%E5%8F%B8%E5%85%A8%E7%90%83%E8%AE%A4%E8%AF%81%E4%BD%93%E7%B3%BB%E8%AF%81%E4%B9%A6%E7%AD%96%E7%95%A5%20Beijing%20Certificate%20Authority%20Co.,%20Ltd.%20Global%20Certificate%20Policy.pdf"]
["CPS Used for Assessment (Title):","Beijing Certificate Authority Co., Ltd. Global Certification Practice Statement"]
["CPS Used for Assessment (Version):","Version 1.0.6"]
["CPS Used for Assessment (Last Update Date):","Jul 25,2022"]
["CPS Used for Assessment (URL):","https://www.bjca.cn/u4d/%E7%94%B5%E5%AD%90%E8%AE%A4%E8%AF%81%E4%B8%9A%E5%8A%A1%E8%A7%84%E5%88%99%EF%BC%88CPS%EF%BC%89/files/%E5%8C%97%E4%BA%AC%E6%95%B0%E5%AD%97%E8%AE%A4%E8%AF%81%E8%82%A1%E4%BB%BD%E6%9C%89%E9%99%90%E5%85%AC%E5%8F%B8%E5%85%A8%E7%90%83%E8%AE%A4%E8%AF%81%E4%BD%93%E7%B3%BB%E7%94%B5%E5%AD%90%E8%AE%A4%E8%AF%81%E4%B8%9A%E5%8A%A1%E8%A7%84%E5%88%99%20Beijing%20Certificate%20Authority%20Co.,%20Ltd.%20Global%20Certification%20Practice%20Statement.pdf"]
["(if applicable) CP/CPS Used for Assessment (Title):"]
["(if applicable) CP/CPS Used for Assessment (Version):"]
["(if applicable) CP/CPS Used for Assessment (Last Update Date):"]
["(if applicable) CP/CPS Used for Assessment (URL):"]
["(if applicable) TSPS Used for Assessment (Title):"]
["(if applicable) TSPS Used for Assessment (Version):"]
["(if applicable) TSPS Used for Assessment (Last Update Date):"]
["(if applicable) TSPS Used for Assessment (URL):"]
["Add new rows as necessary to identify additional documents"]
[]
["Enumerate all CAs covered by this Self-Assessment"]
["Subject","Issuer","SHA-256 Hash (Certificate)","SHA-256 Hash (SPKI)","Revoked?/Expired?"]
["CN=BJCA Global Root CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","F3896F88FE7C0A882766A7FA6AD2749FB57A7F3E98FB769C1FA7B09C2C44D5AE","EBC55F21E88D49EDE81C0075AB08B3C73B81F0F33E37D7641A1D01B6E602DC9D","Valid"]
["CN=BJCA Code Signing CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","47D98649B0ABE9F8C8596BEBD95AF3316300506E156C1968E39C95AE83BD70D5","96047CB79C16E14807F9472324F07B0E12600E0A19384ECC8535D9D9BA3FCFC0","Valid"]
["CN=BJCA Code Signing CA1 G2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","9677A7E2ACB3F5BA75AD9BCEE3C18A4C484DAF891B817F0AC713923E4337EA56","48A517CC1B2B7B5E3477D22A59BF11B6862D294FF93AB815101280780B740EBD","Valid"]
["CN=BJCA Generic CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","19D0FE660DBC0FA948CF45918E48DEFB8396C4026903BC19FE4F91552DFF4DC9","AB82E114DFEBD5CDDD36DF4DCB15B03B0292D52F43BF680954AC4D6B9ED874F2","Valid"]
["CN=BJCA IV SSL CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","D70C597009AF3A3A37BDFABEA0C64108C7B83CD6C2042E8FF178A3EE8FE0CAE8","D40FD80CAD02BE1D31E1CF4EAC7EA1A97ABF456D6F1FAA98F91FEDA89E6AB288","Valid"]
["CN=BJCA OV SSL CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","0A6BC3E2024AC462F5D72BE436AE61D033978EA8DDB63D4C5D6214915E69049B","081CBF3346283AC5285CFD129F8AE4DFBD51034866C2FA4A4EF66B8F431CD8B2","Valid"]
["CN=BJCA TimeStamp CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","245B753A631DD7A5A5B0D3E6DFECA4599C7A1C93D71CBA04ED7BC81D3986303F","907A2B20A198594B721A9F76AAAA897B6926E27BF7C220A6203A3DC68D63A0EC","Valid"]
["CN=BJCA TimeStamp CA1 G2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","64FF2BFC836D5980F58605FD80029F499B805610E10467B9DCCC0D327E0AF561","231B684C4BDCCDE28425F6D3A5762DD34175000158ABF419DB4BC53B0E91D224","Valid"]
["CN=BJCA DV SSL CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","B408D6C82097121694B9B6548C5B4944594C081134F36C5BE88D74FA34759D91","92E29D6BABA3C1E0CBE1D3BEA378FBE63503C6AB3C6167032B6F4B4F67DCDB28","Valid"]
["CN=BJCA EV Code Signing CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","B6352ACC11ECCCFE449023D88C3C038082DE78829CB7C33DD5017FE95852AECA","C73F4C47D70A5296CD5372D143D99E7D280667C0A4A5A6967C23FC8F656E52EC","Valid"]
["CN=BJCA EV Code Signing CA1 G2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","418D2B75C8B44B3A20FC93F55D7006158CC8C0F1A9C1A8C5E8C902AACF36B308","F3E7BECD28E4E72DCC5D29BC5EF4DDA30D01525457E67E3E58556E2733250A29","Valid"]
["CN=BJCA EV SSL CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA1; O=BEIJING CERTIFICATE AUTHORITY; C=CN","115A2A45DB520361A2CDF0A395C4A4BD8A18902EAA4036792825F846BBD76917","B0B903CDA5FD43C7AD3964DD1C400DCCE4B77278E9FB2A83D1CA12F626874633","Valid"]
["CN=BJCA Global Root CA2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","574DF6931E278039667B720AFDC1600FC27EB66DD3092979FB73856487212882","CC94A5A0319FF77A4CCADD821C4C59674E44D52816CBD1DFE2C761370AD4D21C","Valid"]
["CN=BJCA Generic CA2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","B4CDCF2F4A1141CFE604F7D50627C96F882AAB95C1D3B7A4ABB24615DB157D17","DF5C0D9E320E9C8599D87E8D262B970512C18739E03CC6B742988C24D27E36DD","Valid"]
["CN=BJCA IV SSL CA2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","2F9F41114DCADC30784E40FEF7D6EE063A9BE7A363DE5737E88FA1118671505E","E2405FD0292E7FD5FE079E89808EB643D2F93648F73E4E0D17946623BD54BC81","Valid"]
["CN=BJCA OV SSL CA2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","3A1A4BD6A62468578DBC91DC24705B276A837CC18B6BEF1FF3F6ED0FE6326302","B6F26D24EE3EDC1F0CA10E42D19C1A725759086F9F2502965D274879D4CFEF05","Valid"]
["CN=BJCA TimeStamp CA2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","353D175D25D53E850FF336271E1A7C0DC072AF8E0092BCAB6B9BC39E0FABAE09","5AC82D82E6FD57A3E9E9A270771E7411C850027634CDBC7B2795E01BCB2FF89F","Valid"]
["CN=BJCA Code Signing CA2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","FC6C124D84F7EDFF00F0EEF6FE54E832114A74D131E075932A6FF03D6E575AAB","377D888584F824695E1419972134B3555C82FB9275B1194525CDBC188DC4056E","Valid"]
["CN=BJCA DV SSL CA2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","3F5CB1531CB1223AABFB70872DC43D2DD6CC3D2823E96B458A9F8A7EC0265946","F1678357C56E109AC38CD36752411405B1024FAA6BEDDDD59D93B004EF3B7DC0","Valid"]
["CN=BJCA EV Code Signing CA2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","E97960A1A1740CAD61D0ED6A5BDBE4E946D11E6EBDB093D668AB9BB004F78BB3","6979F19159C4A926426495E0A6CC5376CCA48E94C339E266C6B35BDC6DA66A1D","Valid"]
["CN=BJCA EV SSL CA2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","CN=BJCA Global Root CA2; O=BEIJING CERTIFICATE AUTHORITY; C=CN","E601477705341270FD120066BBDF26223E6953C4DB8FA7EA197EAF5BF8343B25","8B3C405B5BC543E5060F16592D7365FCEEE314DE96DD544A1312975835F83ECE","Valid"]
[]
[]
["Enumerate all CAs covered by another Self-Assessment"]
["Subject","Issuer","SHA-256 Hash (Certificate)","SHA-256 Hash (SPKI)","Revoked?/Expired?","Link to \"in scope\" assessment or justification for not being included in an assessment"]

{"sheet":"CCADB Policy v. 1.1 Self Assess","index":3,"n_rows":22,"n_cols":6,"rows_kept":22,"cut":false,"hidden":false,"merged":[[1,0,1,5],[3,0,3,5],[8,0,8,5],[10,0,10,5],[13,0,13,5]]}
["SECTION","SECTION NAME","REQUIREMENT from CCADB Policy (Version 1.1)\n(https://www.ccadb.org/policy)","CURRENTLY COMPLY and INTEND TO CONTINUE COMPLIANCE","CA COMMENTS (Optional)","DETAILED ROOT PROGRAM REVIEW"]
["1. General Provisions"]
[1,"General Provisions","CAs have an overarching responsibility to keep the information in the CCADB about themselves, their operations and their certificates accurate, and to make updates in a timely fashion.",true,"We understand this requirement, currently comply and intend to continue compliance."]
["2. Contact Information"]
[2,"Contact Information","CAs are required to provide the following information for a Primary Point of Contact (POC), and at least one other POC, who may or may not be Primary:\n\nName\nOffice email address\nOffice hours phone number",true,"Contact information has been submitted to CCADB."]
[2,"Contact Information","CAs must also supply one or two non-personal contact email aliases which are more likely to continue working as personnel change; these are maintained as part of the CA’s organizational entry.",true,"Non-personal contact email aliases has been submitted to CCADB."]
[2,"Contact Information","At least one of the Primary POCs will hold a CA Community license;",true,"We understand this requirement, currently comply and intend to continue compliance."]
[2,"Contact Information","Those Primary POCs with a CA Community license are ultimately responsible for keeping CCADB data up-to-date for their CA(s).",true,"We understand this requirement, currently comply and intend to continue compliance."]
["3. Root Certificates"]
[3,"Root Certificates","CAs are required to maintain correct and current information about their root certificates.",true,"The correct and current information about our root certificates have been submitted to CCADB."]
["4. Intermediate Certificates"]
[4,"Intermediate Certificates","A newly-created intermediate certificate must be entered into the CCADB before the intermediate CA begins issuing publicly-trusted certificates.",true,"We understand this requirement, currently comply and intend to continue compliance."]
[4,"Intermediate Certificates","If an intermediate certificate is revoked, the CCADB must be updated to mark it as revoked, giving the reason why, within 24 hours for a security incident, and within 7 days for any other reason.",true,"We understand this requirement, currently comply and intend to continue compliance."]
["5. Policies, Practices and Audit Information"]
[5,"Policies, Practices and Audit Information","In the records for both root certificates and intermediate certificates, CAs are required to provide details of the Certificate Policy (CP) and/or Certificate Practice Statement (CPS) documents relating to that certificate, and also statements of attestation of their conformance to various requirements and other operational criteria (“audits”), those statements being made by a competent independent party or parties.",true,"BJCA Global CP and CPS have detailed descriptions of root certificates and intermediate certificates, independent third party audit reports\n1.https://www.cpacanada.ca/GenericHandlers/CPACHandler.ashx?AttachmentID=389f5843-e05f-4e80-aae0-23cee8922866\n2.https://www.cpacanada.ca//GenericHandlers/CPACHandler.ashx?AttachmentID=2c0c075a-0000-40f1-8a81-1ccb21268e62\n3.https://www.cpacanada.ca//GenericHandlers/CPACHandler.ashx?AttachmentID=78bb08b0-7523-4011-b27c-b8a1a978433e\n4.https://www.cpacanada.ca//GenericHandlers/CPACHandler.ashx?AttachmentID=eb8e9482-2473-4f7d-85de-1474b2b6f8b4"]
[5,"Policies, Practices and Audit Information","These documents are hosted elsewhere and the URLs are stored in the CCADB. \n\nThe URLs to such CPs, CPSes and audits, and any metadata about them such as the name of the auditor or the date of the audit, need to be updated as new information become available. \n\nFor technical reasons, URLs to audit statements need to point to a PDF file.",true]
[5,"Policies, Practices and Audit Information","The entry for each intermediate certificate has “Audits Same as Parent” and “CP/CPS Same as Parent” checkboxes. When those are checked, the details do not need to be duplicated from the parent certificate. However, the intermediate certificate must be specifically listed in the audit statements of the parent certificate.",true]
[5,"Policies, Practices and Audit Information","URLs for the following documents are required for each certificate, unless the exceptions below apply:\n\n- Certificate Policy (CP)\n- Certification Practice Statement (CPS)\n- Standard audit (WebTrust or ETSI)\n- Baseline Requirements (BR) audit (if the certificate is capable of issuing TLS/SSL server certificates)\n- Extended Validation (EV) SSL and/or Code Signing audit (if applicable)\n\nExceptions to providing audit information:\n\n- The SHA-256 fingerprint of the certificate is specifically listed as in scope in the audit statements of the parent certificate, and the “Audits Same as Parent” checkbox is checked; or\n- The certificate has expired; or\n- The certificate is technically-constrained as described in section 7.1.5 of the CA/Browser Forum Baseline Requirements, or\n- The certificate has been revoked, and the corresponding record in the CCADB has been updated with the correct revocation status.",true]
[5,"Policies, Practices and Audit Information","CAs must provide English versions of any Certificate Policy, Certification Practice Statement and Audit documents which are not originally in English, with version numbers matching the document they are a translation of. \n\nThe English version is not required to be authoritative in all cases of dispute, but the CA must attest that the translation is not materially different to the original.\n",true,"We understand this requirement, and the CP/CPS and audit reports we issue are bilingual in Chinese and English."]
[5.1,"Audit Statement Content","Audit statements listed in the CCADB must contain at least the following clearly-labelled information in English:\n\n1. Name and address of the organization performing the audit;\n2. Full name of the CA that was audited;\n3. SHA-256 fingerprint of each root and intermediate certificate that was in scope of the audit (see format specifications below);\n4. List of the CA policy documents (with version numbers) referenced during the audit;\n5. Whether the audit is for a period of time or a point in time;\n6. Date the audit statement was written, which will necessarily be after the audit period end date or point-in-time date (see date format specifications below);\n7. Start date and end date of the period that was audited, for those that cover a period of time (this is not the period the auditor was on-site);\n8. Point-in-time date, for those that are for a point in time;\n9. Full names and version numbers of the audit standards that were used during the audit; and\n10. For ETSI, a statement to indicate if the audit was a full audit, and which parts of the criteria were applied, e.g. DVCP, OVCP, NCP, NCP+, LCP, EVCP, EVCP+, QCP-w, Part1 (General Requirements), and/or Part 2 (Requirements for trust service providers).",true,"We have submitted the above information in CCADB."]
[5.1,"Audit Statement Content","Audits based on ETSI CPs: Audits conducted by accredited conformity assessment bodies (CAB) must have their Audit Attestation Letter (AAL) uploaded to the CAB’s website. CAs provide the URL to the AAL on the CAB’s website, and ALV will verify those URLs against a known list of AAL locations.\n\n- When an ETSI Certificate cannot be issued, the CA must still provide an AAL such that there are no gaps between audit periods for consecutive audits. The CA may post the AAL on their own website or attach the attestation report to a Bugzilla Bug and provide that URL. Additionally, the CA needs to provide an explanation about the problems and time frame for resolution of the problems.","N/A","BJCA performs audit based on WebTrust."]
[5.1,"Audit Statement Content","WebTrust Audits: Audits conducted by licensed WebTrust practitioners must have a WebTrust Seal. CAs enter the URL to the WebTrust Seal into the CCADB, and upon saving of the record, the CCADB automatically converts the URL to point to the corresponding PDF file via integration with CPA Canada.\n\n- For qualified WebTrust audits, the CA may post the audit statements on their own website or attach the audit statement to a Bugzilla Bug and provide that URL. Additionally, the CA needs to provide an explanation about the findings and time frame for resolution of the findings.",true,"So far, the audit periods have been continuous without any gaps.\nInformation from the latest audit report has been submitted to CCADB."]

{"sheet":"TLS BRs v. 1.8.6 Self Assessmen","index":4,"n_rows":532,"n_cols":7,"rows_kept":532,"cut":false,"hidden":false,"merged":[[1,0,1,1],[28,0,28,1],[40,0,40,1],[151,0,151,1],[241,0,241,1],[308,0,308,1],[361,0,361,1],[444,0,444,1],[473,0,473,1]]}
["SECTION","SECTION NAME","REQUIREMENT from BRs (Version 1.8.6)","CERTIFICATE POLICY SECTION THAT ADHERES TO THE BASELINE REQUIREMENTS (Or comment, if the requirement is N/A)","CERTIFICATION PRACTICE STATEMENT SECTION (Or TSPS) THAT ADHERES TO THE CP (Or comment, if the requirement is N/A)","CA COMMENTS (Optional)","DETAILED ROOT PROGRAM REVIEW\nReviewer Comments (Highlight deficiencies in yellow for further review)"]
["1. Introduction"]
[1.1,"Overview","N/A (no requirements included in this section)\n\n\n"]
[1.2,"Document name and identification","N/A (no requirements included in this section)\n"]
["1.2.1","Revisions","N/A (no requirements included in this section)\n"]
["1.2.2","Relevant Dates","N/A (anticipated effective dates are included in individual requirement statements throughout the BRs).\n"]
[1.3,"PKI Participants","N/A (no requirements included in this section)\n"]
["1.3.1","Certification Authorities","N/A (no requirements included in this section)\n"]
["1.3.2","Registration Authorities","With the exception of Section 3.2.2.4 and Section 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2.","Section 1.3.2\n","Section 1.3.2","Besides acting as a CA, BJCA will also act as a RA and no third party will be entrusted as the RA."]
["1.3.2","Registration Authorities","Before the CA authorizes a Delegated Third Party to perform a delegated function, the CA SHALL contractually require the Delegated Third Party to:\n\n1. Meet the qualification requirements of Section 5.3.1, when applicable to the delegated function;\n\n2. Retain documentation in accordance with Section 5.5.2;\n\n3. Abide by the other provisions of these Requirements that are applicable to the delegated function; and\n\n4. Comply with\na. the CA’s Certificate Policy/Certification Practice Statement or\nb. the Delegated Third Party’s practice statement that the CA has verified complies with these Requirements.","N/A","N/A","Besides acting as a CA, BJCA will also act as a RA and no third party will be entrusted as the RA."]
["1.3.2","Registration Authorities","The CA MAY designate an Enterprise RA to verify certificate requests from the Enterprise RA’s own organization. \n\nThe CA SHALL NOT accept certificate requests authorized by an Enterprise RA unless the following requirements are satisfied:\n\n1. The CA SHALL confirm that the requested Fully-Qualified Domain Name(s) are within the Enterprise RA’s verified Domain Namespace.\n\n2. If the certificate request includes a Subject name of a type other than a Fully-Qualified Domain Name, the CA SHALL confirm that the name is either that of the delegated enterprise, or an Affiliate of the delegated enterprise, or that the delegated enterprise is an agent of the named Subject. For example, the CA SHALL NOT issue a Certificate containing the Subject name “XYZ Co.” on the authority of Enterprise RA “ABC Co.”, unless the two companies are affiliated  see Section 3.2) or “ABC Co.” is the agent of “XYZ Co”. This requirement applies regardless of whether the accompanying requested Subject FQDN falls within the Domain Namespace of ABC Co.’s Registered Domain Name.","N/A","N/A","Besides acting as a CA, BJCA will also act as a RA and no third party will be entrusted as the RA."]
["1.3.2","Registration Authorities","The CA SHALL impose these limitations as a contractual requirement on the Enterprise RA and monitor compliance by the Enterprise RA.","N/A","N/A","Besides acting as a CA, BJCA will also act as a RA and no third party will be entrusted as the RA."]
["1.3.3","Subscribers","See Section 1.6.1.","Section 1.3.3","Section 1.3.3"]
["1.3.4","Relying Parties","N/A (no requirements included in this section)\n"]
["1.3.5","Other Participants","N/A (no requirements included in this section)\n"]
[1.4,"Certificate Usage","No stipulation (implied).\n"]
["1.4.1","Appropriate Certificate Uses","N/A (no requirements included in this section)\n"]
["1.4.2","Prohibited Certificate Uses","No stipulation.\n"]
[1.5,"Policy administration","N/A (no requirements included in this section)\n"]
["1.5.1","Organization Administering the Document\n","No stipulation.\n"]
["1.5.2","Contact Person","In this section of a CA’s CPS, the CA shall provide a link to a web page or an email address for contacting the person or persons responsible for operation of the CA.","Section 1.5.2.2","Section 1.5.2.2"]
["1.5.3","Person Determining CPS suitability for the policy\n","No stipulation.\n"]
["1.5.4","CPS approval procedures","No stipulation.\n"]
[1.6,"Definitions and Acronyms","No stipulation (implied).\n"]
["1.6.1","Definitions","Note: After careful consideration, indicate if the definitions included in the CA operator's CP/CPS are materially different than those listed in the BRs.","Section 1.6.1 \n","Section 1.6.1","There is no material difference with the definitions listed in BRs."]
["1.6.2","Acronyms","Note: After careful consideration, indicate if the acronyms included in the CA operator's CP/CPS are materially different than those listed in the BRs.","Section 1.6.2\n","Section 1.6.2","There is no material difference with the acronyms listed in BRs."]
["1.6.3","References","N/A (no requirements included in this section)\n"]
["1.6.4","Conventions","N/A (no requirements included in this section)\n\nNote: It is recommended that CA operator policies express the use of conventions in alignment with RFC 2119.\n"]
["2. Publication and Repository Responsibilities"]
[2,"Publication and Repository Responsibilities","The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements.","Section 1.5.3, 1.5.4 and 1.5.5","Section 1.5.3, 1.5.4 and 1.5.5"]
[2.1,"Repositories","The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with this Policy.","Section 2.3","Section 2.3"]
[2.2,"Publication of information","The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis.","Section 2.2","Section 2.2\n"]
[2.2,"Publication of information","The CA SHALL publicly disclose its CA business practices to the extent required by the CA’s selected audit scheme (see Section 8.4).","Section 2.2 and 8.4","Section 2.2 and 8.4"]
[2.2,"Publication of information","The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 and MUST include all material required by RFC 3647.","Section 1.1.2","Statements"]
[2.2,"Publication of information","Section 4.2 of a CA’s Certificate Policy and/or Certification Practice Statement SHALL state the CA’s policy or practice on processing CAA Records for Fully-Qualified Domain Names; that policy shall be consistent with these Requirements. \n\nIt shall clearly specify the set of Issuer Domain Names that the CA recognizes in CAA “issue” or “issuewild” records as permitting it to issue. \n\nThe CA SHALL log all actions taken, if any, consistent with its processing practice.","Section 2.2 and 4.2.1","Section 2.2 and 4.2.1"]
[2.2,"Publication of information","The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version. \n\nThe CA MAY fulfill this requirement by incorporating these Requirements directly into its Certificate Policy and/or Certification Practice Statements or by incorporating them by reference using a clause such as the following (which MUST include a link to the official version of these Requirements):\n\n[Name of CA] conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates published at http://www.cabforum.org. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document.","Section 1.5.5","Section 1.1.2 and 1.5.5"]
[2.2,"Publication of information","The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. \n\nAt a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are\n\ni. valid,\nii. revoked, and\niii. expired.","See\nhttps://demossl-rsa-valid.bjca.org.cn\nhttps://demossl-rsa-expired.bjca.org.cn\nhttps://demossl-rsa-revoked.bjca.org.cn\nhttps://demossl-ecc-valid.bjca.org.cn\nhttps://demossl-ecc-expired.bjca.org.cn\nhttps://demossl-ecc-revoked.bjca.org.cn","See\nhttps://demossl-rsa-valid.bjca.org.cn\nhttps://demossl-rsa-expired.bjca.org.cn\nhttps://demossl-rsa-revoked.bjca.org.cn\nhttps://demossl-ecc-valid.bjca.org.cn\nhttps://demossl-ecc-expired.bjca.org.cn\nhttps://demossl-ecc-revoked.bjca.org.cn"]
[2.3,"Time or frequency of publication","The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements.","Section 1.5.3, 1.5.4, 1.5.5 and 2.3","Section 1.5.3, 1.5.4, 1.5.5 and 2.3"]
[2.3,"Time or frequency of publication","The CA SHALL indicate conformance with this requirement by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document.","Section 1.5.5","Section 1.5.5"]
[2.4,"Access controls on repositories","The CA shall make its Repository publicly available in a read-only manner.","Section 2.4","Section 2.4"]
["3. Identification and Authentication"]
[3.1,"Naming","No stipulation (implied).\n"]
["3.1.1","Types of names","No stipulation (implied).\n"]
["3.1.2","Need for names to be meaningful","No stipulation (implied).\n"]
["3.1.3","Anonymity or pseudonymity of subscribers\n","No stipulation (implied).\n"]
["3.1.4","Rules for interpreting various name forms\n","No stipulation (implied).\n"]
["3.1.5","Uniqueness of names","No stipulation (implied).\n"]
["3.1.6","Recognition, authentication, and role of trademarks","No stipulation (implied).\n"]
[3.2,"Initial identity validation","No stipulation (implied).\n"]
["3.2.1","Method to prove possession of private key\n","No stipulation (implied).\n"]
["3.2.2","Authentication of Organization and Domain Identity","If the Applicant requests a Certificate that will contain Subject Identity Information comprised only of the countryName field, then the CA SHALL verify the country associated with the Subject using a verification process meeting the requirements of Section 3.2.2.3 and that is described in the CA’s Certificate Policy and/or Certification Practice Statement.","Section 3.2.2.3","Section 3.2.2.3"]
["3.2.2","Authentication of Organization and Domain Identity","If the Applicant requests a Certificate that will contain the countryName field and other Subject Identity Information, then the CA SHALL verify the identity of the Applicant, and the authenticity of the Applicant Representative’s certificate request using a verification process meeting the requirements of this Section 3.2.2.1 and that is described in the CA’s Certificate Policy and/or Certification Practice Statement.","Section 3.2.2.1 and 3.2.2.3","Section 3.2.2.1 and 3.2.2.3"]
["3.2.2","Authentication of Organization and Domain Identity","The CA SHALL inspect any document relied upon under this Section for alteration or falsification.","Section 3.2.2","Section 3.2.2"]
["3.2.2.1","Identity","If the Subject Identity Information is to include the name or address of an organization, the CA SHALL verify the identity and address of the organization and that the address is the Applicant’s address of existence or operation.","Section 3.2.2.1 and 3.2.2.13","Section 3.2.2.1 and 3.2.2.13"]
["3.2.2.1","Identity","The CA SHALL verify the identity and address of the Applicant using documentation provided by, or through communication with, at least one of the following:\n\n1. A government agency in the jurisdiction of the Applicant’s legal creation, existence, or recognition;\n\n2. A third party database that is periodically updated and considered a Reliable Data Source;\n\n3. A site visit by the CA or a third party who is acting as an agent for the CA; or\n\n4. An Attestation Letter.","Section 3.2.2.1","Section 3.2.2.1"]
["3.2.2.1","Identity","The CA MAY use the same documentation or communication described in 1 through 4 above to verify both the Applicant’s identity and address.","Section 3.2.2.1 and 3.2.2.7","Section 3.2.2.1 and 3.2.2.7"]
["3.2.2.1","Identity","Alternatively, the CA MAY verify the address of the Applicant (but not the identity of the Applicant) using a utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable.","Section 3.2.2.13","Section 3.2.2.13"]
["3.2.2.2","DBA/Tradename","If the Subject Identity Information is to include a DBA or tradename, the CA SHALL verify the Applicant’s right to use the DBA/tradename using at least one of the following:\n\n1. Documentation provided by, or communication with, a government agency in the jurisdiction of the Applicant’s legal creation, existence, or recognition;\n\n2. A Reliable Data Source;\n\n3. Communication with a government agency responsible for the management of such DBAs or trade names;\n\n4. An Attestation Letter accompanied by documentary support; or\n\n5. A utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable.","Section 3.2.2.2","Section 3.2.2.2"]
["3.2.2.3","Verification of Country","If the subject:countryName field is present, then the CA SHALL verify the country associated with the Subject using one of the following:\n\na. the IP Address range assignment by country for either\ni. the web site’s IP address, as indicated by the DNS record for the web site or\nii. the Applicant’s IP address;\n\nb. the ccTLD of the requested Domain Name;\n\nc. information provided by the Domain Name Registrar; or\n\nd. a method identified in Section 3.2.2.1.","Section 3.2.2.3","Section 3.2.2.3"]
["3.2.2.3","Verification of Country","The CA SHOULD implement a process to screen proxy servers in order to prevent reliance upon IP addresses assigned in countries other than where the Applicant is actually located.","Section 3.2.2.3","Section 3.2.2.3"]
["3.2.2.4","Validation of Domain Authorization or Control","The CA SHALL confirm that prior to issuance, the CA has validated each Fully-Qualified Domain Name (FQDN) listed in the Certificate as follows:\n\n1. When the FQDN is not an Onion Domain Name, the CA SHALL validate the FQDN using at least one of the methods listed below; and\n\n2. When the FQDN is an Onion Domain Name, the CA SHALL validate the FQDN in accordance with Appendix B.","Section 3.2.2.4","Section 3.2.2.4","BJCA will verify each FQDN using the method specified by BR before issuing SSL Global Server Certificates.\nBJCA does not issue SSL Global Server Certificates for domain names in the form of .onion."]
["3.2.2.4","Validation of Domain Authorization or Control","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.","Section 3.2.2.4","Section 3.2.2.4"]
["3.2.2.4","Validation of Domain Authorization or Control","CAs SHALL maintain a record of which domain validation method, including relevant BR version number, they used to validate every domain.","Section 3.2.2.4","Section 3.2.2.4"]
["3.2.2.4.1","Validating the Applicant as a Domain Contact","This method has been retired and MUST NOT be used. \n\nPrior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.2","Email, Fax, SMS, or Postal Mail to Domain Contact","The Random Value MUST be sent to an email address, fax/SMS number, or postal mail address identified as a Domain Contact.\n","Section 3.2.2.4 (1)","Section 3.2.2.4 (1)"]
["3.2.2.4.2","Email, Fax, SMS, or Postal Mail to Domain Contact","The Random Value SHALL be unique in each email, fax, SMS, or postal mail.\n","Section 3.2.2.4 (1)","Section 3.2.2.4 (1)"]
["3.2.2.4.2","Email, Fax, SMS, or Postal Mail to Domain Contact","The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. \n","Section 3.2.2.4 and 3.2.2.9","Section 3.2.2.4 and 3.2.2.9 "]
["3.2.2.4.3","Phone Contact with Domain Contact","This method has been retired and MUST NOT be used. \n\nPrior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.4","Constructed Email to Domain Contact\n","The Random Value SHALL be unique in each email.\n","Section 3.2.2.9","Section 3.2.2.9"]
["3.2.2.4.4","Constructed Email to Domain Contact","The email MAY be re-sent in its entirety, including the re-use of the Random Value, provided that its entire contents and recipient SHALL remain unchanged.\n","Section 3.2.2.9","Section 3.2.2.9"]
["3.2.2.4.4","Constructed Email to Domain Contact","The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. \n","Section 3.2.2.4 ","Section 3.2.2.4 "]
["3.2.2.4.5","Domain Authorization Document","This method has been retired and MUST NOT be used. \n\nPrior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.6","Agreed-Upon Change to Website","This method has been retired and MUST NOT be used. \n\nPrior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.7","DNS Change","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\n\ni. 30 days or\n\nii. 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 these Guidelines or Section 11.14.3 of the EV Guidelines).\n","Section 3.2.2.4 (4)","Section 3.2.2.4(4)"]
["3.2.2.4.8","IP Address","Once the FQDN has been validated using this method, the CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. \n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.8","IP Address","This method is NOT suitable for validating Wildcard Domain Names.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.9","Test Certificate","This method has been retired and MUST NOT be used. \n\nPrior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.10","TLS Using a Random Number","This method has been retired and MUST NOT be used. \n\nPrior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.11","Any Other Method","This method has been retired and MUST NOT be used.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.12","Validating Applicant as a Domain Contact","Confirming the Applicant’s control over the FQDN by validating the Applicant is the Domain Contact. \n\nThis method may only be used if the CA is also the Domain Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.13","Email to DNS CAA Contact","The Random Value MUST be sent to a DNS CAA Email Contact. \n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.13","Email to DNS CAA Contact","The relevant CAA Resource Record Set MUST be found using the search algorithm defined in RFC 8659, Section 3.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.13","Email to DNS CAA Contact","The Random Value SHALL be unique in each email.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.13","Email to DNS CAA Contact","The email MAY be re-sent in its entirety, including the re-use of the Random Value, provided that its entire contents and recipient(s) SHALL remain unchanged.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.13","Email to DNS CAA Contact","The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. \n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.14","Email to DNS TXT Contact","Confirming the Applicant’s control over the FQDN by sending a Random Value via email and then receiving a confirming response utilizing the Random Value. \n\nThe Random Value MUST be sent to a DNS TXT Record Email Contact for the Authorization Domain Name selected to validate the FQDN.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.14","Email to DNS TXT Contact","The Random Value SHALL be unique in each email.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.14","Email to DNS TXT Contact","The email MAY be re-sent in its entirety, including the re-use of the Random Value, provided that its entire contents and recipient(s) SHALL remain unchanged.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.14","Email to DNS TXT Contact","The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. \n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.15","Phone Contact with Domain Contact","The Random Value MUST be returned to the CA to approve the request.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.15","Phone Contact with Domain Contact","The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.16","Phone Contact with DNS TXT Record Phone Contact","The CA MUST NOT knowingly be transferred or request to be transferred as this phone number has been specifically listed for the purposes of Domain Validation.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.16","Phone Contact with DNS TXT Record Phone Contact","In the event of reaching voicemail, the CA may leave the Random Value and the ADN(s) being validated. The Random Value MUST be returned to the CA to approve the request.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.16","Phone Contact with DNS TXT Record Phone Contact","The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. \n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.17","Phone Contact with DNS CAA Phone Contact","The relevant CAA Resource Record Set MUST be found using the search algorithm defined in RFC 8659 Section 3.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.17","Phone Contact with DNS CAA Phone Contact","The CA MUST NOT be transferred or request to be transferred as this phone number has been specifically listed for the purposes of Domain Validation.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.17","Phone Contact with DNS CAA Phone Contact","In the event of reaching voicemail, the CA may leave the Random Value and the ADN(s) being validated. The Random Value MUST be returned to the CA to approve the request.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.17","Phone Contact with DNS CAA Phone Contact","The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. \n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.18","Agreed-Upon Change to Website v2","Confirming the Applicant’s control over the FQDN by verifying that the Request Token or Random Value is contained in the contents of a file.\n\n1. The entire Request Token or Random Value MUST NOT appear in the request used to retrieve the file, and\n\n2. the CA MUST receive a successful HTTP response from the request (meaning a 2xx HTTP status code must be received).\n","Section 3.2.2.4 (3)","Section 3.2.2.4 (3)"]
["3.2.2.4.18","Agreed-Upon Change to Website v2","The file containing the Request Token or Random Number:\n\n1. MUST be located on the Authorization Domain Name, and\n\n2. MUST be located under the “/.well-known/pki-validation” directory, and\n\n3. MUST be retrieved via either the “http” or “https” scheme, and\n\n4. MUST be accessed over an Authorized Port.\n","Section 3.2.2.4 (3)","Section 3.2.2.4 (3)"]
["3.2.2.4.18","Agreed-Upon Change to Website v2","If the CA follows redirects, the following apply:\n\n1. Redirects MUST be initiated at the HTTP protocol layer.\n\na. For validations performed on or after July 1, 2021, redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in RFC 7231, Section 6.4, or a 308 HTTP status code response, as defined in RFC 7538, Section 3. Redirects MUST be to the final value of the Location HTTP response header, as defined in RFC 7231, Section 7.1.2.\n\nb. For validations performed prior to July 1, 2021, redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in RFC 7231, Section 6.4. CAs SHOULD limit the accepted status codes and resource URLs to those defined within 1.a.\n\n2. Redirects MUST be to resource URLs with either the “http” or “https” scheme.\n\n3. Redirects MUST be to resource URLs accessed via Authorized Ports.\n","Section 3.2.2.4 (3)","Section 3.2.2.4 (3)"]
["3.2.2.4.18","Agreed-Upon Change to Website v2","If a Random Value is used, then:\n\n1. The CA MUST provide a Random Value unique to the certificate request.\n\n2. The Random Value MUST 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.\n","Section 3.2.2.4 ","Section 3.2.2.4 "]
["3.2.2.4.18","Agreed-Upon Change to Website v2","The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names.\n","Section 3.2.2.6","Section 3.2.2.6"]
["3.2.2.4.19","Agreed-Upon Change to Website - ACME","The CA MUST receive a successful HTTP response from the request (meaning a 2xx HTTP status code must be received).\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.19","Agreed-Upon Change to Website - ACME","The token (as defined in RFC 8555, Section 8.3) MUST NOT be used for more than 30 days from its creation. \n\nThe CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.19","Agreed-Upon Change to Website - ACME","If the CA follows redirects, the following apply:\n\n1. Redirects MUST be initiated at the HTTP protocol layer.\n\na. For validations performed on or after July 1, 2021, redirects MUST be the result of a 301, 302, or 307 HTTP status code response, as defined in RFC 7231, Section 6.4, or a 308 HTTP status code response, as defined in RFC 7538, Section 3. Redirects MUST be to the final value of the Location HTTP response header, as defined in RFC 7231, Section 7.1.2.\n\nb. For validations performed prior to July 1, 2021, redirects MUST be the result of an HTTP status code result within the 3xx Redirection class of status codes, as defined in RFC 7231, Section 6.4. CAs SHOULD limit the accepted status codes and resource URLs to those defined within 1.a.\n\n2. Redirects MUST be to resource URLs with either the “http” or “https” scheme.\n\n3. Redirects MUST be to resource URLs accessed via Authorized Ports.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.19","Agreed-Upon Change to Website - ACME","The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.20","TLS Using ALPN","The token (as defined in RFC 8737, Section 3) MUST NOT be used for more than 30 days from its creation. \n\nThe CPS MAY specify a shorter validity period for the token, in which case the CA MUST follow its CPS.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.4.20","TLS Using ALPN","Once the FQDN has been validated using this method, the CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method.\n","N/A","N/A","We don't use this domain validation method."]
["3.2.2.5","Authentication for an IP Address","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.\n","Section 3.2.2.5","Section 3.2.2.5"]
["3.2.2.5","Authentication for an IP Address","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. \n","Section 4.2.1","Section 4.2.1"]
["3.2.2.5","Authentication for an IP Address","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.\n","Section 3.2.2.5","Section 3.2.2.5"]
["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.\n\nThe Request Token or Random Value MUST NOT appear in the request.\n","Section 3.2.2.5(1)","Section 3.2.2.5(1)"]
["3.2.2.5.1","Agreed-Upon Change to Website","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\n\ni. 30 days or\n\nii. 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).\n","Section 3.2.2.5(1)","Section 3.2.2.5(1)"]
["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.\n","Section 3.2.2.5(2)","Section 3.2.2.5(2)"]
["3.2.2.5.2","Email, Fax, SMS, or Postal Mail to IP Address Contact","The Random Value SHALL be unique in each email, fax, SMS, or postal mail.\n","Section 3.2.2.9","Section 3.2.2.9"]
["3.2.2.5.2","Email, Fax, SMS, or Postal Mail to IP Address Contact","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.\n","Section 3.2.2.5","Section 3.2.2.5 "]
["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.\n","Section 3.2.2.5(3)","Section 3.2.2.5(3)"]
["3.2.2.5.4","Any Other Method","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.\n","N/A","N/A","BJCA does not use any other method than the validation method specified by BR."]
["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. \n\nThe CA MUST place the call to a phone number identified by the IP Address Registration Authority as the IP Address Contact.\n","Section 3.2.2.5 (4)","Section 3.2.2.5 (4)"]
["3.2.2.5.5","Phone Contact with IP Address Contact\n","Each phone call SHALL be made to a single number.\n","Section 3.2.2.5 (4)","Section 3.2.2.5 (4)"]
["3.2.2.5.5","Phone Contact with 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.\n","N/A","N/A","We don't use this IP Address validation method."]
["3.2.2.5.5","Phone Contact with IP Address Contact","The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation.\n","Section 3.2.2.5","Section 3.2.2.5"]
["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 draft 04 of “ACME IP Identifier Validation Extension,” available at https://tools.ietf.org/html/draft-ietf-acme-ip-04#section-4.\n","N/A","N/A","We don't use this IP Address validation method."]
["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 draft 04 of “ACME IP Identifier Validation Extension,” available at https://tools.ietf.org/html/draft-ietf-acme-ip-04#section-4.\n","N/A","N/A","We don't use this IP Address validation method."]
["3.2.2.6","Wildcard Domain Validation","Before issuing a Wildcard Certificate, the CA MUST establish and follow a documented procedure that determines if the FQDN portion of any Wildcard Domain Name in the Certificate is “registry-controlled” or is a “public suffix” (e.g. “*.com”, “*.co.uk”, see RFC 6454 Section 8.2 for further explanation).\n","Section 3.2.2.6","Section 3.2.2.6"]
["3.2.2.6","Wildcard Domain Validation","If the FQDN portion of any Wildcard Domain Name is “registry-controlled” or is a “public suffix”, CAs MUST refuse issuance unless the Applicant proves its rightful control of the entire Domain Namespace. (e.g. CAs MUST NOT issue “*.co.uk” or “*.local”, but MAY issue “*.example.com” to Example Co.).\n","Section 3.2.2.6","Section 3.2.2.6"]
["3.2.2.7","Data Source Accuracy","Prior to using any data source as a Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.\n","Section 3.2.2.7","Section 3.2.2.7"]
["3.2.2.8","CAA Records","As part of the issuance process, the CA MUST retrieve and process CAA records in accordance with RFC 8659 for each dNSName in the subjectAltName extension that does not contain an Onion Domain Name.\n","Section 3.2.2.8 and 4.2.1","Section 3.2.2.8 and 4.2.1"]
["3.2.2.8","CAA Records","If the CA issues, they MUST do so within the TTL of the CAA record, or 8 hours, whichever is greater.\n","Section 3.2.2.8","Section 3.2.2.8"]
["3.2.2.8","CAA Records","When processing CAA records, CAs MUST process the issue, issuewild, and iodef property tags as specified in RFC 8659, although they are not required to act on the contents of the iodef property tag.\n","Section 3.2.2.8","Section 3.2.2.8"]
["3.2.2.8","CAA Records","Additional property tags MAY be supported, but MUST NOT conflict with or supersede the mandatory property tags set out in this document. \n","Section 3.2.2.8","Section 3.2.2.8","CPS does not show disclosure and can support Additional property tags in internal practice, but it must not conflict with or supersede the mandatory property tags set out in BR."]
["3.2.2.8","CAA Records","CAs MUST respect the critical flag and not issue a certificate if they encounter an unrecognized property tag with this flag set.\n","Section 3.2.2.8","Section 3.2.2.8"]
["3.2.2.8","CAA Records","RFC 8659 requires that CAs “MUST NOT issue a certificate unless the CA determines that either \n\n(1) the certificate request is consistent with the applicable CAA RRset or \n\n(2) an exception specified in the relevant CP or CPS applies.”\n","Section 3.2.2.8","Section 3.2.2.8"]
["3.2.2.8","CAA Records","For issuances conforming to these Baseline Requirements, CAs MUST NOT rely on any exceptions specified in their CP or CPS unless they are one of the following:\n\n• CAA checking is optional for certificates for which a Certificate Transparency pre-certificate was created and logged in at least two public logs, and for which CAA was checked.\n\n• CAA checking is optional for certificates issued by a Technically Constrained Subordinate CA Certificate as set out in Section 7.1.5, where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant.\n\n• For certificates issued prior to July 1, 2021, CAA checking is optional if the CA or an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) of the domain’s DNS.\n","Section 3.2.2.8","Section 3.2.2.8"]
["3.2.2.8","CAA Records","CAs MUST document potential issuances that were prevented by a CAA record in sufficient detail to provide feedback to the CAB Forum on the circumstances, and SHOULD dispatch reports of such issuance requests to the contact(s) stipulated in the CAA iodef record(s), if present.\n","Section 3.2.2.8","Section 3.2.2.8"]
["3.2.3","Authentication of individual identity","If an Applicant subject to this Section 3.2.3 is a natural person, then the CA SHALL verify the Applicant’s name, Applicant’s address, and the authenticity of the certificate request.\n","Section 3.2.3","Section 3.2.3"]
["3.2.3","Authentication of individual identity","The CA SHALL verify the Applicant’s name using a legible copy, which discernibly shows the Applicant’s face, of at least one currently valid government-issued photo ID (passport, drivers license, military ID, national ID, or equivalent document type).\n","Section 3.2.3","Section 3.2.3"]
["3.2.3","Authentication of individual identity","The CA SHALL inspect the copy for any indication of alteration or falsification.\n","Section 3.2.3","Section 3.2.3 (1)"]
["3.2.3","Authentication of individual identity","The CA SHALL verify the Applicant’s address using a form of identification that the CA determines to be reliable, such as a government ID, utility bill, or bank or credit card statement.\n","Section 3.2.3","Section 3.2.3"]
["3.2.3","Authentication of individual identity","The CA SHALL verify the certificate request with the Applicant using a Reliable Method of Communication.\n","Section 3.2.3","Section 3.2.3 (2)"]
["3.2.4","Non-verified subscriber information","No stipulation (implied).\n"]
["3.2.5","Validation of authority","If the Applicant for a Certificate containing Subject Identity Information is an organization, the CA SHALL use a Reliable Method of Communication to verify the authenticity of the Applicant Representative’s certificate request.\n","Section 3.2.5","Section 3.2.5"]
["3.2.5","Validation of authority","In addition, the CA SHALL establish a process that allows an Applicant to specify the individuals who may request Certificates.\n","Section 3.2.5","Section 3.2.5"]
["3.2.5","Validation of authority","If an Applicant specifies, in writing, the individuals who may request a Certificate, then the CA SHALL NOT accept any certificate requests that are outside this specification.\n","Section 3.2.5","Section 3.2.5"]
["3.2.5","Validation of authority","The CA SHALL provide an Applicant with a list of its authorized certificate requesters upon the Applicant’s verified written request.\n","Section 3.2.5","Section 3.2.5"]
["3.2.6","Criteria for Interoperation or Certification","The CA SHALL disclose all Cross Certificates that identify the CA as the Subject, provided that the CA arranged for or accepted the establishment of the trust relationship (i.e. the Cross Certificate at issue).\n","Section 3.2.6","Section 3.2.6"]
[3.3,"Identification and authentication for re-key requests\n","No stipulation (implied).\n"]
["3.3.1","Identification and authentication for routine re-key\n","No stipulation (implied).\n"]
["3.3.2","Identification and authentication for re-key after revocation\n","No stipulation (implied).\n"]
[3.4,"Identification and authentication for revocation request\n","No stipulation (implied).\n"]
["4. Certificate Life-cycle Operational Requirements"]
[4.1,"Certificate Application","No stipulation (implied).\n"]
["4.1.1","Who can submit a certificate application\n","No stipulation.\n"]
["4.1.2","Enrollment process and responsibilities","Prior to the issuance of a Certificate, the CA SHALL obtain the following documentation from the Applicant:\n\n1. A certificate request, which may be electronic; and\n\n2. An executed Subscriber Agreement or Terms of Use, which may be electronic. The CA SHOULD obtain any additional documentation the CA determines necessary to meet these Requirements.\n","Section 4.1.2","Section 4.1.2"]
["4.1.2","Enrollment process and responsibilities","Prior to the issuance of a Certificate, the CA SHALL obtain from the Applicant a certificate request in a form prescribed by the CA and that complies with these Requirements.\n","Section 4.1.2","Section 4.1.2"]
["4.1.2","Enrollment process and responsibilities","The certificate request MUST contain a request from, or on behalf of, the Applicant for the issuance of a Certificate, and a certification by, or on behalf of, the Applicant that all of the information contained therein is correct.\n","Section 4.1.2","Section 4.1.2"]
[4.2,"Certificate application processing","No stipulation (implied).\n"]
["4.2.1","Performing identification and authentication functions","In cases where the certificate request does not contain all the necessary information about the Applicant, the CA SHALL obtain the remaining information from the Applicant or, having obtained it from a reliable, independent, third-party data source, confirm it with the Applicant.\n","Section 4.2.1","Section 4.2.1"]
["4.2.1","Performing identification and authentication functions","The CA SHALL establish and follow a documented procedure for verifying all data requested for inclusion in the Certificate by the Applicant.\n","Section 4.2.1","Section 4.2.1"]
["4.2.1","Performing identification and authentication functions","Applicant information MUST include, but not be limited to, at least one Fully-Qualified Domain Name or IP address to be included in the Certificate’s subjectAltName extension.\n","Section 3.1.1 and 4.2.1","Section 3.1.1 and 4.2.1"]
["4.2.1","Performing identification and authentication functions","For validation of Domain Names and IP Addresses according to Section 3.2.2.4 and 3.2.2.5, any reused data, document, or completed validation MUST be obtained no more than 398 days prior to issuing the Certificate.\n\nIn no case may a prior validation be reused if any data or document used in the prior validation was obtained more than the maximum time permitted for reuse of the data or document prior to issuing the Certificate.\n","Section 4.2.1 and 6.3.2","Section 4.2.1 and 6.3.2"]
["4.2.1","Performing identification and authentication functions","The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements.\n","Section 4.2.2","Section 4.2.2"]
["4.2.1","Performing identification and authentication functions","If a Delegated Third Party fulfills any of the CA’s obligations under this section, the CA SHALL verify that the process used by the Delegated Third Party to identify and further verify High Risk Certificate Requests provides at least the same level of assurance as the CA’s own processes.","N/A","N/A","Besides acting as a CA, BJCA will also act as a RA and no third party will be entrusted as the RA."]
["4.2.2","Approval or rejection of certificate applications","CAs SHALL NOT issue Certificates containing Internal Names or Reserved IP Addresses (see Section 7.1.4.2.1).\n","Section 3.2.2.5","Section 3.2.2.5"]
["4.2.3","Time to process certificate applications\n","No stipulation.\n"]
[4.3,"Certificate issuance","No stipulation (implied).\n"]
["4.3.1","CA actions during certificate issuance","Certificate issuance by the Root CA SHALL require an individual authorized by the CA (i.e. the CA system operator, system officer, or PKI administrator) to deliberately issue a direct command in order for the Root CA to perform a certificate signing operation.\n","Section 4.3.1","Section 4.3.1"]
["4.3.2","Notification to subscriber by the CA of issuance of certificate\n","No stipulation."]
[4.4,"Certificate acceptance","No stipulation (implied).\n"]
["4.4.1","Conduct constituting certificate acceptance\n","No stipulation."]
["4.4.2","Publication of the certificate by the CA\n","No stipulation."]
["4.4.3","Notification of certificate issuance by the CA to other entities\n","No stipulation."]
[4.5,"Key pair and certificate usage","No stipulation (implied).\n"]
["4.5.1","Subscriber private key and certificate usage\n","See Section 9.6.3, provisions 2. and 4.\n","Section 9.6.3(5) and 9.6.3(8)","Section 9.6.3(5) and 9.6.3(8)"]
["4.5.2","Relying party public key and certificate usage\n","No stipulation."]
[4.6,"Certificate renewal","No stipulation (implied).\n"]
["4.6.1","Circumstance for certificate renewal\n","No stipulation."]
["4.6.2","Who may request renewal","No stipulation.\n"]
["4.6.3","Processing certificate renewal requests\n","No stipulation."]
["4.6.4","Notification of new certificate issuance to subscriber\n","No stipulation."]
["4.6.5","Conduct constituting acceptance of a renewal certificate\n","No stipulation."]
["4.6.6","Publication of the renewal certificate by the CA\n","No stipulation."]
["4.6.7","Notification of certificate issuance by the CA to other entities\n","No stipulation."]
[4.7,"Certificate re-key","No stipulation (implied).\n"]
["4.7.1","Circumstance for certificate re-key","No stipulation.\n"]
["4.7.2","Who may request certification of a new public key\n","No stipulation."]
["4.7.3","Processing certificate re-keying requests\n","No stipulation."]
["4.7.4","Notification of new certificate issuance to subscriber\n","No stipulation."]
["4.7.5","Conduct constituting acceptance of a re-keyed certificate\n","No stipulation."]
["4.7.6","Publication of the re-keyed certificate by the CA\n","No stipulation."]
["4.7.7","Notification of certificate issuance by the CA to other entities\n","No stipulation."]
[4.8,"Certificate modification","No stipulation (implied).\n"]
["4.8.1","Circumstance for certificate modification\n","No stipulation."]
["4.8.2","Who may request certificate modification\n","No stipulation."]
["4.8.3","Processing certificate modification requests\n","No stipulation."]
["4.8.4","Notification of new certificate issuance to subscriber\n","No stipulation."]
["4.8.5","Conduct constituting acceptance of modified certificate\n","No stipulation."]
["4.8.6","Publication of the modified certificate by the CA\n","No stipulation."]
["4.8.7","Notification of certificate issuance by the CA to other entities\n","No stipulation."]
[4.9,"Certificate revocation and suspension\n","No stipulation (implied)."]
["4.9.1","Circumstances for revocation","No stipulation (implied).\n"]
["4.9.1.1","Reasons for Revoking a Subscriber Certificate","The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:\n\n1. The Subscriber requests in writing that the CA revoke the Certificate;\n\n2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization;\n\n3. The CA obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise;\n\n4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys);\n\n5. The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon.\n","Section 4.9.1.1","Section 4.9.1.1"]
["4.9.1.1","Reasons for Revoking a Subscriber Certificate","The CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days if one or more of the following occurs:\n\n1. The Certificate no longer complies with the requirements of Section 6.1.5 and Section 6.1.6;\n\n2. The CA obtains evidence that the Certificate was misused;\n\n3. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use;\n\n4. The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name Registrant’s right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name);\n\n5. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name;\n\n6. The CA is made aware of a material change in the information contained in the Certificate;\n\n7. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement;\n\n8. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate;\n\n9. The CA’s right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository;\n\n10. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or\n\n11. The CA is made aware of a demonstrated or proven method that exposes the Subscriber’s Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed.","Section 4.9.1.1","Section 4.9.1.1"]
["4.9.1.2","Reasons for Revoking a Subordinate CA Certificate","The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days if one or more of the following occurs:\n\n1. The Subordinate CA requests revocation in writing;\n\n2. The Subordinate CA notifies the Issuing CA that the original certificate request was not authorized and does not retroactively grant authorization;\n\n3. The Issuing CA obtains evidence that the Subordinate CA’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer complies with the requirements of Section 6.1.5 and Section 6.1.6;\n\n4. The Issuing CA obtains evidence that the Certificate was misused;\n\n5. The Issuing CA is made aware that the Certificate was not issued in accordance with or that Subordinate CA has not complied with this document or the applicable Certificate Policy or Certification Practice Statement;\n\n6. The Issuing CA determines that any of the information appearing in the Certificate is inaccurate or misleading;\n\n7. The Issuing CA or Subordinate CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate;\n\n8. The Issuing CA’s or Subordinate CA’s right to issue Certificates under these Requirements expires or is revoked or terminated, unless the Issuing CA has made arrangements to continue maintaining the CRL/OCSP Repository; or\n\n9. Revocation is required by the Issuing CA’s Certificate Policy and/or Certification Practice Statement.\n","Section 4.9.1.2","Section 4.9.1.2"]
["4.9.2","Who can request revocation","N/A (no requirements included in this section)\n"]
["4.9.3","Procedure for revocation request","The CA SHALL provide a process for Subscribers to request revocation of their own Certificates. The process MUST be described in the CA’s Certificate Policy or Certification Practice Statement. \n","Section 4.9.3.1","Section 4.9.3.1"]
["4.9.3","Procedure for revocation request","The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports.\n","Section 4.9.3.1 and 4.9.3.2","Section 4.9.3.1 and 4.9.3.2"]
["4.9.3","Procedure for revocation request","The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates.\n","Section 4.9.3.2","Section 4.9.3.2"]
["4.9.3","Procedure for revocation request","The CA SHALL publicly disclose the instructions through a readily accessible online means and in Section 1.5.2 of their CPS.\n","Section 1.5.2.1 and 4.9.3.1 ","Section 1.5.2.1 and 4.9.3.1 "]
["4.9.4","Revocation request grace period","No stipulation.\n"]
["4.9.5","Time within which CA must process the revocation request","Within 24 hours after receiving a Certificate Problem Report, the CA SHALL investigate the facts and circumstances related to a Certificate Problem Report and provide a preliminary report on its findings to both the Subscriber and the entity who filed the Certificate Problem Report. \n","Section 4.9.5","Section 4.9.5"]
["4.9.5","Time within which CA must process the revocation request","After reviewing the facts and circumstances, the CA SHALL work with the Subscriber and any entity reporting the Certificate Problem Report or other revocation-related notice to establish whether or not the certificate will be revoked, and if so, a date which the CA will revoke the certificate.\n","Section 4.9.3.2 and 4.9.5","Section 4.9.3.2 and 4.9.5"]
["4.9.5","Time within which CA must process the revocation request","The period from receipt of the Certificate Problem Report or revocation-related notice to published evocation MUST NOT exceed the time frame set forth in Section 4.9.1.1.\n","Section 4.9.1.1 and 4.9.5","Section 4.9.1.1 and 4.9.5"]
["4.9.6","Revocation checking requirement for relying parties\n","No stipulation."]
["4.9.7","CRL issuance frequency (if applicable)","For the status of Subscriber Certificates:\n\nIf the CA publishes a CRL, then the CA SHALL update and reissue CRLs at least once every seven days, and the value of the nextUpdate field MUST NOT be more than ten days beyond the value of the thisUpdate field.\n","Section 4.9.7","Section 4.9.7"]
["4.9.7","CRL issuance frequency (if applicable)","For the status of Subordinate CA Certificates:\n\nThe CA SHALL update and reissue CRLs at least:\n\ni. once every twelve months; and\nii. within 24 hours after revoking a Subordinate CA Certificate.\n\nThe value of the nextUpdate field MUST NOT be more than twelve months beyond the value of the thisUpdate field.\n","Section 4.9.7","Section 4.9.7"]
["4.9.8","Maximum latency for CRLs (if applicable)\n","No stipulation."]
["4.9.9","On-line revocation/status checking availability","OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST either:\n\n1. Be signed by the CA that issued the Certificates whose revocation status is being checked, or\n\n2. Be signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose revocation status is being checked. \n\nIn the latter case, the OCSP signing Certificate MUST contain an extension of type id-pkix-ocsp-nocheck, as defined by RFC6960.\n","Section 4.9.9","Section 4.9.9"]
["4.9.10","On-line revocation checking requirements","OCSP responders operated by the CA SHALL support the HTTP GET method, as described in RFC 6960 and/or RFC 5019.\n","Section 4.9.10","Section 4.9.10"]
["4.9.10","On-line revocation checking requirements","The validity interval of an OCSP response is the difference in time between the thisUpdate and nextUpdate field, inclusive. For purposes of computing differences, a difference of 3,600 seconds shall be equal to one hour, and a difference of 86,400 seconds shall be equal to one day, ignoring leap-seconds.\n","Section 4.9.10","Section 4.9.10","CPS does not show disclosure, and we comply with this requirement in internal practice."]
["4.9.10","On-line revocation checking requirements","For the status of Subscriber Certificates:\n\n1. OCSP responses MUST have a validity interval greater than or equal to eight hours;\n\n2. OCSP responses MUST have a validity interval less than or equal to ten days;\n\n3. For OCSP responses with validity intervals less than sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol prior to one-half of the validity period before the nextUpdate.\n\n4. For OCSP responses with validity intervals greater than or equal to sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate.\n","Section 4.9.10","Section 4.9.10"]
["4.9.10","On-line revocation checking requirements","For the status of Subordinate CA Certificates:\n\nThe CA SHALL update information provided via an Online Certificate Status Protocol\n\ni. at least every twelve months; and\nii. within 24 hours after revoking a Subordinate CA Certificate.\n","Section 4.9.10","Section 4.9.10"]
["4.9.10","On-line revocation checking requirements","If the OCSP responder receives a request for the status of a certificate serial number that is “unused”, then the responder SHOULD NOT respond with a “good” status. If the OCSP responder is for a CA that is not Technically Constrained in line with Section 7.1.5, the responder MUST NOT respond with a “good” status for such requests.\n","Section 4.9.10","Section 4.9.10"]
["4.9.10","On-line revocation checking requirements","A certificate serial number within an OCSP request is one of the following three options:\n\n1. “assigned” if a Certificate with that serial number has been issued by the Issuing CA, using any current or previous key associated with that CA subject; or\n\n2. “reserved” if a Precertificate [RFC6962] with that serial number has been issued by \na. the Issuing CA; or\nb. a Precertificate Signing Certificate [RFC6962] associated with the Issuing CA; or\n\n3. “unused” if neither of the previous conditions are met.\n","Section 4.9.10","Section 4.9.10","CPS does not show disclosure, and we comply with this requirement in internal practice."]
["4.9.11","Other forms of revocation advertisements available\n","No stipulation."]
["4.9.12","Special requirements re key compromise\n","See Section 4.9.1.\n","Section 4.9.1.1, 4.9.1.2 and 4.9.12","Section 4.9.1.1, 4.9.1.2 and 4.9.12"]
["4.9.13","Circumstances for suspension","The Repository MUST NOT include entries that indicate that a Certificate is suspended.\n","N/A","N/A","Certificate suspension is not supported."]
["4.9.14","Who can request suspension","Not applicable.\n"]
["4.9.15","Procedure for suspension request","Not applicable.\n"]
["4.9.16","Limits on suspension period","Not applicable.\n"]
["4.10","Certificate status services","No stipulation (implied).\n"]
["4.10.1","Operational characteristics","Revocation entries on a CRL or OCSP Response MUST NOT be removed until after the Expiry Date of the revoked Certificate.\n","Section 4.10.1","Section 4.10.1"]
["4.10.2","Service availability","The CA SHALL operate and maintain its CRL and OCSP capability with resources sufficient to provide a response time of ten seconds or less under normal operating conditions.\n","Section 4.10.2","Section 4.10.2"]
["4.10.2","Service availability","The CA SHALL maintain an online 24x7 Repository that application software can use to automatically check the current status of all unexpired Certificates issued by the CA.\n","Section 4.10.2","Section 4.10.2"]
["4.10.2","Service availability","The CA SHALL maintain a continuous 24x7 ability to respond internally to a high-priority Certificate Problem Report, and where appropriate, forward such a complaint to law enforcement authorities, and/or revoke a Certificate that is the subject of such a complaint.\n","Section 4.10.2","Section 4.10.2","CPS does not show disclosure, and we comply with this requirement in internal practice."]
["4.10.3","Optional features","No stipulation.\n"]
[4.11,"End of subscription","No stipulation.\n"]
[4.12,"Key escrow and recovery","No stipulation (implied).\n"]
["4.12.1","Key escrow and recovery policy and practices\n","No stipulation."]
["4.12.2","Session key encapsulation and recovery policy and practices\n","Not applicable.\n"]
["5. Management, Operational, and Physical Controls"]
[5,"MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS","The CA/Browser Forum’s Network and Certificate System Security Requirements are incorporated by reference as if fully set forth herein.\n","Section 1.5.5","Section 1.5.5"]
[5,"MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS","The CA SHALL develop, implement, and maintain a comprehensive security program designed to:\n\n1. Protect the confidentiality, integrity, and availability of Certificate Data and Certificate Management Processes;\n\n2. Protect against anticipated threats or hazards to the confidentiality, integrity, and availability of the Certificate Data and Certificate Management Processes;\n\n3. Protect against unauthorized or unlawful access, use, disclosure, alteration, or destruction of any Certificate Data or Certificate Management Processes;\n\n4. Protect against accidental loss or destruction of, or damage to, any Certificate Data or Certificate Management Processes; and\n\n5. Comply with all other security requirements applicable to the CA by law.\n","Section 6.6.2 and 6.6.3","Section 6.6.2 and 6.6.3"]
[5,"MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS","The Certificate Management Process MUST include:\n\n1. physical security and environmental controls;\n\n2. system integrity controls, including configuration management, integrity maintenance of trusted code, and malware detection/prevention;\n\n3. network security and firewall management, including port restrictions and IP address filtering;\n\n4. user management, separate trusted-role assignments, education, awareness, and training; and\n\n5. logical access controls, activity logging, and inactivity time-outs to provide individual accountability.\n","Section 6.5.1 and 6.7","Section 6.5.1 and 6.7"]
[5,"MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS","The CA’s security program MUST include an annual Risk Assessment that:\n\n1. Identifies foreseeable internal and external threats that could result in unauthorized access, disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate Management Processes;\n\n2. Assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity of the Certificate Data and Certificate Management Processes; and\n\n3. Assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter such threats.\n","Section 5.4.8","Section 5.4.8"]
[5,"MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS","Based on the Risk Assessment, the CA SHALL develop, implement, and maintain a security plan consisting of security procedures, measures, and products designed to achieve the objectives set forth above and to manage and control the risks identified during the Risk Assessment, commensurate with the sensitivity of the Certificate Data and Certificate Management Processes.\n","Section 5.4.8","Section 5.4.8"]
[5,"MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS","The security plan MUST include administrative, organizational, technical, and physical safeguards appropriate to the sensitivity of the Certificate Data and Certificate Management Processes.\n","Section 5.4.8","Section 5.4.8"]
[5,"MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS","The security plan MUST also take into account then-available technology and the cost of implementing the specific measures, and SHALL implement a reasonable level of security appropriate to the harm that might result from a breach of security and the nature of the data to be protected.\n","Section 5.4.8","Section 5.4.8"]
[5.1,"PHYSICAL SECURITY CONTROLS","No stipulation (implied)."]
["5.1.1","Site location and construction","No stipulation (implied).\n"]
["5.1.2","Physical access","No stipulation (implied).\n"]
["5.1.3","Power and air conditioning","No stipulation (implied).\n"]
["5.1.4","Water exposures","No stipulation (implied).\n"]
["5.1.5","Fire prevention and protection","No stipulation (implied).\n"]
["5.1.6","Media storage","No stipulation (implied).\n"]
["5.1.7","Waste disposal","No stipulation (implied).\n"]
["5.1.8","Off-site backup","No stipulation (implied).\n"]
[5.2,"Procedural controls","No stipulation (implied).\n"]
["5.2.1","Trusted roles","No stipulation (implied).\n"]
["5.2.2","Number of Individuals Required per Task","The CA Private Key SHALL be backed up, stored, and recovered only by personnel in trusted roles using, at least, dual control in a physically secured environment.\n","Section 5.2.2 and 6.2.2","Section 5.2.2 and 6.2.2"]
["5.2.3","Identification and authentication for each role\n","No stipulation (implied)."]
["5.2.4","Roles requiring separation of duties\n","No stipulation (implied)."]
[5.3,"Personnel controls","No stipulation (implied).\n"]
["5.3.1","Qualifications, experience, and clearance requirements","Prior to the engagement of any person in the Certificate Management Process, whether as an employee, agent, or an independent contractor of the CA, the CA SHALL verify the identity and trustworthiness of such person.\n","Section 5.3.1","Section 5.3.1"]
["5.3.2","Background check procedures","No stipulation (implied).\n"]
["5.3.3","Training Requirements and Procedures","The CA SHALL provide all personnel performing information verification duties with skills-training that covers basic Public Key Infrastructure knowledge, authentication and vetting policies and procedures (including the CA’s Certificate Policy and/or Certification Practice Statement), common threats to the information verification process (including phishing and other social engineering tactics), and these Requirements.\n","Section 5.3.3","Section 5.3.3"]
["5.3.3","Training Requirements and Procedures","The CA SHALL maintain records of such training and ensure that personnel entrusted with Validation Specialist duties maintain a skill level that enables them to perform such duties satisfactorily.\n","Section 5.3.3","Section 5.3.3"]
["5.3.3","Training Requirements and Procedures","The CA SHALL document that each Validation Specialist possesses the skills required by a task before allowing the Validation Specialist to perform that task.\n","Section 5.3.3 and 5.3.1","Section 5.3.3 and 5.3.1"]
["5.3.3","Training Requirements and Procedures","The CA SHALL require all Validation Specialists to pass an examination provided by the CA on the information verification requirements outlined in these Requirements.\n","Section 5.3.3 and 5.3.1","Section 5.3.3 and 5.3.1"]
["5.3.4","Retraining frequency and requirements","All personnel in Trusted roles SHALL maintain skill levels consistent with the CA’s training and performance programs.\n","Section 5.3.4","Section 5.3.4"]
["5.3.5","Job rotation frequency and sequence\n","No stipulation (implied)."]
["5.3.6","Sanctions for unauthorized actions","No stipulation (implied).\n"]
["5.3.7","Independent Contractor Controls","The CA SHALL verify that the Delegated Third Party’s personnel involved in the issuance of a Certificate meet the training and skills requirements of Section 5.3.3 and the document retention and event logging requirements of Section 5.4.1.\n","Section 5.3.7","Section 5.3.7"]
["5.3.8","Documentation supplied to personnel\n","No stipulation (implied)."]
[5.4,"Audit logging procedures","No stipulation (implied).\n"]
["5.4.1","Types of events recorded","The CA and each Delegated Third Party SHALL record events related to the security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems.\n","Section 5.4.1","Section 5.4.1"]
["5.4.1","Types of events recorded","The CA and each Delegated Third Party SHALL record events related to their actions taken to process a certificate request and to issue a Certificate, including all information generated and documentation received in connection with the certificate request; the time and date; and the personnel involved.\n","Section 5.4.1","Section 5.4.1"]
["5.4.1","Types of events recorded","The CA SHALL make these records available to its Qualified Auditor as proof of the CA’s compliance with these Requirements.\n","Section 5.4.3","Section 5.4.3"]
["5.4.1","Types of events recorded","The CA SHALL record at least the following events:\n\n1. CA certificate and key lifecycle events, including:\n- 1. Key generation, backup, storage, recovery, archival, and destruction;\n- 2. Certificate requests, renewal, and re-key requests, and revocation;\n- 3. Approval and rejection of certificate requests;\n- 4. Cryptographic device lifecycle management events;\n- 5. Generation of Certificate Revocation Lists;\n- 6. Signing of OCSP Responses (as described in Section 4.9 and Section 4.10); and\n- 7. Introduction of new Certificate Profiles and retirement of existing Certificate Profiles.\n\n2. Subscriber Certificate lifecycle management events, including:\n- 1. Certificate requests, renewal, and re-key requests, and revocation;\n- 2. All verification activities stipulated in these Requirements and the CA’s Certification Practice Statement;\n- 3. Approval and rejection of certificate requests;\n- 4. Issuance of Certificates;\n- 5. Generation of Certificate Revocation Lists; and\n- 6. Signing of OCSP Responses (as described in Section 4.9 and Section 4.10).\n\n3. Security events, including:\n- 1. Successful and unsuccessful PKI system access attempts;\n- 2. PKI and security system actions performed;\n- 3. Security profile changes;\n- 4. Installation, update and removal of software on a Certificate System;\n- 5. System crashes, hardware failures, and other anomalies;\n- 6. Firewall and router activities; and\n- 7. Entries to and exits from the CA facility.\n","Section 5.4.1","Section 5.4.1"]
["5.4.1","Types of events recorded","Log records MUST include the following elements:\n\n1. Date and time of record;\n\n2. Identity of the person making the journal record; and\n\n3. Description of the record.\n","Section 5.4.1","Section 5.4.1"]
["5.4.2","Frequency for Processing and Archiving Audit Logs\n","No stipulation (implied)."]
["5.4.3","Retention Period for Audit Logs","The CA and each Delegated Third Party SHALL retain, for at least two (2) years:\n\n1. CA certificate and key lifecycle management event records (as set forth in Section 5.4.1 (1)) after the later occurrence of:\n- 1. the destruction of the CA Private Key; or\n- 2. the revocation or expiration of the final CA Certificate in that set of Certificates that have an X.509v3 basicConstraints extension with the cA field set to true and which share a common Public Key corresponding to the CA Private Key;\n\n2. Subscriber Certificate lifecycle management event records (as set forth in Section 5.4.1 (2)) after the revocation or expiration of the Subscriber Certificate;\n\n3. Any security event records (as set forth in Section 5.4.1 (3)) after the event occurred.\n","Section 5.4.3","Section 5.4.3"]
["5.4.4","Protection of Audit Log","No stipulation (implied).\n"]
["5.4.5","Audit Log Backup Procedures","No stipulation (implied).\n"]
["5.4.6","Audit Log Accumulation System (internal vs. external)\n","No stipulation (implied)."]
["5.4.7","Notification to event-causing subject\n","No stipulation (implied)."]
["5.4.8","Vulnerability assessments","Additionally, the CA’s security program MUST include an annual Risk Assessment that:\n\n1. Identifies foreseeable internal and external threats that could result in unauthorized access, disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate Management Processes;\n\n2. Assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity of the Certificate Data and Certificate Management Processes; and\n\n3. Assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter such threats.\n","Section 5.4.8","Section 5.4.8"]
[5.5,"Records archival","No stipulation (implied).\n"]
["5.5.1","Types of records archived","The CA and each Delegated Third Party SHALL archive all audit logs (as set forth in Section 5.4.1).\n\nAdditionally, the CA and each Delegated Third Party SHALL archive: 1. Documentation related to the security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems; and 2. Documentation related to their verification, issuance, and revocation of certificate requests and Certificates.\n","Section 5.5.1","Section 5.5.1"]
["5.5.2","Retention period for archive","Archived audit logs (as set forth in Section 5.5.1 SHALL be retained for a period of at least two (2) years from their record creation timestamp, or as long as they are required to be retained per Section 5.4.3, whichever is longer.\n","Section 5.5.2","Section 5.5.2"]
["5.5.2","Retention period for archive","Additionally, the CA and each Delegated Third Party SHALL retain, for at least two (2) years: 1. All archived documentation related to the security of Certificate Systems, Certificate Management Systems, Root CA Systems and Delegated Third Party Systems (as set forth in Section 5.5.1); and 2. All archived documentation relating to the verification, issuance, and revocation of certificate requests and Certificates (as set forth in Section 5.5.1) after the later occurrence of: 1. such records and documentation were last relied upon in the verification, issuance, or revocation of certificate requests and Certificates; or 2. the expiration of the Subscriber Certificates relying upon such records and documentation.\n","Section 5.5.2","Section 5.5.2"]
["5.5.3","Protection of archive","No stipulation (implied).\n"]
["5.5.4","Archive backup procedures","No stipulation (implied).\n"]
["5.5.5","Requirements for time-stamping of records\n","No stipulation (implied).\n"]
["5.5.6","Archive collection system (internal or external)\n","No stipulation (implied)."]
["5.5.7","Procedures to obtain and verify archive information\n","No stipulation (implied)."]
[5.6,"Key changeover","No stipulation (implied).\n"]
[5.7,"Compromise and disaster recovery","No stipulation (implied).\n"]
["5.7.1","Incident and compromise handling procedures","CA organizations shall have an Incident Response Plan and a Disaster Recovery Plan.\n","Section 5.7.1","Section 5.7.1"]
["5.7.1","Incident and compromise handling procedures","The CA SHALL document business continuity and disaster recovery procedures designed to notify and reasonably protect Application Software Suppliers, Subscribers, and Relying Parties in the event of a disaster, security compromise, or business failure.","Section 5.7.1 and 5.7.3","Section 5.7.1 and 5.7.3"]
["5.7.1","Incident and compromise handling procedures","The CA is not required to publicly disclose its business continuity plans but SHALL make its business continuity plan and security plans available to the CA’s auditors upon request.\n","Section 8.4","Section 8.4"]
["5.7.1","Incident and compromise handling procedures","The CA SHALL annually test, review, and update these procedures.\n","Section 5.7.1","Section 5.7.1"]
["5.7.1","Incident and compromise handling procedures","The business continuity plan MUST include:\n\n1. The conditions for activating the plan,\n\n2. Emergency procedures,\n\n3. Fallback procedures,\n\n4. Resumption procedures,\n\n5. A maintenance schedule for the plan;\n\n6. Awareness and education requirements;\n\n7. The responsibilities of the individuals;\n\n8. Recovery time objective (RTO);\n\n9. Regular testing of contingency plans.\n\n10. The CA’s plan to maintain or restore the CA’s business operations in a timely manner following interruption to or failure of critical business processes\n\n11. A requirement to store critical cryptographic materials (i.e., secure cryptographic device and activation materials) at an alternate location;\n\n12. What constitutes an acceptable system outage and recovery time\n\n13. How frequently backup copies of essential business information and software are taken;\n\n14. The distance of recovery facilities to the CA’s main site; and\n\n15. Procedures for securing its facility to the extent possible during the period of time following a disaster and prior to restoring a secure environment either at the original or a remote site. \n","Section 5.7.1 and 5.7.4","Section 5.7.1 and 5.7.4","BJCA's business continuity plan contains these contents, which we disclose to auditors."]
["5.7.2","Recovery Procedures if Computing resources, software, and/or data are corrupted\n","No stipulation (implied)."]
["5.7.3","Recovery Procedures after Key Compromise\n","No stipulation (implied)."]
["5.7.4","Business continuity capabilities after a disaster\n","No stipulation (implied)."]
[5.8,"CA or RA termination","No stipulation (implied).\n"]
["6. Technical Security Controls"]
[6.1,"Key pair generation and installation\n","No stipulation (implied)."]
["6.1.1","Key pair generation\n","No stipulation (implied)."]
["6.1.1.1","CA Key Pair Generation","For CA Key Pairs that are either\ni. used as a CA Key Pair for a Root Certificate or\nii. used as a CA Key Pair for a Subordinate CA Certificate, where the Subordinate CA is not the operator of the Root CA or an Affiliate of the Root CA,\n\nthe CA SHALL:\n1. prepare and follow a Key Generation Script,\n\n2. have a Qualified Auditor witness the CA Key Pair generation process or record a video of the entire CA Key Pair generation process, and\n\n3. have a Qualified Auditor issue a report opining that the CA followed its key ceremony during its Key and Certificate generation process and the controls used to ensure the integrity and confidentiality of the Key Pair.\n","Section 6.1.1.1","Section 6.1.1.1"]
["6.1.1.1","CA Key Pair Generation","For other CA Key Pairs that are for the operator of the Root CA or an Affiliate of the Root CA, the CA SHOULD:\n\n1. prepare and follow a Key Generation Script and\n\n2. have a Qualified Auditor witness the CA Key Pair generation process or record a video of the entire CA Key Pair generation process.\n","Section 6.1.1.1","Section 6.1.1.1"]
["6.1.1.1","CA Key Pair Generation","In all cases, the CA SHALL:\n\n1. generate the CA Key Pair in a physically secured environment as described in the CA’s Certificate Policy and/or Certification Practice Statement;\n\n2. generate the CA Key Pair using personnel in Trusted Roles under the principles of multiple person control and split knowledge;\n\n3. generate the CA Key Pair within cryptographic modules meeting the applicable technical and business requirements as disclosed in the CA’s Certificate Policy and/or Certification Practice Statement;\n\n4. log its CA Key Pair generation activities; and\n\n5. maintain effective controls to provide reasonable assurance that the Private Key was generated and protected in conformance with the procedures described in its Certificate Policy and/or Certification Practice Statement and (if applicable) its Key Generation Script.\n","Section 6.1.1.1","Section 6.1.1.1"]
["6.1.1.2","RA Key Pair Generation","No stipulation (implied).\n"]
["6.1.1.3","Subscriber Key Pair Generation","The CA SHALL reject a certificate request if one or more of the following conditions are met:\n\n1. The Key Pair does not meet the requirements set forth in Section 6.1.5 and/or Section 6.1.6;\n\n2. There is clear evidence that the specific method used to generate the Private Key was flawed;\n\n3. The CA is aware of a demonstrated or proven method that exposes the Applicant’s Private Key to compromise;\n\n4. The CA has previously been made aware that the Applicant’s Private Key has suffered a Key Compromise, such as through the provisions of Section 4.9.1.1;\n\n5. The CA is aware of a demonstrated or proven method to easily compute the Applicant’s Private Key based on the Public Key (such as a Debian weak key, see https://wiki.debian.org/SSLkeys).\n","Section 6.1.1.2","Section 6.1.1.2"]
["6.1.1.3","Subscriber Key Pair Generation","If the Subscriber Certificate will contain an extKeyUsage extension containing either the values id-kp-serverAuth [RFC5280] or anyExtendedKeyUsage [RFC5280], the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA.\n","Section 6.1.1.2","Section 6.1.1.2"]
["6.1.2","Private key delivery to subscriber","Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key without authorization by the Subscriber.\n","Section 6.1.2","Section 6.1.2"]
["6.1.2","Private key delivery to subscriber","If the CA or any of its designated RAs become aware that a Subscriber’s Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subscriber, then the CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.\n","Section 4.9.1.1","Section 4.9.1.1"]
["6.1.3","Public key delivery to certificate issuer\n","No stipulation (implied).\n"]
["6.1.4","CA public key delivery to relying parties\n","No stipulation (implied).\n"]
["6.1.5","Key sizes","For RSA key pairs the CA SHALL:\n• Ensure that the modulus size, when encoded, is at least 2048 bits, and;\n• Ensure that the modulus size, in bits, is evenly divisible by 8.\n","Section 6.1.5","Section 6.1.5"]
["6.1.5","Key sizes","For ECDSA key pairs, the CA SHALL:\n• Ensure that the key represents a valid point on the NIST P-256, NIST P-384 or NIST P-521 elliptic curve.\n","Section 6.1.5","Section 6.1.5"]
["6.1.5","Key sizes","No other algorithms or key sizes are permitted.\n","Section 6.1.5","Section 6.1.5"]
["6.1.6","Public key parameters generation and quality checking","RSA: The CA SHALL confirm that the value of the public exponent is an odd number equal to 3 or more. \n\nAdditionally, the public exponent SHOULD be in the range between 2^16 + 1 and 2^256 - 1. \n\nThe modulus SHOULD also have the following characteristics: an odd number, not the power of a prime, and have no factors smaller than 752. [Source: Section 5.3.3, NIST SP 800-89]\n","Section 6.1.6","Section 6.1.6","CPS does not show disclosure, and we comply with this requirement in internal practice."]
["6.1.6","Public key parameters generation and quality checking","ECDSA: The CA SHOULD confirm the validity of all keys using either the ECC Full Public Key Validation Routine or the ECC Partial Public Key Validation Routine. [Source: Sections 5.6.2.3.2 and 5.6.2.3.3, respectively, of NIST SP 800-56A: Revision 2]\n","Section 6.1.6","Section 6.1.6","CPS does not show disclosure, and we comply with this requirement in internal practice."]
["6.1.7","Key usage purposes (as per X.509 v3 key usage field)","Private Keys corresponding to Root Certificates MUST NOT be used to sign Certificates except in the following cases:\n\n1. Self-signed Certificates to represent the Root CA itself;\n\n2. Certificates for Subordinate CAs and Cross Certificates;\n\n3. Certificates for infrastructure purposes (administrative role certificates, internal CA operational device certificates); and\n\n4. Certificates for OCSP Response verification.\n","Section 6.1.7","Section 6.1.7"]
[6.2,"Private Key Protection and Cryptographic Module Engineering Controls\n","The CA SHALL implement physical and logical safeguards to prevent unauthorized certificate issuance.\n","Section 4.3.1 and 6.2.2","Section 4.3.1 and 6.2.2"]
[6.2,"Private Key Protection and Cryptographic Module Engineering Controls","Protection of the CA Private Key outside the validated system or device specified above MUST consist of physical security, encryption, or a combination of both, implemented in a manner that prevents disclosure of the Private Key.\n","Section 6.2.7","Section 6.2.7"]
[6.2,"Private Key Protection and Cryptographic Module Engineering Controls","The CA SHALL encrypt its Private Key with an algorithm and key-length that, according to the state of the art, are capable of withstanding cryptanalytic attacks for the residual life of the encrypted key or key part.\n","Section 6.2.5, 6.2.6 and 6.2.4","Section 6.2.5, 6.2.6 and 6.2.4"]
["6.2.1","Cryptographic module standards and controls\n","No stipulation (implied).\n"]
["6.2.2","Private key (n out of m) multi-person control\n","No stipulation (implied).\n"]
["6.2.3","Private key escrow","No stipulation (implied).\n"]
["6.2.4","Private key backup","See Section 5.2.2.\n","Section 6.2.4","Section 6.2.4"]
["6.2.5","Private key archival","Parties other than the Subordinate CA SHALL NOT archive the Subordinate CA Private Keys without authorization by the Subordinate CA.\n","N/A","N/A","The Subordinate CA are operated by the BJCA itself."]
["6.2.6","Private key transfer into or from a cryptographic module","If the Issuing CA generated the Private Key on behalf of the Subordinate CA, then the Issuing CA SHALL encrypt the Private Key for transport to the Subordinate CA.\n","N/A","N/A","The Subordinate CA are operated by the BJCA itself."]
["6.2.6","Private key transfer into or from a cryptographic module","If the Issuing CA becomes aware that a Subordinate CA’s Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subordinate CA, then the Issuing CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.\n","N/A","N/A","The Subordinate CA are operated by the BJCA itself."]
["6.2.7","Private key storage on cryptographic module","The CA SHALL protect its Private Key in a system or device that has been validated as meeting at least FIPS 140-2 level 3, FIPS 140-3 level 3, or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher), which includes requirements to protect the Private Key and other assets against known threats.\n","Section 6.2.7","Section 6.2.7"]
["6.2.8","Activating Private Keys","No stipulation (implied).\n"]
["6.2.9","Deactivating Private Keys","No stipulation (implied).\n"]
["6.2.10","Destroying Private Keys","No stipulation (implied).\n"]
["6.2.11","Cryptographic Module Capabilities","No stipulation (implied).\n"]
[6.3,"Other aspects of key pair management\n","No stipulation (implied).\n"]
["6.3.1","Public key archival","No stipulation (implied).\n"]
["6.3.2","Certificate operational periods and key pair usage periods","Subscriber Certificates issued on or after 1 September 2020 SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days. \n","Section 6.3.2","Section 6.3.2"]
["6.3.2","Certificate operational periods and key pair usage periods","Subscriber Certificates issued after 1 March 2018, but prior to 1 September 2020, MUST NOT have a Validity Period greater than 825 days. \n","Section 6.3.2","Section 6.3.2"]
["6.3.2","Certificate operational periods and key pair usage periods","Subscriber Certificates issued after 1 July 2016 but prior to 1 March 2018 MUST NOT have a Validity Period greater than 39 months.\n","Section 6.3.2","Section 6.3.2"]
["6.3.2","Certificate operational periods and key pair usage periods","For the purpose of calculations, a day is measured as 86,400 seconds. Any amount of time greater than this, including fractional seconds and/or leap seconds, shall represent an additional day. For this reason, Subscriber Certificates SHOULD NOT be issued for the maximum permissible time by default, in order to account for such adjustments.\n","Section 6.3.2","Section 6.3.2","CPS does not show disclosure, and we comply with this requirement in internal practice."]
[6.4,"Activation data","No stipulation (implied).\n"]
["6.4.1","Activation data generation and installation\n","No stipulation (implied).\n"]
["6.4.2","Activation data protection","No stipulation (implied).\n"]
["6.4.3","Other aspects of activation data","No stipulation (implied).\n"]
[6.5,"Computer security controls","No stipulation (implied).\n"]
["6.5.1","Specific computer security technical requirements","The CA SHALL enforce multi-factor authentication for all accounts capable of directly causing certificate issuance.\n","Section 6.5.1","Section 6.5.1"]
["6.5.2","Computer security rating","No stipulation (implied).\n"]
[6.6,"Life cycle technical controls","No stipulation (implied).\n"]
["6.6.1","System development controls","No stipulation (implied).\n"]
["6.6.2","Security management controls","No stipulation (implied).\n"]
["6.6.3","Life cycle security controls","No stipulation (implied).\n"]
[6.7,"Network security controls","No stipulation (implied).\n"]
[6.8,"Time-stamping","No stipulation (implied).\n"]
["7. Certificate, CRL, and OCSP Profiles"]
[7.1,"Certificate profile","The CA SHALL meet the technical requirements set forth in Section 2.2 - Publication of Information, Section 6.1.5 - Key Sizes, and Section 6.1.6 - Public Key Parameters Generation and Quality Checking.\n","Section 7.1","Section 7.1"]
[7.1,"Certificate profile","CAs SHALL generate non-sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG.\n","Section 7.1","Section 7.1"]
["7.1.1","Version number(s)","Certificates MUST be of type X.509 v3.\n","Section 7.1.1","Section 7.1.1"]
["7.1.2","Certificate Content and Extensions; Application of RFC 5280\n","N/A (no requirements included in this section)\n"]
["7.1.2.1","Root CA Certificate","basicConstraints\n\nThis extension MUST appear as a critical extension. The cA field MUST be set true.\n\nThe pathLenConstraint field SHOULD NOT be present.\n","Section 7.1.2","Section 7.1.2"]
["7.1.2.1","Root CA Certificate","keyUsage\n\nThis extension MUST be present and MUST be marked critical. Bit positions for keyCertSign and cRLSign MUST be set. \n\nIf the Root CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set.\n","Section 7.1.2","Section 7.1.2"]
["7.1.2.1","Root CA Certificate","extKeyUsage \n\nThis extension MUST NOT be present.\n","Section 7.1.2","Section 7.1.2"]
["7.1.2.2","Subordinate CA Certificate","certificatePolicies\n\nThis extension MUST be present and SHOULD NOT be marked critical.\n\ncertificatePolicies:policyIdentifier (Required)\n\nThe following fields MAY be present if the Subordinate CA is not an Affiliate of the entity that controls the Root CA.\n• certificatePolicies:policyQualifiers:policyQualifierId (Optional)\nid-qt 1 [RFC5280].\n• certificatePolicies:policyQualifiers:qualifier:cPSuri (Optional) HTTP URL for the Root CA’s Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the CA.\n","Section 7.1.2","Section 7.1.2"]
["7.1.2.2","Subordinate CA Certificate","cRLDistributionPoints\n\nThis extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA’s CRL service.\n","Section 7.1.2  \n","Section 7.1.2"]
["7.1.2.2","Subordinate CA Certificate","authorityInformationAccess\n\nThis extension SHOULD be present. It MUST NOT be marked critical. \n\nIt SHOULD contain the HTTP URL of the Issuing CA’s certificate (accessMethod = 1.3.6.1.5.5.7.48.2). It MAY contain the HTTP URL of the Issuing CA’s OCSP responder (accessMethod = 1.3.6.1.5.5.7.48.1).\n","Section 7.1.2  \n","Section 7.1.2"]
["7.1.2.2","Subordinate CA Certificate","basicConstraints\n\nThis extension MUST be present and MUST be marked critical. The cA field MUST be set true. The pathLenConstraint field MAY be present.\n","Section 7.1.2  \n","Section 7.1.2"]
["7.1.2.2","Subordinate CA Certificate","keyUsage\n\nThis extension MUST be present and MUST be marked critical. Bit positions for keyCertSign and cRLSign MUST be set. \n\nIf the Subordinate CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set.\n","Section 7.1.2  \n","Section 7.1.2"]
["7.1.2.2","Subordinate CA Certificate","extKeyUsage (optional/required)\n\nFor Cross Certificates that share a Subject Distinguished Name and Subject Public Key with a Root Certificate operated in accordance with these Requirements, this extension MAY be present. If present, this extension SHOULD NOT be marked critical. This extension MUST only contain usages for which the issuing CA has verified the Cross Certificate is authorized to assert. This extension MAY contain the anyExtendedKeyUsage [RFC5280] usage, if the Root Certificate(s) associated with this Cross Certificate are operated by the same organization as the issuing Root Certificate.\n","N/A","N/A","This situation does not exist."]
["7.1.2.2","Subordinate CA Certificate","extKeyUsage (optional/required)\n\nFor all other Subordinate CA Certificates, including Technically Constrained Subordinate CA Certificates:\n\nThis extension MUST be present and SHOULD NOT be marked critical.\n\nFor Subordinate CA Certificates that will be used to issue TLS certificates, the value id-kp-serverAuth [RFC5280] MUST be present. \n\nThe value id-kp-clientAuth [RFC5280] MAY be present. \n\nThe values id-kp-emailProtection [RFC5280], id-kp-codeSigning [RFC5280], id-kp-timeStamping [RFC5280], and anyExtendedKeyUsage [RFC5280] MUST NOT be present. \n\nOther values SHOULD NOT be present.\n\nFor Subordinate CA Certificates that are not used to issue TLS certificates, then the value id-kp-serverAuth [RFC5280] MUST NOT be present. Other values MAY be present, but SHOULD NOT combine multiple independent key purposes (e.g. including id-kp-timeStamping [RFC5280] with id-kp-codeSigning [RFC5280]).\n","Section 7.1.2  \n","Section 7.1.2"]
["7.1.2.2","Subordinate CA Certificate","authorityKeyIdentifier (required)\n\nThis extension MUST be present and MUST NOT be marked critical. It MUST contain a keyIdentifier field and it MUST NOT contain a authorityCertIssuer or authorityCertSerialNumber field.\n","Section 7.1.2  \n","Section 7.1.2"]
["7.1.2.3","Subscriber Certificate","certificatePolicies\n\nThis extension MUST be present and SHOULD NOT be marked critical.\n• certificatePolicies:policyIdentifier (Required)\n\nA Policy Identifier, defined by the issuing CA, that indicates a Certificate Policy asserting the issuing CA’s adherence to and compliance with these Requirements.\n\nThe following extensions MAY be present:\n• certificatePolicies:policyQualifiers:policyQualifierId (Recommended)\nid-qt 1 [RFC 5280].\n• certificatePolicies:policyQualifiers:qualifier:cPSuri (Optional)\n\nHTTP URL for the Subordinate CA’s Certification Practice Statement, Relying Party Agreement or other pointer to online information provided by the CA.\n","Section 7.1.2  \n","Section 7.1.2"]
["7.1.2.3","Subscriber Certificate","cRLDistributionPoints\n\nThis extension MAY be present. If present, it MUST NOT be marked critical, and it MUST contain the HTTP URL of the CA’s CRL service.\n","Section 7.1.2  \n","Section 7.1.2"]
["7.1.2.3","Subscriber Certificate","authorityInformationAccess\n\nThis extension MUST be present. It MUST NOT be marked critical, and it MUST contain the HTTP URL of the Issuing CA’s OCSP responder (accessMethod = 1.3.6.1.5.5.7.48.1). It SHOULD also contain the HTTP URL of the Issuing CA’s certificate (accessMethod = 1.3.6.1.5.5.7.48.2).\n","Section 7.1.2  \n","Section 7.1.2"]
["7.1.2.3","Subscriber Certificate","basicConstraints (optional)\n\nThe cA field MUST NOT be true.\n","Section 7.1.2  \n","Section 7.1.2"]
["7.1.2.3","Subscriber Certificate","keyUsage (optional)\n\nIf present, bit positions for keyCertSign and cRLSign MUST NOT be set.\n","Section 7.1.2  \n","Section 7.1.2"]
["7.1.2.3","Subscriber Certificate","extKeyUsage (required)\n\nEither the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or both values MUST be present. id-kp-emailProtection [RFC5280] MAY be present. \n\nOther values SHOULD NOT be present. \n\nThe value anyExtendedKeyUsage MUST NOT be present.\n","Section 7.1.2  \n","Section 7.1.2"]
["7.1.2.3","Subscriber Certificate","authorityKeyIdentifier (required)\n\nThis extension MUST be present and MUST NOT be marked critical. It MUST contain a keyIdentifier field and it MUST NOT contain a authorityCertIssuer or authorityCertSerialNumber field.\n","Section 7.1.2  \n","Section 7.1.2"]
["7.1.2.4","All Certificates","All other fields and extensions MUST be set in accordance with RFC 5280. \n","Section 7.1.2  \n","Section 7.1.2"]
["7.1.2.4","All Certificates","The CA SHALL NOT issue a Certificate that contains a keyUsage flag, extKeyUsage value, Certificate extension, or other data not specified in Section 7.1.2.1, Section 7.1.2.2, or Section 7.1.2.3 unless the CA is aware of a reason for including the data in the Certificate.\n\nIf the CA issues certificates containing information other than described here, explain what those fields/extensions are, and the reason for doing so.\n","Section 7.1.2  \n","Section 7.1.2"]
["7.1.2.4","All Certificates","CAs SHALL NOT issue a Certificate with:\n\na. Extensions that do not apply in the context of the public Internet (such as an extKeyUsage value for a service that is only valid in the context of a privately managed network), unless: i. such value falls within an OID arc for which the Applicant demonstrates ownership, or ii. the Applicant can otherwise demonstrate the right to assert the data in a public context; or\n\nb. semantics that, if included, will mislead a Relying Party about the certificate information verified by the CA (such as including an extKeyUsage value for a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance).\n","Section 7.1.2  \n","Section 7.1.2"]
["7.1.2.5","Application of RFC 5280","For purposes of clarification, a Precertificate, as described in RFC 6962 - Certificate Transparency, shall not be considered to be a “certificate” subject to the requirements of RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile under these Baseline Requirements.\n","Section 4.4.2","Section 4.4.2"]
["7.1.3","Algorithm object identifiers","No stipulation (implied).\n"]
["7.1.3.1","SubjectPublicKeyInfo","The following requirements apply to the subjectPublicKeyInfo field within a Certificate or Precertificate. No other encodings are permitted.\n","Section 7.1","Section 7.1"]
["7.1.3.1.1","RSA","The CA SHALL indicate an RSA key using the rsaEncryption (OID: 1.2.840.113549.1.1.1) algorithm identifier. \n\nThe parameters MUST be present, and MUST be an explicit NULL.\n\nThe CA SHALL NOT use a different algorithm, such as the id-RSASSA-PSS (OID: 1.2.840.113549.1.1.10) algorithm identifier, to indicate an RSA key.\n\nWhen encoded, the AlgorithmIdentifier for RSA keys MUST be byte-for-byte identical with the following hex-encoded bytes: 300d06092a864886f70d0101010500\n","Section 7.1.3","Section 7.1.3"]
["7.1.3.1.2","ECDSA","The CA SHALL indicate an ECDSA key using the id-ecPublicKey (OID: 1.2.840.10045.2.1) algorithm identifier. \n\nThe parameters MUST use the namedCurve encoding.\n• For P-256 keys, the namedCurve MUST be secp256r1 (OID: 1.2.840.10045.3.1.7).\n• For P-384 keys, the namedCurve MUST be secp384r1 (OID: 1.3.132.0.34).\n• For P-521 keys, the namedCurve MUST be secp521r1 (OID: 1.3.132.0.35).\n\nWhen encoded, the AlgorithmIdentifier for ECDSA keys MUST be byte-for-byte identical with the following hex-encoded bytes:\n• For P-256 keys, 301306072a8648ce3d020106082a8648ce3d030107.\n• For P-384 keys, 301006072a8648ce3d020106052b81040022.\n• For P-521 keys, 301006072a8648ce3d020106052b81040023.\n","Section 7.1.3","Section 7.1.3"]
["7.1.3.2","Signature AlgorithmIdentifier","All objects signed by a CA Private Key MUST conform to these requirements on the use of the AlgorithmIdentifier or AlgorithmIdentifier-derived type in the context of signatures.\n\nIn particular, it applies to all of the following objects and fields:\n• The signatureAlgorithm field of a Certificate or Precertificate.\n• The signature field of a TBSCertificate (for example, as used by either a Certificate or Precertificate).\n• The signatureAlgorithm field of a CertificateList\n• The signature field of a TBSCertList\n• The signatureAlgorithm field of a BasicOCSPResponse.\n\nNo other encodings are permitted for these fields.\n","Section 7.1.3","Section 7.1.3"]
["7.1.3.2.1","RSA","The CA SHALL use one of the following signature algorithms and encodings. When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the specified hex-encoded bytes.\n\n• RSASSA-PKCS1-v1_5 with SHA-256:\n\nEncoding: 300d06092a864886f70d01010b0500.\n\n----------------------------\n\n• RSASSA-PKCS1-v1_5 with SHA-384:\n\nEncoding: 300d06092a864886f70d01010c0500.\n\n----------------------------\n\n• RSASSA-PKCS1-v1_5 with SHA-512:\n\nEncoding: 300d06092a864886f70d01010d0500.\n\n• RSASSA-PSS with SHA-256, MGF-1 with SHA-256, and a salt length of 32 bytes:\n\nEncoding: 304106092a864886f70d01010a3034a00f300d06096086480165030402010500a11c301a06092a864886f70d010108300d06096086480165030402010500a203020120\n\n----------------------------\n\n• RSASSA-PSS with SHA-384, MGF-1 with SHA-384, and a salt length of 48 bytes:\n\nEncoding: 304106092a864886f70d01010a3034a00f300d06096086480165030402020500a11c301a06092a864886f70d010108300d06096086480165030402020500a203020130\n\n----------------------------\n\n• RSASSA-PSS with SHA-512, MGF-1 with SHA-512, and a salt length of 64 bytes:\n\nEncoding: 304106092a864886f70d01010a3034a00f300d06096086480165030402030500a11c301a06092a864886f70d010108300d06096086480165030402030500a203020140\n","Section 7.1.3","Section 7.1.3"]
["7.1.3.2.1","RSA","In addition, the CA MAY use the following signature algorithm and encoding [SHA-1] if all of the following conditions are met:\n\n• If used within a Certificate, such as the signatureAlgorithm field of a Certificate or the signature field of a TBSCertificate:\n\n•• The new Certificate is a Root CA Certificate or Subordinate CA Certificate that is a Cross-Certificate; and,\n\n•• There is an existing Certificate, issued by the same issuing CA Certificate, using the following encoding for the signature algorithm; and,\n\n•• The existing Certificate has a serialNumber that is at least 64-bits long; and,\n\n•• The only differences between the new Certificate and existing Certificate are one of the following:\n\n••• A new subjectPublicKey within the subjectPublicKeyInfo, using the same algorithm and key size; and/or,\n\n••• A new serialNumber, of the same encoded length as the existing Certificate; and/or\n\n••• The new Certificate’s extKeyUsage extension is present, has at least one key purpose specified, and none of the key purposes specified are the id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) or the anyExtendedKeyUsage (OID: 2.5.29.37.0) key purposes; and/or\n\n••• The new Certificate’s basicConstraints extension has a pathLenConstraint that is zero.\n\n• If used within an OCSP response, such as the signatureAlgorithm of a BasicOCSPResponse:\n\n•• The producedAt field value of the ResponseData MUST be earlier than 2022-06-01 00:00:00 UTC; and,\n\n•• All unexpired, un-revoked Certificates that contain the Public Key of the CA Key Pair and that have the same Subject Name MUST also contain an extKeyUsage extension with the only key usage present being the id-kp-ocspSigning (OID: 1.3.6.1.5.5.7.3.9) key usage.\n\n• If used within a CRL, such as the signatureAlgorithm field of a CertificateList or the signature field of a TBSCertList:\n\n•• The CRL is referenced by one or more Root CA or Subordinate CA Certificates; and,\n\n•• The Root CA or Subordinate CA Certificate has issued one or more Certificates using the following encoding for the signature algorithm. \n\nNote: The above requirements do not permit a CA to sign a Precertificate with this encoding.\n\n• RSASSA-PKCS1-v1_5 with SHA-1: Encoding: 300d06092a864886f70d0101050500","N/A","N/A","This situation does not exist."]
["7.1.3.2.2","ECDSA","The CA SHALL use the appropriate signature algorithm and encoding based upon the signing key used.\n\nIf the signing key is P-256, the signature MUST use ECDSA with SHA-256. When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the following hex-encoded bytes: 300a06082a8648ce3d040302.\n\nIf the signing key is P-384, the signature MUST use ECDSA with SHA-384. When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the following hex-encoded bytes: 300a06082a8648ce3d040303.\n\nIf the signing key is P-521, the signature MUST use ECDSA with SHA-512. When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the following hex-encoded bytes: 300a06082a8648ce3d040304.\n","Section 7.1.3","Section 7.1.3"]
["7.1.4","Name Forms","No stipulation (implied).\n"]
["7.1.4.1","Name Encoding","The following requirements SHOULD be met by all newly-issued Subordinate CA Certificates that are not used to issue TLS certificates, as defined in Section 7.1.2.2, and MUST be met for all other Certificates, regardless of whether the Certificate is a CA Certificate or a Subscriber Certificate.\n","Section 7.1.4","Section 7.1.4"]
["7.1.4.1","Name Encoding","For every valid Certification Path (as defined by RFC 5280, Section 6):\n\n• For each Certificate in the Certification Path, the encoded content of the Issuer Distinguished Name field of a Certificate SHALL be byte-for-byte identical with the encoded form of the Subject Distinguished Name field of the Issuing CA certificate.\n\n• For each CA Certificate in the Certification Path, the encoded content of the Subject Distinguished Name field of a Certificate SHALL be byte-for-byte identical among all Certificates whose Subject Distinguished Names can be compared as equal according to RFC 5280, Section 7.1, and including expired and revoked Certificates.\n","Section 7.1.4","Section 7.1.4"]
["7.1.4.2","Subject Information - Subscriber Certificates","By issuing the Certificate, the CA represents that it followed the procedure set forth in its Certificate Policy and/or Certification Practice Statement to verify that, as of the Certificate’s issuance date, all of the Subject Information was accurate. \n\nCAs SHALL NOT include a Domain Name or IP Address in a Subject attribute except as specified in Section 3.2.2.4 or Section 3.2.2.5.\n","Section 7.1.4","Section 7.1.4"]
["7.1.4.2","Subject Information - Subscriber Certificates","Subject attributes MUST NOT contain only metadata such as ‘.’, ‘-’, and ’ ’ (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or Not applicable.","Section 7.1.4","Section 7.1.4"]
["7.1.4.2.1","Subject Alternative Name Extension","Certificate Field: extensions:subjectAltName\nRequired/Optional: Required\nContents: This extension MUST contain at least one entry. Each entry MUST be one of the following types:\n\n• dNSName: The entry MUST contain either a Fully-Qualified Domain Name or Wildcard Domain Name that the CA has validated in accordance with Section 3.2.2.4. Wildcard Domain Names MUST be validated for consistency with Section 3.2.2.6. The entry MUST NOT contain an Internal Name. \n\nThe Fully-Qualified Domain Name or the FQDN portion of the Wildcard Domain Name contained in the entry MUST be composed entirely of LDH Labels joined together by a U+002E FULL STOP (“.”) character. The zero-length Domain Label representing the root zone of the Internet Domain Name System MUST NOT be included (e.g. “example.com” MUST be encoded as “example.com” and MUST NOT be encoded as “example.com.”).\n\nThe Fully-Qualified Domain Name or the FQDN portion of the Wildcard Domain Name MUST consist solely of Domain Labels that are P-Labels or Non-Reserved LDH Labels.\n\n• iPAddress: The entry MUST contain an IPv4 or IPv6 address that the CA has validated in accordance with Section 3.2.2.5. The entry MUST NOT contain a Reserved IP Address.\n","Section 3.1.1","Section 3.1.1"]
["7.1.4.2.2","Subject Distinguished Name Fields","Certificate Field: subject:commonName (OID 2.5.4.3)\n\nRequired/Optional: Deprecated (Discouraged, but not prohibited)\n\nContents: If present, this field MUST contain exactly one entry that is one of the values contained in the Certificate’s subjectAltName extension (see Section 7.1.4.2.1). \n\nThe value of the field MUST be encoded as follows:\n• If the value is an IPv4 address, then the value MUST be encoded as an IPv4Address as specified in RFC 3986, Section 3.2.2.\n• If the value is an IPv6 address, then the value MUST be encoded in the text representation specified in RFC 5952, Section 4.\n• If the value is a Fully-Qualified Domain Name or Wildcard Domain Name, then the value MUST be encoded as a character-for-character copy of the dNSName entry value from the subjectAltName extension. Specifically, all Domain Labels of the Fully-Qualified Domain Name or FQDN portion of the Wildcard Domain Name must be encoded as LDH Labels, and P-Labels MUST NOT be converted to their Unicode representation.\n","Section 7.1","Section 7.1"]
["7.1.4.2.2","Subject Distinguished Name Fields","Certificate Field: subject:organizationName (OID 2.5.4.10)\n\nRequired/Optional: Optional.\n\nContents: If present, the subject:organizationName field MUST contain either the Subject’s name or DBA as verified under Section 3.2.2.2. The CA may include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g., if the official record shows “Company Name Incorporated”, the CA MAY use “Company Name Inc.” or “Company Name”. Because Subject name attributes for individuals (e.g. givenName (2.5.4.42) and surname (2.5.4.4)) are not broadly supported by application software, the CA MAY use the subject:organizationName field to convey a natural person Subject’s name or DBA.\n","Section 7.1","Section 7.1"]
["7.1.4.2.2","Subject Distinguished Name Fields","Certificate Field: subject:givenName (2.5.4.42) and subject:surname (2.5.4.4)\n\nRequired/Optional: Optional.\n\nContents: If present, the subject:givenName field and subject:surname field MUST contain a natural person Subject’s name as verified under Section 3.2.3. A Certificate containing a subject:givenName field or subject:surname field MUST contain the (2.23.140.1.2.3) Certificate Policy OID.\n","Section 7.1","Section 7.1"]
["7.1.4.2.2","Subject Distinguished Name Fields","Certificate Field: Number and street: subject:streetAddress (OID: 2.5.4.9)\n\nRequired/Optional:\n\nOptional if the subject:organizationName field, subject:givenName field, or subject:surname field are present. \n\nProhibited if the subject:organizationName field, subject:givenName, and subject:surname field are absent.\n\nContents: If present, the subject:streetAddress field MUST contain the Subject’s street address information as verified under Section 3.2.2.1.\n","Section 7.1","Section 7.1"]
["7.1.4.2.2","Subject Distinguished Name Fields","Certificate Field: subject:localityName (OID: 2.5.4.7)\n\nRequired/Optional: \n\nRequired if the subject:organizationName field, subject:givenName field, or subject:surname field are present and the subject:stateOrProvinceName field is absent. \n\nOptional if the subject:stateOrProvinceName field and the subject:organizationName field, subject:givenName field, or subject:surname field are present. \n\nProhibited if the subject:organizationName field, subject:givenName, and subject:surname field are absent.\n\nContents: If present, the subject:localityName field MUST contain the Subject’s locality information as verified under Section 3.2.2.1. If the subject:countryName field specifies the ISO 3166-1 user-assigned code of XX in accordance with Section 7.1.4.2.2 (h), the localityName field MAY contain the Subject’s locality and/or state or province information as verified under Section 3.2.2.1.\n","Section 7.1","Section 7.1"]
["7.1.4.2.2","Subject Distinguished Name Fields","Certificate Field: subject:stateOrProvinceName (OID: 2.5.4.8)\n\nRequired/Optional: \n\nRequired if the subject:organizationName field, subject:givenName field, or subject:surname field are present and subject:localityName field is absent. \n\nOptional if the subject:localityName field and the subject:organizationName field, the subject:givenName field, or the subject:surname field are present. \n\nProhibited if the subject:organizationName field, the subject:givenName field, or subject:surname field are absent.\n\nContents: If present, the subject:stateOrProvinceName field MUST contain the Subject’s state or province information as verified under Section 3.2.2.1. If the subject:countryName field specifies the ISO 3166-1 user-assigned code of XX in accordance with Section 7.1.4.2.2 (h), the subject:stateOrProvinceName field MAY contain the full name of the Subject’s country information as verified under Section 3.2.2.1.\n","Section 7.1","Section 7.1"]
["7.1.4.2.2","Subject Distinguished Name Fields","Certificate Field: subject:postalCode (OID: 2.5.4.17)\n\nRequired/Optional: \n\nOptional if the subject:organizationName, subject:givenName field, or subject:surname fields are present. \n\nProhibited if the subject:organizationName field, subject:givenName field, or subject:surname field are absent.\n\nContents: If present, the subject:postalCode field MUST contain the Subject’s zip or postal information as verified under Section 3.2.2.1.\n","Section 7.1","Section 7.1"]
["7.1.4.2.2","Subject Distinguished Name Fields","Certificate Field: subject:countryName (OID: 2.5.4.6)\n\nRequired/Optional: \n\nRequired if the subject:organizationName field, subject:givenName, or subject:surname field are present. \n\nOptional if the subject:organizationName field, subject:givenName field, and subject:surname field are absent.\n\nContents: If the subject:organizationName field is present, the subject:countryName MUST contain the two-letter ISO 3166-1 country code associated with the location of the Subject verified under Section 3.2.2.1. If the subject:organizationName field is absent, the subject:countryName field MAY contain the two-letter ISO 3166-1 country code associated with the Subject as verified in accordance with Section 3.2.2.3. If a Country is not represented by an official ISO 3166-1 country code, the CA MAY specify the ISO 3166-1 user-assigned code of XX indicating that an official ISO 3166-1 alpha-2 code has not been assigned.\n","Section 7.1","Section 7.1"]
["7.1.4.2.2","Subject Distinguished Name Fields","Certificate Field: subject:organizationalUnitName (OID: 2.5.4.11)\n\nRequired/Optional: Prohibited.\n","Section 7.1","Section 7.1"]
["7.1.4.2.2","Subject Distinguished Name Fields","Other Subject Attributes\n\nOther attributes MAY be present within the subject field. If present, other attributes MUST contain information that has been verified by the CA.\n","N/A","N/A","This situation does not exist."]
["7.1.4.3","Subject Information - Root Certificates and Subordinate CA Certificates","By issuing a Subordinate CA Certificate, the CA represents that it followed the procedure set forth in its Certificate Policy and/or Certification Practice Statement to verify that, as of the Certificate’s issuance date, all of the Subject Information was accurate.\n","Section 7.1","Section 7.1"]
["7.1.4.3.1","Subject Distinguished Name Fields","Certificate Field: subject:commonName (OID 2.5.4.3)\n\nRequired/Optional: Required\n\nContents: This field MUST be present and the contents SHOULD be an identifier for the certificate such that the certificate’s Name is unique across all certificates issued by the issuing certificate.\n","Section 7.1","Section 7.1"]
["7.1.4.3.1","Subject Distinguished Name Fields","Certificate Field: subject:organizationName (OID 2.5.4.10)\n\nRequired/Optional: Required\n\nContents: This field MUST be present and the contents MUST contain either the Subject CA’s name or DBA as verified under Section 3.2.2.2. The CA may include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g., if the official record shows “Company Name Incorporated”, the CA MAY use “Company Name Inc.” or “Company Name”.\n","Section 7.1","Section 7.1"]
["7.1.4.3.1","Subject Distinguished Name Fields","Certificate Field: subject:countryName (OID: 2.5.4.6)\n\nRequired/Optional: Required\n\nContents: This field MUST contain the two-letter ISO 3166-1 country code for the country in which the CA’s place of business is located.\n","Section 7.1","Section 7.1"]
["7.1.5","Name constraints","For a Subordinate CA Certificate to be considered Technically Constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying all extended key usages that the Subordinate CA Certificate is authorized to issue certificates for.\n","N/A","N/A","This situation does not exist."]
["7.1.5","Name constraints","The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension.\n","Section 7.1.2","Section 7.1.2"]
["7.1.5","Name constraints","If the Subordinate CA Certificate includes the id-kp-serverAuth extended key usage, then the Subordinate CA Certificate MUST include the Name Constraints X.509v3 extension with constraints on dNSName, iPAddress and DirectoryName as follows: \n\na. For each dNSName in permittedSubtrees, the CA MUST confirm that the Applicant has registered the dNSName or has been authorized by the domain registrant to act on the registrant’s behalf in line with the verification practices of Section 3.2.2.4.\n\nb. For each iPAddress range in permittedSubtrees, the CA MUST confirm that the Applicant has been assigned the IP Address range or has been authorized by the assigner to act on the assignee’s behalf.\n\nc. For each DirectoryName in permittedSubtrees, the CA MUST confirm the Applicant’s and/or Subsidiary’s Organizational name and location such that end entity certificates issued from the subordinate CA Certificate will be in compliance with Section 7.1.2.4 and Section 7.1.2.5.\n","Section 7.1","Section 7.1"]
["7.1.5","Name constraints","If the Subordinate CA Certificate is not allowed to issue certificates with an IP Address, then the Subordinate CA Certificate MUST specify the entire IPv4 and IPv6 address ranges in excludedSubtrees. \n","N/A","N/A","This situation does not exist."]
["7.1.5","Name constraints","The Subordinate CA Certificate MUST include within excludedSubtrees an iPAddress GeneralName of 8 zero octets (covering the IPv4 address range of 0.0.0.0/0). \n","N/A","N/A","This situation does not exist."]
["7.1.5","Name constraints","The Subordinate CA Certificate MUST also include within excludedSubtrees an iPAddress GeneralName of 32 zero octets (covering the IPv6 address range of ::0/0).\n","N/A","N/A","This situation does not exist."]
["7.1.5","Name constraints","Otherwise, the Subordinate CA Certificate MUST include at least one iPAddress in permittedSubtrees.\n","N/A","N/A","This situation does not exist."]
["7.1.5","Name constraints","If the Subordinate CA is not allowed to issue certificates with dNSNames, then the Subordinate CA Certificate MUST include a zero-length dNSName in excludedSubtrees. Otherwise, the Subordinate CA Certificate MUST include at least one dNSName in permittedSubtrees.\n","N/A","N/A","This situation does not exist."]
["7.1.6","Certificate policy object identifier","N/A (no requirements included in this section)\n"]
["7.1.6.1","Reserved Certificate Policy Identifiers\n","N/A (no requirements included in this section)\n"]
["7.1.6.2","Root CA Certificates","A Root CA Certificate SHOULD NOT contain the certificatePolicies extension. If present, the extension MUST conform to the requirements set forth for Certificates issued to Subordinate CAs in Section 7.1.6.3.\n","Section 7.1.2","Section 7.1.2"]
["7.1.6.3","Subordinate CA Certificates","A Certificate issued to a Subordinate CA that is not an Affiliate of the Issuing CA:\n\n1. MUST include one or more explicit policy identifiers that indicate the Subordinate CA’s adherence to and compliance with these Requirements (i.e. either the CA/Browser Forum Reserved Certificate Policy Identifiers or identifiers documented by the Subordinate CA in its Certificate Policy and/or Certification Practice Statement) and\n\n2. MAY contain one or more identifiers documented by the Subordinate CA in its Certificate Policy and/or Certification Practice Statement and\n\n3. MUST NOT contain the anyPolicy identifier (2.5.29.32.0).\n","N/A","N/A","This situation does not exist."]
["7.1.6.3","Subordinate CA Certificates","A Certificate issued to a Subordinate CA that is an affiliate of the Issuing CA:\n\n1. MAY include one or more explicit policy identifiers that indicate the Subordinate CA’s adherence to and compliance with these Requirements (i.e. either the CA/Browser Forum Reserved Certificate Policy Identifiers or identifiers documented by the Subordinate CA in its Certificate Policy and/or Certification Practice Statement) and\n\n2. MAY contain one or more identifiers documented by the Subordinate CA in its Certificate Policy and/or Certification Practice Statement and\n\n3. MAY contain the anyPolicy identifier (2.5.29.32.0) in place of an explicit policy identifier.\n","Section 1.2","Section 1.2"]
["7.1.6.3","Subordinate CA Certificates","The Subordinate CA and the Issuing CA SHALL represent, in their Certificate Policy and/or Certification Practice Statement, that all Certificates containing a policy identifier indicating compliance with these Requirements are issued and managed in accordance with these Requirements.\n","Section 1.2","Section 1.2"]
["7.1.6.4","Subscriber Certificates","A Certificate issued to a Subscriber MUST contain, within the Certificate’s certificatePolicies extension, one or more policy identifier(s) that are specified beneath the CA/Browser Forum’s reserved policy OID arc of {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1)} (2.23.140.1).\n","Section 1.2","Section 1.2"]
["7.1.6.4","Subscriber Certificates","The certificate MAY also contain additional policy identifier(s) defined by the Issuing CA. The issuing CA SHALL document in its Certificate Policy or Certification Practice Statement that the Certificates it issues containing the specified policy identifier(s) are managed in accordance with these requirements.\n","Section 1.2","Section 1.2"]
["7.1.6.4","Subscriber Certificates","Prior to including a Reserved Certificate Policy Identifier, the CA MUST ensure the following requirements are met:\n\n• Certificate Policy Identifier: 2.23.140.1.2.1\nIf the Certificate complies with these requirements and lacks Subject identity information that has been verified in accordance with Section 3.2.2.1 or Section 3.2.3. Such Certificates MUST NOT include organizationName, givenName, surname, streetAddress, localityName, stateOrProvinceName, or postalCode in the Subject field.\n\n• Certificate Policy Identifier: 2.23.140.1.2.2\nIf the Certificate complies with these Requirements and includes Subject Identity Information that is verified in accordance with Section 3.2.2.1. Such Certificates MUST also include organizationName, localityName (to the extent such field is required under Section 7.1.4.2.2), stateOrProvinceName (to the extent such field is required under Section 7.1.4.2.2), and countryName in the Subject field.\n\n• Certificate Policy Identifier: 2.23.140.1.2.3\nIf the Certificate complies with these Requirements and includes Subject Identity Information that is verified in accordance with Section 3.2.3. Such Certificates MUST also include either organizationName or both givenName and surname, localityName (to the extent such field is required under Section 7.1.4.2.2), stateOrProvinceName (to the extent required under Section 7.1.4.2.2), and countryName in the Subject field.\n\n• Certificate Policy Identifier: 2.23.140.1.1\nIf the Certificate complies with these Requirements and has been issued and operated in accordance with the CA/Browser Forum Guidelines for the Issuance and Management of Extended Validation Certificates (“EV Guidelines”). Such Certificates MUST also include Subject Identity Information as required and verified according to the EV Guidelines.\n","Section 1.2","Section 1.2"]
["7.1.7","Usage of Policy Constraints extension\n","No stipulation (implied).\n"]
["7.1.8","Policy qualifiers syntax and semantics\n","No stipulation (implied).\n"]
["7.1.9","Processing semantics for the critical Certificate Policies extension\n","No stipulation (implied).\n"]
[7.2,"CRL profile","No stipulation (implied).\n"]
["7.2.1","Version number(s)","No stipulation (implied).\n"]
["7.2.2","CRL and CRL entry extensions","1. reasonCode (OID 2.5.29.21)\n\nIf present, this extension MUST NOT be marked critical.\n\nIf a CRL entry is for a Root CA or Subordinate CA Certificate, including Cross Certificates, this CRL entry extension MUST be present. If a CRL entry is for a Certificate not technically capable of causing issuance, this CRL entry extension SHOULD be present, but MAY be omitted, subject to the following requirements.\n\nThe CRLReason indicated MUST NOT be unspecified (0). If the reason for revocation is unspecified, CAs MUST omit reasonCode entry extension, if allowed by the previous requirements. If a CRL entry is for a Certificate not subject to these Requirements and was either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30, the CRLReason MUST NOT be certificateHold (6). If a CRL entry is for a Certificate subject to these Requirements, the CRLReason MUST NOT be certificateHold (6).\n\nIf a reasonCode CRL entry extension is present, the CRLReason MUST indicate the most appropriate reason for revocation of the certificate, as defined by the CA within its CP/CPS.\n","Section 7.2.2","Section 7.2.2"]
["7.2.2","CRL and CRL entry extensions","2. issuingDistributionPoint (OID 2.5.29.28)\n\nEffective 2023-01-15, if a CRL does not contain entries for all revoked unexpired certificates issued by the CRL issuer, then it MUST contain a critical Issuing Distribution Point extension and MUST populate the distributionPoint field of that extension.","N/A","N/A","This CA issues a Full CRL."]
[7.3,"OCSP profile","If an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross Certificates, and that certificate has been revoked, then the revocationReason field within the RevokedInfo of the CertStatus MUST be present.\n","Section 7.3","Section 7.3"]
[7.3,"OCSP profile","The CRLReason indicated MUST contain a value permitted for CRLs, as specified in Section 7.2.2.\n","Section 7.2.2","Section 7.2.2"]
["7.3.1","Version number(s)","No stipulation (implied).\n"]
["7.3.2","OCSP extensions","The singleExtensions of an OCSP response MUST NOT contain the reasonCode (OID 2.5.29.21) CRL entry extension.\n","Section 7.3.2","Section 7.3.2"]
["8. Compliance Audit and Other Assessments"]
[8,"Compliance Audit and Other Assessments","The CA SHALL at all times:\n\n1. Comply with these Requirements;\n\n2. Comply with the audit requirements set forth in this section; and\n\n3. Be licensed as a CA in each jurisdiction where it operates, if licensing is required by the law of such jurisdiction for the issuance of Certificates.\n","Section 8.1","Section 8.1"]
[8.1,"Frequency or circumstances of assessment","Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with Section 7.1.5 and audited in line with Section 8.7 only, or Unconstrained and fully audited in line with all remaining requirements from this section. A Certificate is deemed as capable of being used to issue new certificates if it contains an X.509v3 basicConstraints extension, with the cA boolean set to true and is therefore by definition a Root CA Certificate or a Subordinate CA Certificate.\n","Section 7.1.2","Section 7.1.2"]
[8.1,"Frequency or circumstances of assessment","The period during which the CA issues Certificates SHALL be divided into an unbroken sequence of audit periods.\n","Section 8.1","Section 8.1"]
[8.1,"Frequency or circumstances of assessment\n","An audit period MUST NOT exceed one year in duration.\n","Section 8.1","Section 8.1"]
[8.1,"Frequency or circumstances of assessment","If the CA does not have a currently valid Audit Report indicating compliance with one of the audit schemes listed in Section 8.4, then, before issuing Publicly-Trusted Certificates, the CA SHALL successfully complete a point-in-time readiness assessment performed in accordance with applicable standards under one of the audit schemes listed in Section 8.4.\n","N/A","N/A","So far, the audit periods have been continuous without any gaps."]
[8.1,"Frequency or circumstances of assessment","The point-in-time readiness assessment SHALL be completed no earlier than twelve (12) months prior to issuing Publicly-Trusted Certificates and SHALL be followed by a complete audit under such scheme within ninety (90) days of issuing the first Publicly-Trusted Certificate.\n","N/A","N/A","So far, the audit periods have been continuous without any gaps."]
[8.2,"Identity/qualifications of assessor","The CA’s audit SHALL be performed by a Qualified Auditor. A Qualified Auditor means a natural person, Legal Entity, or group of natural persons or Legal Entities that collectively possess the following qualifications and skills:\n\n1. Independence from the subject of the audit;\n\n2. The ability to conduct an audit that addresses the criteria specified in an Eligible Audit Scheme (see Section 8.4);\n\n3. Employs individuals who have proficiency in examining Public Key Infrastructure technology, information security tools and techniques, information technology and security auditing, and the third-party attestation function;\n\n4. (For audits conducted in accordance with any one of the ETSI standards) accredited in accordance with ISO 17065 applying the requirements specified in ETSI EN 319 403;\n\n5. (For audits conducted in accordance with the WebTrust standard) licensed by WebTrust;\n\n6. Bound by law, government regulation, or professional code of ethics; and\n\n7. Except in the case of an Internal Government Auditing Agency, maintains Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage\n","Section 8.2","Section 8.2"]
[8.3,"Assessor’s relationship to assessed entity\n","No stipulation (implied)."]
[8.4,"Topics covered by assessment","The CA SHALL undergo an audit in accordance with one of the following schemes:\n\n1. “WebTrust for CAs v2.1 or newer” AND “WebTrust for CAs SSL Baseline with Network Security v2.3 or newer”; or\n\n2. ETSI EN 319 411-1 v1.2.2, which includes normative references to ETSI EN 319 401 (the latest version of the referenced ETSI documents should be applied); or\n\n3. If a Government CA is required by its Certificate Policy to use a different internal audit scheme, it MAY use such scheme provided that the audit either \na. encompasses all requirements of one of the above schemes or \nb. consists of comparable criteria that are available for public review.\n","Section 8.4","Section 8.4"]
[8.4,"Topics covered by assessment","Whichever scheme is chosen, it MUST incorporate periodic monitoring and/or accountability procedures to ensure that its audits continue to be conducted in accordance with the requirements of the scheme.\n","Section 8.4","Section 8.4"]
[8.4,"Topics covered by assessment","The audit MUST be conducted by a Qualified Auditor, as specified in Section 8.2.\n","Section 8.2","Section 8.2"]
[8.4,"Topics covered by assessment","For Delegated Third Parties which are not Enterprise RAs, then the CA SHALL obtain an audit report, issued under the auditing standards that underlie the accepted audit schemes found in Section 8.4, that provides an opinion whether the Delegated Third Party’s performance complies with either the Delegated Third Party’s practice statement or the CA’s Certificate Policy and/or Certification Practice Statement.\n","N/A","N/A","Besides acting as a CA, BJCA will also act as a RA and no third party will be entrusted as the RA."]
[8.4,"Topics covered by assessment","If the opinion is that the Delegated Third Party does not comply, then the CA SHALL not allow the Delegated Third Party to continue performing delegated functions.\n","N/A","N/A","Besides acting as a CA, BJCA will also act as a RA and no third party will be entrusted as the RA."]
[8.4,"Topics covered by assessment","The audit period for the Delegated Third Party SHALL NOT exceed one year (ideally aligned with the CA’s audit).\n","N/A","N/A","Besides acting as a CA, BJCA will also act as a RA and no third party will be entrusted as the RA."]
[8.4,"Topics covered by assessment","However, if the CA or Delegated Third Party is under the operation, control, or supervision of a Government Entity and the audit scheme is completed over multiple years, then the annual audit MUST cover at least the core controls that are required to be audited annually by such scheme plus that portion of all non-core controls that are allowed to be conducted less frequently, but in no case may any non-core control be audited less often than once every three years.\n","N/A","N/A","BJCA is an independent enterprise."]
[8.5,"Actions taken as a result of deficiency\n","No stipulation (implied)."]
[8.6,"Communication of results","The Audit Report SHALL state explicitly that it covers the relevant systems and processes used in the issuance of all Certificates that assert one or more of the policy identifiers listed in Section 7.1.6.1. \n","Section 8.6","Section 8.6"]
[8.6,"Communication of results","The CA SHALL make the Audit Report publicly available.\n","Section 8.6","Section 8.6"]
[8.6,"Communication of results","The CA MUST make its Audit Report publicly available no later than three months after the end of the audit period. \n\nIn the event of a delay greater than three months, the CA SHALL provide an explanatory letter signed by the Qualified Auditor.\n","Section 8.6","Section 8.6","CPS does not show disclosure, and we comply with this requirement in internal practice."]
[8.6,"Communication of results","The Audit Report MUST contain at least the following clearly-labelled information:\n\n1. name of the organization being audited;\n\n2. name and address of the organization performing the audit;\n\n3. the SHA-256 fingerprint of all Roots and Subordinate CA Certificates, including Cross Certificates, that were in-scope of the audit;\n\n4. audit criteria, with version number(s), that were used to audit each of the certificates (and associated keys);\n\n5. a list of the CA policy documents, with version numbers, referenced during the audit;\n\n6. whether the audit assessed a period of time or a point in time;\n\n7. the start date and end date of the Audit Period, for those that cover a period of time;\n\n8. the point in time date, for those that are for a point in time;\n\n9. the date the report was issued, which will necessarily be after the end date or point in time date; and\n\n10. (for audits conducted in accordance with any of the ETSI standards) a statement to indicate if the audit was a full audit or a surveillance audit, and which portions of the criteria were applied and evaluated, e.g. DVCP, OVCP, NCP, NCP+, LCP, EVCP, EVCP+, QCP-w, Part 1 (General Requirements), and/or Part 2 (Requirements for Trust Service Providers).\n\n11. (for audits conducted in accordance with any of the ETSI standards) a statement to indicate that the auditor referenced the applicable CA/Browser Forum criteria, such as this document, and the version used.\n","Section 8.6","Section 8.6","See audit report."]
[8.6,"Communication of results","An authoritative English language version of the publicly available audit information MUST be provided by the Qualified Auditor and the CA SHALL ensure it is publicly available.\n","Section 8.6","Section 8.6"]
[8.6,"Communication of results","The Audit Report MUST be available as a PDF, and SHALL be text searchable for all information required. Each SHA-256 fingerprint within the Audit Report MUST be uppercase letters and MUST NOT contain colons, spaces, or line feeds.\n","Section 8.6","Section 8.6","See audit report.\n"]
[8.7,"Self-Audits","During the period in which the CA issues Certificates, the CA SHALL monitor adherence to its Certificate Policy, Certification Practice Statement and these Requirements and strictly control its service quality by performing self audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken.\n","Section 8.7","Section 8.7"]
[8.7,"Self-Audits","Except for Delegated Third Parties that undergo an annual audit that meets the criteria specified in Section 8.4, the CA SHALL strictly control the service quality of Certificates issued or containing information verified by a Delegated Third Party by having a Validation Specialist employed by the CA perform ongoing quarterly audits against a randomly selected sample of at least the greater of one certificate or three percent of the Certificates verified by the Delegated Third Party in the period beginning immediately after the last sample was taken.\n","Section 8.7","Section 8.7"]
[8.7,"Self-Audits","The CA SHALL review each Delegated Third Party’s practices and procedures to ensure that the Delegated Third Party is in compliance with these Requirements and the relevant Certificate Policy and/or Certification Practice Statement.\n","N/A","N/A","Besides acting as a CA, BJCA will also act as a RA and no third party will be entrusted as the RA."]
[8.7,"Self-Audits","The CA SHALL internally audit each Delegated Third Party’s compliance with these Requirements on an annual basis.\n","N/A","N/A","Besides acting as a CA, BJCA will also act as a RA and no third party will be entrusted as the RA."]
[8.7,"Self-Audits","During the period in which a Technically Constrained Subordinate CA issues Certificates, the CA which signed the Subordinate CA SHALL monitor adherence to the CA’s Certificate Policy and the Subordinate CA’s Certification Practice Statement.\n","N/A","N/A","This situation does not exist."]
[8.7,"Self-Audits","On at least a quarterly basis, against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by the Subordinate CA, during the period commencing immediately after the previous audit sample was taken, the CA shall ensure all applicable CP are met.\n","Section 8.7","Section 8.7"]
["9. Other Business and Legal Matters"]
[9.1,"Fees","No stipulation (implied).\n"]
["9.1.1","Certificate issuance or renewal fees\n","No stipulation (implied).\n"]
["9.1.2","Certificate access fees","No stipulation (implied).\n"]
["9.1.3","Revocation or status information access fees\n","No stipulation (implied).\n"]
["9.1.4","Fees for other services","No stipulation (implied).\n"]
["9.1.5","Refund policy","No stipulation (implied).\n"]
[9.2,"Financial responsibility","No stipulation (implied).\n"]
["9.2.1","Insurance coverage","No stipulation (implied).\n"]
["9.2.2","Other assets","No stipulation (implied).\n"]
["9.2.3","Insurance or warranty coverage for end-entities\n","No stipulation (implied).\n"]
[9.3,"Confidentiality of business information\n","No stipulation (implied).\n"]
["9.3.1","Scope of confidential information","No stipulation (implied).\n"]
["9.3.2","Information not within the scope of confidential information\n","No stipulation (implied).\n"]
["9.3.3","Responsibility to protect confidential information\n","No stipulation (implied).\n"]
[9.4,"Privacy of personal information","No stipulation (implied).\n"]
["9.4.1","Privacy plan","No stipulation (implied).\n"]
["9.4.2","Information treated as private","No stipulation (implied).\n"]
["9.4.3","Information not deemed private","No stipulation (implied).\n"]
["9.4.4","Responsibility to protect private information\n","No stipulation (implied).\n"]
["9.4.5","Notice and consent to use private information\n","No stipulation (implied).\n"]
["9.4.6","Disclosure pursuant to judicial or administrative process\n","No stipulation (implied).\n"]
["9.4.7","Other information disclosure circumstances\n","No stipulation (implied).\n"]
[9.5,"Intellectual property rights","No stipulation (implied).\n"]
[9.6,"Representations and warranties","No stipulation (implied).\n"]
["9.6.1","CA representations and warranties","The Root CA SHALL be responsible for the performance and warranties of the Subordinate CA, for the Subordinate CA’s compliance with these Requirements, and for all liabilities and indemnification obligations of the Subordinate CA under these Requirements, as if the Root CA were the Subordinate CA issuing the Certificates\n","Section 9.6.1","Section 9.6.1"]
["9.6.2","RA representations and warranties","No stipulation.\n"]
["9.6.3","Subscriber representations and warranties","The CA SHALL require, as part of the Subscriber Agreement or Terms of Use, that the Applicant make the commitments and warranties in this section for the benefit of the CA and the Certificate Beneficiaries.\n","Section 9.6.3","Section 9.6.3"]
["9.6.3","Subscriber representations and warranties","Prior to the issuance of a Certificate, the CA SHALL obtain, for the express benefit of the CA and the Certificate Beneficiaries, either:\n\n1. The Applicant’s agreement to the Subscriber Agreement with the CA, or\n2. The Applicant’s acknowledgement of the Terms of Use.\n","Section 9.6.3","Section 9.6.3"]
["9.6.3","Subscriber representations and warranties","The CA SHALL implement a process to ensure that each Subscriber Agreement or Terms of Use is legally enforceable against the Applicant. In either case, the Agreement MUST apply to the Certificate to be issued pursuant to the certificate request.\n","Section 9.6.3","Section 9.6.3"]
["9.6.3","Subscriber representations and warranties","The Subscriber Agreement or Terms of Use MUST contain provisions imposing on the Applicant itself (or made by the Applicant on behalf of its principal or agent under a subcontractor or hosting service relationship) the following obligations and warranties:\n\n1. Accuracy of Information: An obligation and warranty to provide accurate and complete information at all times to the CA, both in the certificate request and as otherwise requested by the CA in connection with the issuance of the Certificate(s) to be supplied by the CA;\n\n2. Protection of Private Key: An obligation and warranty by the Applicant to take all reasonable measures to assure control of, keep confidential, and properly protect at all times the Private Key that corresponds to the Public Key to be included in the requested Certificate(s) (and any associated activation data or device, e.g. password or token);\n\n3. Acceptance of Certificate: An obligation and warranty that the Subscriber will review and verify the Certificate contents for accuracy;\n\n4. Use of Certificate: An obligation and warranty to install the Certificate only on servers that are accessible at the subjectAltName(s) listed in the Certificate, and to use the Certificate solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement or Terms of Use;\n\n5. Reporting and Revocation: An obligation and warranty to:\na. promptly request revocation of the Certificate, and cease using it and its associated Private Key, if there is any actual or suspected misuse or compromise of the Subscriber’s Private Key associated with the Public Key included in the Certificate, and \nb. promptly request revocation of the Certificate, and cease using it, if any information in the Certificate is or becomes incorrect or inaccurate;\n\n6. Termination of Use of Certificate: An obligation and warranty to promptly cease all use of the Private Key corresponding to the Public Key included in the Certificate upon revocation of that Certificate for reasons of Key Compromise.\n\n7. Responsiveness: An obligation to respond to the CA’s instructions concerning Key Compromise or Certificate misuse within a specified time period.\n\n8. Acknowledgment and Acceptance: An acknowledgment and acceptance that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the terms of the Subscriber Agreement or Terms of Use or if revocation is required by the CA’s CP, CPS, or these Baseline Requirements.","Section 9.6.3","Section 9.6.3"]
["9.6.4","Relying party representations and warranties","No stipulation (implied)."]
["9.6.5","Representations and warranties of other participants","No stipulation (implied)."]
[9.7,"Disclaimers of warranties","No stipulation (implied).\n"]
[9.8,"Limitations of liability","For delegated tasks, the CA and any Delegated Third Party MAY allocate liability between themselves contractually as they determine, but the CA SHALL remain fully responsible for the performance of all parties in accordance with these Requirements, as if the tasks had not been delegated.\n","N/A","N/A","Besides acting as a CA, BJCA will also act as a RA and no third party will be entrusted as the RA."]
[9.8,"Limitations of liability","If the CA chooses to limit its liability for Certificates that are not issued or managed in compliance with these Requirements or its Certificate Policy and/or Certification Practice Statement, then the CA SHALL include the limitations on liability in the CA’s Certificate Policy and/or Certification Practice Statement.\n","Section 9.8","Section 9.8"]
[9.9,"Indemnities","Thus, except in the case where the CA is a government entity, the CA SHALL defend, indemnify, and hold harmless each Application Software Supplier for any and all claims, damages, and losses suffered by such Application Software Supplier related to a Certificate issued by the CA, regardless of the cause of action or legal theory involved. \n\nThis does not apply, however, to any claim, damages, or loss suffered by such Application Software Supplier related to a Certificate issued by the CA where such claim, damage, or loss was directly caused by such Application Software Supplier’s software displaying as not trustworthy a Certificate that is still valid, or displaying as trustworthy: (1) a Certificate that has expired, or (2) a Certificate that has been revoked (but only in cases where the revocation status is currently available from the CA online, and the application software either failed to check such status or ignored an indication of revoked status).\n","Section 9.9","Section 9.9"]
["9.10","Term and termination","No stipulation (implied).\n"]
["9.10.1","Term","No stipulation (implied).\n"]
["9.10.2","Termination","No stipulation (implied).\n"]
["9.10.3","Effect of termination and survival","No stipulation (implied).\n"]
[9.11,"Individual notices and communications with participants\n","No stipulation (implied).\n"]
[9.12,"Amendments","No stipulation (implied).\n"]
["9.12.1","Procedure for amendment","No stipulation (implied).\n"]
["9.12.2","Notification mechanism and period","No stipulation (implied).\n"]
["9.12.3","Circumstances under which OID must be changed\n","No stipulation (implied).\n"]
[9.13,"Dispute resolution provisions","No stipulation (implied).\n"]
[9.14,"Governing law","No stipulation (implied).\n"]
[9.15,"Compliance with applicable law","No stipulation (implied).\n"]
[9.16,"Miscellaneous provisions","No stipulation (implied).\n"]
["9.16.1","Entire agreement","No stipulation (implied).\n"]
["9.16.2","Assignment","No stipulation (implied).\n"]
[9.15,"Compliance with applicable law","The CA SHALL issue Certificates and operate its PKI in accordance with all law applicable to its business and the Certificates it issues in every jurisdiction in which it operates.","Section 9.15","Section 9.15"]
["9.16.3","Severability","In the event of a conflict between these Requirements and a law, regulation or government order (hereinafter ‘Law’) of any jurisdiction in which a CA operates or issues certificates, a CA MAY modify any conflicting requirement to the minimum extent necessary to make the requirement valid and legal in the jurisdiction. This applies only to operations or certificate issuances that are subject to that Law. \n\nIn such event, the CA SHALL immediately (and prior to issuing a certificate under the modified requirement) include in Section 9.16.3 of the CA’s CPS a detailed reference to the Law requiring a modification of these Requirements under this section, and the specific modification to these Requirements implemented by the CA.\n","Section 9.16.3","Section 9.16.3"]
["9.16.3","Severability","The CA MUST also (prior to issuing a certificate under the modified requirement) notify the CA/Browser Forum of the relevant information newly added to its CPS by sending a message to questions@cabforum.org and receiving confirmation that it has been posted to the Public Mailing List and is indexed in the Public Mail Archives available at https://cabforum.org/pipermail/public/ (or such other email addresses and links as the Forum may designate), so that the CA/Browser Forum may consider possible revisions to these Requirements accordingly.\n","Section 9.16.3","Section 9.16.3"]
["9.16.3","Severability","Any modification to CA practice enabled under this section MUST be discontinued if and when the Law no longer applies, or these Requirements are modified to make it possible to comply with both them and the Law simultaneously. \n\nAn appropriate change in practice, modification to the CA’s CPS and a notice to the CA/Browser Forum, as outlined above, MUST be made within 90 days.\n","Section 9.16.3","Section 9.16.3"]
["9.16.4","Enforcement (attorneys’ fees and waiver of rights)\n","No stipulation (implied).\n"]
["9.16.5","Force Majeure","No stipulation (implied).\n"]
[9.17,"Other provisions","No stipulation (implied).\n"]

{"sheet":"NCSSRs v. 1.7 Self Assessment","index":5,"n_rows":49,"n_cols":6,"rows_kept":49,"cut":false,"hidden":false,"merged":[[1,0,1,5],[2,0,2,5],[15,0,15,5],[16,0,16,5],[32,0,32,5],[41,0,41,5],[42,0,42,5]]}
["SECTION","SECTION NAME","REQUIREMENT from NetSec SSRs (Version 1.7)","CURRENTLY COMPLY and INTEND TO CONTINUE COMPLIANCE","CA COMMENTS (Optional)","DETAILED ROOT PROGRAM REVIEW\nReviewer Comments (Highlight deficiencies in yellow for further review)"]
["1. General Protections for the Network and Supporting Systems"]
["Each CA or Delegated Third Party SHALL:"]
["1.a","General Protections for the Network and Supporting Systems","Segment Certificate Systems into networks based on their functional or logical relationship, for example separate physical networks or VLANs;",true,"See Section 6.7 of CPS\n"]
["1.b","General Protections for the Network and Supporting Systems","Apply equivalent security controls to all systems co-located in the same network with a Certificate System;",true]
["1.c","General Protections for the Network and Supporting Systems","Maintain Root CA Systems in a High Security Zone and in an offline state or air-gapped from all other networks;",true]
["1.d","General Protections for the Network and Supporting Systems","Maintain and protect Issuing Systems, Certificate Management Systems, and Security Support Systems in at least a Secure Zone;",true]
["1.e","General Protections for the Network and Supporting Systems","Implement and configure Security Support Systems that protect systems and communications between systems inside Secure Zones and High Security Zones, and communications with non-Certificate Systems outside those zones (including those with organizational business units that do not provide PKI-related services) and those on public networks;",true]
["1.f","General Protections for the Network and Supporting Systems","Configure each network boundary control (firewall, switch, router, gateway, or other network control device or system) with rules that support only the services, protocols, ports, and communications that the CA has identified as necessary to its operations;",true]
["1.g","General Protections for the Network and Supporting Systems","Configure Issuing Systems, Certificate Management Systems, Security Support Systems, and Front-End / Internal-Support Systems by removing or disabling all accounts, applications, services, protocols, and ports that are not used in the CA’s or Delegated Third Party’s operations and allowing only those that are approved by the CA or Delegated Third Party;",true]
["1.h","General Protections for the Network and Supporting Systems","Ensure that the CA’s security policies encompass a change management process, following the principles of documentation, approval and review, and to ensure that all changes to Certificate Systems, Issuing Systems, Certificate Management Systems, Security Support Systems, and Front-End / Internal-Support Systems follow said change management process;",true]
["1.i","General Protections for the Network and Supporting Systems","Grant administration access to Certificate Systems only to persons acting in Trusted Roles and require their accountability for the Certificate System’s security;",true]
["1.j","General Protections for the Network and Supporting Systems","Implement Multi-Factor Authentication to each component of the Certificate System that supports Multi-Factor Authentication;",true,"See Section 6.5.1 of CPS\n"]
["1.k","General Protections for the Network and Supporting Systems","Change authentication keys and passwords for any privileged account or service account on a Certificate System whenever a person’s authorization to administratively access that account on the Certificate System is changed or revoked; and",true]
["1.l","General Protections for the Network and Supporting Systems","Apply recommended security patches to Certificate Systems within six (6) months of the security patch's availability, unless the CA documents that the security patch would introduce additional vulnerabilities or instabilities that outweigh the benefits of applying the security patch.",true]
["2. Trusted Roles, Delegated Third Parties, and System Accounts"]
["Each CA or Delegated Third Party SHALL:"]
["2.a","Trusted Roles, Delegated Third Parties, and System Accounts","Follow a documented procedure for appointing individuals to Trusted Roles and assigning responsibilities to them;",true]
["2.b","Trusted Roles, Delegated Third Parties, and System Accounts","Document the responsibilities and tasks assigned to Trusted Roles and implement “separation of duties” for such Trusted Roles based on the security-related concerns of the functions to be performed;",true]
["2.c","Trusted Roles, Delegated Third Parties, and System Accounts","Ensure that only personnel assigned to Trusted Roles have access to Secure Zones and High Security Zones;",true]
["2.d","Trusted Roles, Delegated Third Parties, and System Accounts","Ensure that an individual in a Trusted Role acts only within the scope of such role when performing administrative tasks assigned to that role;",true]
["2.e","Trusted Roles, Delegated Third Parties, and System Accounts","Require employees and contractors to observe the principle of “least privilege” when accessing, or when configuring access privileges on, Certificate Systems;",true]
["2.f","Trusted Roles, Delegated Third Parties, and System Accounts","Require that each individual in a Trusted Role use a unique credential created by or assigned to that person in order to authenticate to Certificate Systems (for accountability purposes, group accounts or shared role credentials SHALL NOT be used);",true]
["2.g","Trusted Roles, Delegated Third Parties, and System Accounts","If an authentication control used by a Trusted Role is a username and password, then, where technically feasible, implement the following controls:\n\n* For accounts that are accessible only within Secure Zones or High Security Zones, require that passwords have at least twelve (12) characters;\n\n* For authentications which cross a zone boundary into a Secure Zone or High Security Zone, require Multi-Factor Authentication. For accounts accessible from outside a Secure Zone or High Security Zone require passwords that have at least eight (8) characters and are not be one of the user's previous four (4) passwords; and implement account lockout for failed access attempts in accordance with subsection k;\n\n* When developing password policies, CAs SHOULD take into account the password guidance in NIST 800-63B Appendix A.\n\n* Frequent password changes have been shown to cause users to select less secure passwords. If the CA has any policy that specifies routine periodic password changes, that period SHOULD NOT be less than two years. Effective April 1, 2020, if the CA has any policy that requires routine periodic password changes, that period SHALL NOT be less than two years.",true]
["2.h","Trusted Roles, Delegated Third Parties, and System Accounts","Have a policy that requires Trusted Roles to log out of or lock workstations when no longer in use;",true]
["2.i","Trusted Roles, Delegated Third Parties, and System Accounts","Have a procedure to configure workstations with inactivity time-outs that log the user off or lock the workstation after a set time of inactivity without input from the user (the CA or Delegated Third Party MAY allow a workstation to remain active and unattended if the workstation is otherwise secured and running administrative tasks that would be interrupted by an inactivity time-out or system lock);",true]
["2.j","Trusted Roles, Delegated Third Parties, and System Accounts","Review all system accounts at least every three (3) months and deactivate any accounts that are no longer necessary for operations;",true]
["2.k","Trusted Roles, Delegated Third Parties, and System Accounts","Lockout account access to Certificate Systems after no more than five (5) failed access attempts, provided that this security measure;\n\n* Is supported by the Certificate System,\n\n* Cannot be leveraged for a denial of service attack, and\n\n* Does not weaken the security of this authentication control;",true]
["2.l","Trusted Roles, Delegated Third Parties, and System Accounts","Implement a process that disables all privileged access of an individual to Certificate Systems within twenty four (24) hours upon termination of the individual’s employment or contracting relationship with the CA or Delegated Third Party;",true]
["2.m","Trusted Roles, Delegated Third Parties, and System Accounts","Enforce Multi-Factor Authentication OR multi-party authentication for administrator access to Issuing Systems and Certificate Management Systems;",true]
["2.n","Trusted Roles, Delegated Third Parties, and System Accounts","Enforce Multi-Factor Authentication for all Trusted Role accounts on Certificate Systems (including those approving the issuance of a Certificate, which equally applies to Delegated Third Parties) that are accessible from outside a Secure Zone or High Security Zone; and",true]
["2.o","Trusted Roles, Delegated Third Parties, and System Accounts","Restrict remote administration or access to an Issuing System, Certificate Management System, or Security Support System except when:\n\n* the remote connection originates from a device owned or controlled by the CA or Delegated Third Party,\n\n* the remote connection is through a temporary, non-persistent encrypted channel that is supported by Multi-Factor Authentication, and\n\n* the remote connection is made to a designated intermediary device that is (i) located within the CA’s network, (ii) secured in accordance with these Requirements, and (iii) that mediates the remote connection to the Issuing System.",true]
["3. Logging, Monitoring, and Alerting"]
["Certification Authorities and Delegated Third Parties SHALL:"]
["3.a","Logging, Monitoring, and Alerting","Implement a System under the control of CA or Delegated Third Party Trusted Roles that continuously monitors, detects, and alerts personnel to any modification to Certificate Systems, Issuing Systems, Certificate Management Systems, Security Support Systems, and Front-End / Internal-Support Systems unless the modification has been authorized through a change management process. The CA or Delegated Third Party shall respond to the alert and initiate a plan of action within at most twenty-four (24) hours;",true]
["3.b","Logging, Monitoring, and Alerting","Identify those Certificate Systems under the control of CA or Delegated Third Party Trusted Roles capable of monitoring and logging system activity, and enable those systems to log and continuously monitor the events specified in Section 5.4.1 (3) of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates;",true]
["3.c","Logging, Monitoring, and Alerting","Implement automated mechanisms under the control of CA or Delegated Third Party Trusted Roles to process logged system activity and alert personnel, using notices provided to multiple destinations, of possible Critical Security Events;",true]
["3.d","Logging, Monitoring, and Alerting","Require Trusted Role personnel to follow up on alerts of possible Critical Security Events;",true]
["3.e","Logging, Monitoring, and Alerting","Monitor the integrity of the logging processes for application and system logs through continuous automated monitoring and alerting or through a human review to ensure that logging and log-integrity functions are effective. Alternatively, if a human review is utilized and the system is online, the process must be performed at least once every 31 days.",true]
["3.f","Logging, Monitoring, and Alerting","Monitor the archival and retention of logs to ensure that logs are retained for the appropriate amount of time in accordance with the disclosed business practices and applicable legislation.",true,"See Section 5.4.3 of CPS\n"]
["3.g","Logging, Monitoring, and Alerting","If continuous automated monitoring and alerting is utilized to satisfy sections 1.h. or 3.e. of these Requirements, respond to the alert and initiate a plan of action within at most twenty-four (24) hours.",true]
["4. Vulnerability Detection and Patch Management"]
["Certification Authorities and Delegated Third Parties SHALL:"]
["4.a","Vulnerability Detection and Patch Management","Implement intrusion detection and prevention controls under the control of CA or Delegated Third Party Trusted Roles to protect Certificate Systems against common network and system threats;",true,"See Section 6.7 of CPS\n"]
["4.b","Vulnerability Detection and Patch Management","Document and follow a vulnerability correction process that addresses the identification, review, response, and remediation of vulnerabilities;",true]
["4.c","Vulnerability Detection and Patch Management","Undergo or perform a Vulnerability Scan\n\n(1) within one (1) week of receiving a request from the CA/Browser Forum,\n\n(2) after any system or network changes that the CA determines are significant, and\n\n(3) at least every three (3) months, on public and private IP addresses identified by the CA or Delegated Third Party as the CA’s or Delegated Third Party’s Certificate Systems;",true,"See Section 5.4.8 of CPS"]
["4.d","Vulnerability Detection and Patch Management","Undergo a Penetration Test on the CA’s and each Delegated Third Party’s Certificate Systems on at least an annual basis and after infrastructure or application upgrades or modifications that the CA determines are significant;",true,"See Section 5.4.8 of CPS"]
["4.e","Vulnerability Detection and Patch Management","Record evidence that each Vulnerability Scan and Penetration Test was performed by a person or entity (or collective group thereof) with the skills, tools, proficiency, code of ethics, and independence necessary to provide a reliable Vulnerability Scan or Penetration Test; and",true]
["4.f","Vulnerability Detection and Patch Management","Do one of the following within ninety-six (96) hours of discovery of a Critical Vulnerability not previously addressed by the CA’s vulnerability correction process:\n\n(1) Remediate the Critical Vulnerability;\n\n(2) If remediation of the Critical Vulnerability within ninety-six (96) hours is not possible, create and implement a plan to mitigate the Critical Vulnerability, giving priority to\n\ni. vulnerabilities with high CVSS scores, starting with the vulnerabilities the CA determines are the most critical (such as those with a CVSS score of 10.0) and ii. systems that lack sufficient compensating controls that, if the vulnerability were left unmitigated, would allow external system control, code execution, privilege escalation, or system compromise; or\n\n(3) Document the factual basis for the CA’s determination that the vulnerability does not require remediation because\n\ni. the CA disagrees with the NVD rating, ii. the identification is a false positive, iii. the exploit of the vulnerability is prevented by compensating controls or an absence of threats; or iv. other similar reasons.",true]

{"sheet":"Chrome Root Program Policy v. 1","index":6,"n_rows":42,"n_cols":6,"rows_kept":42,"cut":false,"hidden":false,"merged":[[1,0,1,5],[3,0,3,5],[5,0,5,5],[9,0,9,5],[11,0,11,5],[15,0,15,5],[22,0,22,5],[27,0,27,5],[33,0,33,5],[36,0,36,5]]}
["SECTION","SECTION NAME","CHROME ROOT PROGRAM POLICY v1.2 REQUIREMENT","CURRENTLY COMPLY and INTEND TO CONTINUE COMPLIANCE","CA COMMENTS (Optional)","DETAILED ROOT PROGRAM REVIEW\nReviewer Comments (Highlight deficiencies in yellow for further review)"]
["Overview"]
[null,"Minimum Requirements","CA owners with certificates included in the Chrome Root Store must satisfy the requirements defined in this policy, including taking responsibility for ensuring the continued compliance of all corresponding subordinate CAs and delegated third parties participating in the Public Key Infrastructure (PKI).",true]
["1. Baseline Requirements"]
[1,"Baseline Requirements","Applicants and CA owners with certificates included in the Chrome Root Store must adhere to the latest version of the CA/Browser Forum “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” (“Baseline Requirements”).",true,"See Section 1.1.2 of CPS\n"]
["2. Operator Policies"]
[2,"CA Operator Policies","Applicants and CA owners with certificates included in the Chrome Root Store must accurately describe the policies and practices of their CA(s) within a Certificate Policy (CP) and corresponding Certification Practice Statement (CPS).\n\nThese documents must provide sufficient detail to assess the operations of the CA(s) and the compliance with these expectations and those of the Baseline Requirements, and must not conflict with either of these requirements.",true]
[2,"CA Operator Policies","These documents must be freely publicly available for examination, and include at least an authoritative English language version.",true,"Chinese-English Bilingual Version"]
[2,"CA Operator Policies","CA owners must upload updated versions of a CA’s CP, CPS, or CP/CPS to its own publicly accessible policy repository and update CCADB within seven days of the update being completed.",true]
["3. Modern Infrastructures"]
[3,"Modern Infrastructures","The Chrome Root Store will only accept applicant root CA certificates with corresponding key material generated within five years of application to the Chrome Root Store.",true]
["4. Dedicated TLS PKI Hierarchies"]
[4,"Dedicated TLS PKI Hierarchies","The Chrome Root Store will only accept applicant root CA certificates that are part of PKI hierarchies dedicated to TLS certificate issuance.",true]
[4,"Dedicated TLS PKI Hierarchies","All corresponding subordinate CA certificates operated beneath a root CA must:\n- include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of either:\n-- id-kp-serverAuth, or\n-- id-kp-serverAuth and id-kp-clientAuth\n- not contain a public key corresponding to any other unexpired or non-revoked certificate that asserts different extendedKeyUsage values.",true]
[4,"Dedicated TLS PKI Hierarchies","All corresponding subscriber certificates must:\n- include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of either:\n-- id-kp-serverAuth, or\n-- id-kp-serverAuth and id-kp-clientAuth",true]
["5. Audits"]
[5,"Audits","Both applicant CAs and those with certificates already included in the Chrome Root Store, along with all corresponding subordinate CAs, must be audited in accordance with the table below.",true]
[5,"Audits","For a Root CA, Cross-certified Subordinate CA, TLS Subordinate CA, or Technically Constrained TLS Subordinate CA:\n\nIf WebTrust…\nWebTrust Principles and Criteria for Certification Authorities; and\nWebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security\n[and WebTrust for CAs - EV SSL, if issuing EV]\n \nor…\n \nIf ETSI*…\nETSI EN 319 411-1 LCP and [DVCP or OVCP]; or\nETSI EN 319 411-1 [NCP or NCP+] and EVCP (if issuing EV)",true]
[5,"Audits","For a Technically Constrained Non-TLS Subordinate CA:\n\nMinimally expected to be audited as defined in Section 8.7 of the BRs (self-audit).",true]
[5.1,"Annual Audits","CAs must retain an unbroken, contiguous audit coverage.\n\nRecurring complete (i.e., “full”, “full system” or “full re-assessment”) annual audits must begin once a CA’s key material has been generated and must continue until the corresponding root CA’s key material has been destroyed or is no longer included in the Chrome Root Store.",true]
[5.2,"Ad-Hoc Audits","Root CA certificate key material generation must be observed and audited by a Qualified Auditor who is unaffiliated with the CA owner, as described and required by Section 6.1.1.1 of the Baseline Requirements.",true]
[5.3,"Reporting Requirements","Reports for both annual and ad-hoc audits must satisfy the requirements in Section 8.6 of the Baseline Requirements and be uploaded to the CCADB within 90 days from the ending date specified in the audit letter.",true]
["6. Annual Self-Assessments"]
[6,"Annual Self-Assessments","Beginning in 2023, on an annual basis, CA owners with certificates included in the Chrome Root Store must complete and submit to the CCADB a self-assessment evaluating the conformance of their policies and practices against this policy and the Baseline Requirements for:\n- each root CA certificate included in the Chrome Root Store.\n- any corresponding subordinate CA certificate technically capable of issuing TLS certificates (i.e., explicitly contains an extendedKeyUsage value of id-kp-serverAuth or the functional equivalent, for example, due to the absence of any extendedKeyUsage values).",true]
[6,"Annual Self-Assessments","A single self-assessment may cover multiple CAs operating under both the same CP and CPS, or combined CP/CPS. If a consolidated self-assessment is submitted, the CA operator must enumerate the CAs in the scope of the self-assessment.",true]
[6,"Annual Self-Assessments","Completed self-assessments must be submitted to the CCADB within 90 days from the “BR Audit Period End Date” field specified in the root CA’s “CA Owner/Certificate” CCADB record.",true]
[6,"Annual Self-Assessments","All applicants must submit a completed self-assessment to the CCADB before requesting a CA certificate’s inclusion in the Chrome Root Store.",true]
["7. Responding to Incidents"]
[7,"Incidents","All applicants and CA owners with certificates included in the Chrome Root Store must abide by their CP and/or CPS, where they describe how the CA is operated, and must incorporate the Baseline Requirements.",true]
[7,"Reporting Incidents","Any suspected or actual incident must be reported and publicly disclosed at the time of discovery by the CA owner, along with a timeline for an analysis of root causes, regardless of perceived impact on end users.",true]
[7,"Reporting Incidents","CA owners must be detailed, candid, timely, and transparent in describing their architecture, implementation, operations, and external dependencies as necessary for the Chrome Root Program and the public to evaluate the nature of the incident and the CA owner’s response.",true]
[7,"Reporting Incidents","CA owners must file an incident report if they fail to meet the commitments made in their CP, CPS, or CP/CPS.",true]
[7,"Reporting Incidents","When a CA owner becomes aware of or suspects an incident, they must notify chrome-root-program@google.com with a description of the incident. \n\nIf the CA owner has publicly disclosed this incident, this notification must include a link to the disclosure.",true]
["8. Common CA Database"]
[8,"Common CA Database","All applicants and CA owners with certificates included in the Chrome Root Store must follow the requirements defined in the CCADB policy. In instances where the CCADB policy conflicts with this policy, this policy must take precedence.",true]
[8,"Common CA Database","Minimally, CA owners with certificates included in the Chrome Root Store must ensure information stored in the CCADB is reviewed monthly and updated when changes occur.",true]
["9. Timely and Transparent Communications"]
[9,"Timely and Transparent Communications","At any time, the Chrome Root Program may request additional information from a CA owner using email or CCADB communications to verify the commitments and obligations outlined in this policy are being met. CA owners must provide the requested information within 14 days unless specified otherwise.",true]
[9.1,"Notification of Cross-Certificate Issuance","CA owners must notify chrome-root-program@google.com at least three weeks before issuing a certificate to any CA owned or operated by a different CA owner that can validate to a corresponding root CA certificate included in the Chrome Root Store.\n\nThe notification must include:\n\n- the intended issuing CA certificate’s SHA-256 hash,\n- the intended subject CA certificate’s DN,\n- the intended date of certificate issuance,\n- the organization responsible for operating the intended subject CA,\n- the organization that owns the intended subject CA’s key material,\n- the organization providing RA services for the intended subject CA,\n- all relevant audit reports related to the intended subject CA,\n- a detailed description of the process the intended issuing CA owner used to evaluate the conformance of the intended subject CA and subject CA owner against its own policies, the Baseline Requirements, and this policy,\n- all relevant artifacts related to the evaluation of the intended subject CA and subject CA owner (including CP, CPS, subscriber agreements, assessment methodology, outputs from the assessment process, assessor qualifications, etc.),\n- a detailed description of the intended issuing CA owner’s planned compliance monitoring activities and oversight functions for the intended subject CA and subject CA owner, and\n- an explicit acknowledgment that the intended subject CA and subject CA owner satisfy the requirements defined in this policy.",true,"BJCA understands and complies with this regulation, but BJCA has no plans to issue cross-certificate."]
[9.1,"Notification of Cross-Certificate Issuance","Cross-certificates must not be issued without the expressed approval of the Chrome Root Program.",true,"BJCA understands and complies with this regulation, but BJCA has no plans to issue cross-certificate."]
[9.2,"Notification of Procurement, Sale, or other Change Control Events","CA owners with CAs included in the Chrome Root Store must not assume trust is transferable.",true]
[9.2,"Notification of Procurement, Sale, or other Change Control Events","Where permissible by law, CA owners must notify chrome-root-program@google.com at least 30 days before any impending:\n\n- procurements,\n- sales,\n- changes of ownership or operating control,\n- cessations of operations, or\n- other change control events involving PKI components that would materially affect the ongoing operations or perceived trustworthiness of a CA whose certificate is included in the Chrome Root Store (e.g., changes to operational location(s)).",true]

{"sheet":"Mozilla Compliance Self Assessm","index":7,"n_rows":93,"n_cols":5,"rows_kept":93,"cut":false,"hidden":false,"merged":[]}
[null,"Mozilla Root Store Policy v.2.8"]
["RFC 3647*","MOZILLA REQUIREMENT","CURRENTLY COMPLY and INTEND TO CONTINUE COMPLIANCE","CA COMMENTS (Optional)","DETAILED ROOT PROGRAM REVIEW\nReviewer Comments (Highlight deficiencies in yellow for further review)"]
["*","Recommended section of RFC 3647 framework for information to appear in CP or CPS."]
[1,"INTRODUCTION"]
[1,"CP/CPS information must fully and publicly disclose CA practices, in English and in RFC 3647 format, on the CA's website.",true,"Chinese-English Bilingual Version"]
["MRSP 3.3","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses"]
["Wiki","https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS"]
[]
["1.1 or 1.3.1","Clearly indicate which CAs are covered by the CP/CPS.",true]
["MRSP 3.3","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses"]
["Wiki","https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CA_Hierarchy"]
[]
["1.2.2, 2.3, or Revision Table","CP/CPS must be updated at least every 12 months.",true]
["MRSP 3.3","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses"]
["Wiki","https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Revision_Table"]
[]
[2,"PUBLICATION AND REPOSITORY RESPONSIBILITIES"]
[2.2,"CP/CPS has a commitment to comply with CA/Browser Forum requirements",true]
["MRSP 2.3","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#23-baseline-requirements-conformance"]
["Wiki","https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_Commitment_to_Comply_statement_in_CP.2FCPS"]
[]
[2.4,"All Audit, CP, CPS documents will be kept and made available as required by Mozilla Policy and the BRs.",true]
["MRSP 3.3","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses"]
["Wiki","https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Complete_Audit_History"]
[]
[3,"IDENTIFICATION AND AUTHENTICATION"]
["3.2.2.4","The CP/CPS clearly specifies the methods and procedures that the CA employs for domain validation.",true]
["MRSP 2.2","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#22-validation-practices"]
["MRSP 3.3","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses"]
["Wiki","https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Domain_Name_Ownership"]
["Wiki","https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Non-Standard_Email_Address_Prefixes_for_Domain_Ownership_Validation"]
[]
["3.2.4","All information provided by subscribers is verified using an independent source of information or an alternative communication channel before it is included in the certificate.",true]
["MRSP 2.2","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#22-validation-practices"]
[]
["3.2.6","The CA must notify Mozilla prior to issuing a cross-certificate or unconstrained CA certificate to an external third party.",true,"BJCA understands and complies with this regulation, but BJCA has no plans to issue cross-certificate or unconstrained CA certificate to an external third party."]
["MRSP 5.3","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#53-intermediate-certificates"]
["MRSP 8.4","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#84-externally-operated-subordinate-cas"]
["Wiki","https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Allowing_External_Entities_to_Operate_Subordinate_CAs"]
[]
[4,"CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS"]
["4.3.1","CAs should use pre-issuance linting because it reduces the number of misissuance events.",true]
["Wiki","https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Pre-Issuance_Linting"]
[]
["4.3.1","It is presumed that for each precertificate a corresponding certificate exists. Therefore, CAs must have the means to provide OCSP and revoke the serial number of any precertificate.",true]
["MRSP 5.4","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#54-precertificates"]
["Wiki","https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates"]
[]
["4.3.1 or 6.5.1","CAs must “enforce multi-factor authentication for all accounts capable of causing certificate issuance or performing Registration Authority or Delegated Third Party functions, or implement technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses”. ",true]
["MRSP 2.1","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#21-ca-operations"]
[]
["4.3.1","CAs must not backdate a certificate's notBefore date to avoid a deadline, prohibition, or code-enforced restriction.",true]
["Wiki","https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date"]
[]
["4.9.12","Section 4.9.12 of a CA operator's CPS (or, if applicable, the CP or \nCP/CPS) MUST clearly specify the methods that parties may use to \ndemonstrate private key compromise.",true]
["MRSP 6","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation"]
[]
[5,"CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS"]
["5.7.1","CAs must notify Mozilla in the event of CA key compromise or other major security incident.",true]
["MRSP 7","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#7-root-store-changes"]
[]
[6,"TECHNICAL SECURITY CONTROLS"]
["6.1.5","NIST P-521 is not an approved algorithm",true]
["MRSP 5.1","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#51-algorithms"]
[6.7,"CAs should incorporate the NetSec Requirements by reference in either section 5 or section 6.7 of their CP/CPS",true]
["Wiki","https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Network_Security_Controls"]
[]
[7,"CERTIFICATE, CRL, AND OCSP PROFILES"]
[]
["7.1.3","CAs SHALL NOT sign SHA-1 hashes over end entity certificates with an EKU extension containing the id-kp-emailProtection key purpose.",true]
["7.1.3; 7.2; 7.3","Effective July 1, 2023, CAs SHALL NOT sign SHA-1 hashes over:\ncertificates with an EKU extension containing the id-kp-ocspSigning key purpose; intermediate certificates that chain up to roots in Mozilla's program; OCSP responses; or CRLs.",true]
["MRSP 5.1.3","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#513-sha-1"]
[]
[8,"COMPLIANCE AUDIT AND OTHER ASSESSMENTS"]
[8.1,"CAs must maintain a Complete Audit History from cradle to grave with no gaps.",true]
["MRSP 3.1.3","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#313-audit-parameters"]
["MRSP 7.1","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#71-inclusions"]
["Wiki","https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Complete_Audit_History"]
[]
[8.2,"CAs must provide a Statement of Auditor Qualifications",true]
["MRSP 3.1.4","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#314-public-audit-information"]
["Wiki","https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications"]
[]
[8.4,"Audits must conform to either WebTrust or ETSI criteria",true]
["MRSP 3.1.2","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#312-required-audits"]
[]
[8.5,"Previously undisclosed incidents must be reported in Bugzilla and sufficiently remediated.",true]
["MRSP 2.2","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#24-incidents"]
["Wiki","https://wiki.mozilla.org/CA/Responding_To_An_Incident"]
[]
[9,"OTHER BUSINESS AND LEGAL MATTERS"]
[9.5,"The CP/CPS must be made available to Mozilla under one of the allowed Creative Commons licenses.",true]
["MRSP 3.3","https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses"]

{"sheet":"TLS EV v. 1.8.0 Self Assessment","index":8,"n_rows":107,"n_cols":6,"rows_kept":107,"cut":false,"hidden":false,"merged":[[1,0,1,5],[11,0,11,5],[30,0,30,5],[33,0,33,5],[73,0,73,5],[76,0,76,5],[78,0,78,5],[86,0,86,5],[88,0,88,5],[90,0,90,5],[98,0,98,5],[100,0,100,5],[102,0,102,5]]}
["SECTION","SECTION NAME","REQUIREMENT from EVGs (Version 1.8.0)","CURRENTLY COMPLY and INTEND TO CONTINUE COMPLIANCE","CA COMMENTS (Optional)","DETAILED ROOT PROGRAM REVIEW\nReviewer Comments (Highlight deficiencies in yellow for further review)"]
["8. Community and Applicability"]
[8.1,"Issuance of EV Certificates","If a court or government body with jurisdiction over the activities covered by these Guidelines determines that the performance of any mandatory requirement is illegal, then such requirement is considered reformed to the minimum extent necessary to make the requirement valid and legal. This applies only to operations or certificate issuances that are subject to the laws of that jurisdiction. \n\nThe parties involved SHALL notify the CA / Browser Forum of the facts, circumstances, and law(s) involved, so that the CA/Browser Forum may revise these Guidelines accordingly.",true,"See Section 9.16.3 of CPS"]
["8.2.1","EV Policies - Implementation","Each CA must develop, implement, enforce, display prominently on its Web site, and periodically update as necessary its own auditable EV Certificate practices, policies and procedures, such as a Certification Practice Statement (CPS) and Certificate Policy (CP) that:\n\nA. Implement the requirements of these Guidelines as they are revised from time-to-time;\n\nB. Implement the requirements of\ni. the then-current WebTrust Program for CAs, and\nii. the then-current WebTrust EV Program or ETSI TS 102 042 for EVCP or ETSI EN 319 411-1 for EVCP policy; and\n\nC. Specify the CA’s and its Root CA’s entire root certificate hierarchy including all roots that its EV Certificates depend on for proof of those EV Certificates’ authenticity.",true,"See Section 1.1.3 and 1.5.5 of CPS\n"]
["8.2.2","EV Policies - Disclosure","Each CA MUST publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis.",true,"See Section 2.2 of CPS"]
["8.2.2","EV Policies - Disclosure","The CA SHALL publicly disclose its CA business practices to the extent required by the CA’s selected audit scheme (see Section 17.1).",true]
["8.2.2","EV Policies - Disclosure","The CA’s Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647. \n\nThe Certificate Policy and/or Certification Practice Statement MUST include all material required by RFC 3647.",true]
[8.3,"Commitment to Comply with Recommendations","Each CA SHALL publicly give effect to these Guidelines and represent that they will adhere to the latest published version by incorporating them into their respective EV Policies.",true,"See Section 1.1.2 of CPS\n"]
[8.3,"Commitment to Comply with Recommendations","In addition, the CA MUST include (directly or by reference) the applicable requirements of these Guidelines in all contracts with Subordinate CAs, RAs, Enterprise RAs, and subcontractors that involve or relate to the issuance or maintenance of EV Certificates.\n\nThe CA MUST enforce compliance with such terms.","N/A","Besides acting as a CA, BJCA will also act as a RA and no third party will be entrusted as the RA."]
[8.4,"Insurance","Each CA SHALL maintain the following insurance related to their respective performance and obligations under these Guidelines:\n\nA. Commercial General Liability insurance (occurrence form) with policy limits of at least two million US dollars in coverage; and\nB. Professional Liability/Errors and Omissions insurance, with policy limits of at least five million US dollars in coverage, and including coverage for:\ni. claims for damages arising out of an act, error, or omission, unintentional breach of contract, or neglect in issuing or maintaining EV Certificates, and;\nii. claims for damages arising out of infringement of the proprietary rights of any third party (excluding copyright, and trademark infringement), and invasion of privacy and advertising injury.\n\nSuch insurance must be with a company rated no less than A- as to Policy Holder’s Rating in the current edition of Best’s Insurance Guide (or with an association of companies each of the members of which are so rated).",true,"See Section 9.2.3 of CPS"]
["8.5.1","Obtaining EV Certificates - General","The CA MAY only issue EV Certificates to Applicants that meet the Private Organization, Government Entity, Business Entity and Non-Commercial Entity requirements specified below.\n\n(Sections 8.5.2 - 8.5.5)",true,"See Section 3.2.2.13 of CPS"]
["9. EV Certificate Content and Profile"]
[9.1,"Issuer Information","Issuer Information listed in an EV Certificate MUST comply with Section 7.1.4.1 of the Baseline Requirements.\n",true,"See Section 7.1.4 of CPS"]
[9.2,"Subject Distinguished Name Fields","Subject to the requirements of these Guidelines, the EV Certificate and certificates issued to Subordinate CAs that are not controlled by the same entity as the CA MUST include the following information about the Subject organization in the fields listed:\n\n- Subject Organization Name Field\n- Subject Common Name Field\n- Subject Business Category Field\n- Subject Jurisdiction of incorporation or Registration Field\n- Subject Registration Number Field\n- Subject Physical Address of Place of Business Field\n- Subject Organizational Unit Name Field\n- Subject Organization Identifier Field",true]
["9.2.1","Subject Organization Name Field\n","Certificate Field: subject:organizationName (OID 2.5.4.10)\nRequired/Optional: Required\nContents: This field MUST contain the Subject’s full legal organization name as listed in the official records of the Incorporating or Registration Agency in the Subject’s Jurisdiction of Incorporation or Registration or as otherwise verified by the CA as provided herein. A CA MAY abbreviate the organization prefixes or suffixes in the organization name, e.g., if the official record shows “Company Name Incorporated” the CA MAY include “Company Name, Inc.”\n\nWhen abbreviating a Subject’s full legal name as allowed by this subsection, the CA MUST use abbreviations that are not misleading in the Jurisdiction of Incorporation or Registration.\n\nIn addition, an assumed name or DBA name used by the Subject MAY be included at the beginning of this field, provided that it is followed by the full legal organization name in parenthesis. \n\nIf the combination of names or the organization name by itself exceeds 64 characters, the CA MAY abbreviate parts of the organization name, and/or omit non‐material words in the organization name in such a way that the text in this field does not exceed the 64-character limit; provided that the CA checks this field in accordance with Section 11.12.1 and a Relying Party will not be misled into thinking that they are dealing with a different organization. In cases where this is not possible, the CA MUST NOT issue the EV Certificate.",true,"See Section 7.1 of CPS\n"]
["9.2.2","Subject Common Name Field\n","Certificate Field: subject:commonName (OID: 2.5.4.3)\nRequired/Optional: Deprecated (Discouraged, but not prohibited)\nContents: If present, this field MUST contain a single Domain Name(s) owned or controlled by the Subject and to be associated with the Subject’s server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This field MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements.",true,"See Section 7.1 of CPS\n"]
["9.2.3","Subject Business Category Field","Certificate Field: subject:businessCategory (OID: 2.5.4.15)\nRequired/Optional: Required\nContents: This field MUST contain one of the following strings: “Private Organization”, “Government Entity”, “Business Entity”, or “Non-Commercial Entity” depending upon whether the Subject qualifies under the terms of Section 8.5.2, Section 8.5.3, Section 8.5.4 or Section 8.5.5, respectively.",true,"See Section 7.1 of CPS\n"]
["9.2.4","Subject Jurisdiction of Incorporation or Registration Field","Locality (if required):\nsubject:jurisdictionLocalityName (OID: 1.3.6.1.4.1.311.60.2.1.1)\nState or province (if required):\nsubject:jurisdictionStateOrProvinceName (OID: 1.3.6.1.4.1.311.60.2.1.2)\nCountry:\nsubject:jurisdictionCountryName (OID: 1.3.6.1.4.1.311.60.2.1.3)\nRequired/Optional: Required\nContents: These fields MUST NOT contain information that is not relevant to the level of the Incorporating Agency or Registration Agency. For example, the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information. Similarly, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both country and state or province information, but MUST NOT include locality information. And, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and state or province information, where the state or province regulates the registration of the entities at the locality level, as well as the locality information. Country information MUST be specified using the applicable ISO country code. State or province or locality information (where applicable) for the Subject’s\nJurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction.\n\nEffective as of 1 October 2020, the CA SHALL ensure that, at time of issuance, the values within these fields have been disclosed within the latest publicly-available disclosure, as described in Section 11.1.3, as acceptable values for the applicable Incorporating Agency or Registration Agency.",true,"See Section 7.1 of CPS\n"]
["9.2.5","Subject Registration Number Field","Certificate Field: subject:serialNumber (OID: 2.5.4.5)\nRequired/Optional: Required\nContents: For Private Organizations, this field MUST contain the Registration (or similar) Number assigned to the Subject by the Incorporating or Registration Agency in its Jurisdiction of Incorporation or Registration, as appropriate. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, then the date of Incorporation or Registration SHALL be entered into this field in any one of the common date formats.\n\nFor Government Entities that do not have a Registration Number or readily verifiable date of creation, the CA SHALL enter appropriate language to indicate that the Subject is a Government Entity.\n\nFor Business Entities, the Registration Number that was received by the Business Entity upon government registration SHALL be entered in this field. For those Business Entities that register with an Incorporating Agency or Registration Agency in a jurisdiction that does not issue numbers pursuant to government registration, the date of the registration SHALL be entered into this field in any one of the common date formats. \n\nEffective as of 1 October 2020, if the CA has disclosed a set of acceptable format or formats for Registration Numbers for the applicable Registration Agency or Incorporating Agency, as described in Section 11.1.3, the CA MUST ensure, prior to issuance, that the Registration Number is valid according to at least one currently disclosed format for that applicable Registration Agency or Incorporating agency.",true,"See Section 7.1 of CPS\n"]
["9.2.6","Subject Physical Address of Place of Business Field","Certificate Fields:\nNumber and street: subject:streetAddress (OID: 2.5.4.9) \nCity or town: subject:localityName (OID: 2.5.4.7)\nState or province (where applicable): subject:stateOrProvinceName (OID: 2.5.4.8)\nCountry: subject:countryName (OID: 2.5.4.6)\nPostal code: subject:postalCode (OID: 2.5.4.17)\nRequired/Optional: As stated in Section 7.1.4.2.2 d, e, f, g and h of the Baseline Requirements.\nContents: This field MUST contain the address of the physical location of the Subject’s Place of Business.",true,"See Section 7.1 of CPS\n"]
["9.2.7","Subject Organizational Unit Name Field","Certificate Field: subject:organizationalUnitName (OID: 2.5.4.11)\nRequired/Optional/Prohibited: Prohibited.",true,"See Section 7.1 of CPS\n"]
["9.2.8","Subject Organization Identifier Field","Certificate Field: subject:organizationIdentifier (OID: 2.5.4.97)\nRequired/Optional: Optional\nContents: If present, this field MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme.\n\nThe organizationIdentifier MUST be encoded as a PrintableString or UTF8String.\n\nThe Registration Scheme MUST be identified using the using the following structure in the presented order:\n• 3 character Registration Scheme identifier;\n• 2 character ISO 3166 country code for the nation in which the Registration Scheme is operated, or if the scheme is operated globally ISO 3166 code “XG” shall be used;\n• For the NTR Registration Scheme identifier, if required under Section 9.2.4, a 2 character ISO 3166-2 identifier for the subdivision (state or province) of the nation in which the Registration Scheme is operated, preceded by plus “+” (0x2B (ASCII), U+002B (UTF-8));\n• a hyphen-minus “-” (0x2D (ASCII), U+002D (UTF-8));\n• Registration Reference allocated in accordance with the identified Registration Scheme\n\nNote: Registration References MAY contain hyphens, but Registration Schemes, ISO 3166 country codes, and ISO 3166-2 identifiers do not. Therefore if more than one hyphen appears in the structure, the leftmost hyphen is a separator, and the remaining hyphens are part of the Registration Reference. \n\nAs in Section 9.2.4, the specified location information MUST match the scope of the registration being referenced.\n\nExamples:\n\n• NTRGB-12345678 (NTR scheme, Great Britain, Unique Identifier at Country level is 12345678)\n• NTRUS+CA-12345678 (NTR Scheme, United States - California, Unique identifier at State level is 12345678)\n• VATDE-123456789 (VAT Scheme, Germany, Unique Identifier at Country Level is 12345678)\n• PSDBE-NBB-1234.567.890 (PSD Scheme, Belgium, NCA’s identifier is NBB, Subject Unique Identifier assigned by the NCA is 1234.567.890)\n\n\nRegistration Schemes listed in Appendix H are currently recognized as valid under these guidelines.\n\nThe CA SHALL:\n1. confirm that the organization represented by the Registration Reference is the same as the organization named in the organizationName field as specified in Section 9.2.1 within the context of the subject’s jurisdiction as specified in Section 9.2.4;\n2. further verify the Registration Reference matches other information verified in accordance with Section 11;\n3. take appropriate measures to disambiguate between different organizations as described in Appendix H for each Registration Scheme;\n4. Apply the validation rules relevant to the Registration Scheme as specified in Appendix H.","N/A","Not stipulation. "]
["9.2.9","Other Subject Attributes","CAs SHALL NOT include any Subject Distinguished Name attributes except as specified in Section 9.2.\n",true,"See Section 7.1 of CPS\n"]
["9.3.2","EV Subscriber Certificates","Each EV Certificate issued by the CA to a Subscriber MUST contain a policy identifier that is either defined by these Guidelines or the CA in the certificate’s certificatePolicies extension that:\n\n1. indicates which CA policy statement relates to that Certificate,\n2. asserts the CA’s adherence to and compliance with these Guidelines, and\n3. is either the CA/Browser Forum’s EV policy identifier or a policy identifier that, by pre-agreement with the Application Software Supplier, marks the Certificate as being an EV Certificate.\n\nThe following Certificate Policy identifier is the CA/Browser Forum’s EV policy identifier: {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) ev-guidelines (1) } (2.23.140.1.1), if the Certificate complies with these Guidelines.",true,"See Section 1.2 of CPS\n"]
["9.3.4","EV Subordinate CA Certificates","1. Certificates issued to Subordinate CAs that are not controlled by the issuing CA MUST contain one or more policy identifiers defined by the issuing CA that explicitly identify the EV Policies that are implemented by the Subordinate CA.","N/A","All Subordinate CAs are operated and controlled by BJCA."]
["9.3.5","Subscriber Certificates","A Certificate issued to a Subscriber MUST contain one or more policy identifier(s), defined by the Issuing CA, in the Certificate’s certificatePolicies extension that indicates adherence to and compliance with these Guidelines. Each CA SHALL document in its Certificate Policy or Certification Practice Statement that the Certificates it issues containing the specified policy identifier(s) are managed in accordance with these Guidelines.",true,"See Section 1.2 of CPS\n"]
[9.4,"Maximum Validity Period For EV Certificate","The Validity Period for an EV Certificate SHALL NOT exceed 398 days.",true,"See Section 6.3.2 of CPS\n"]
[9.7,"Additional Technical Requirements for EV Certificates","All provisions of the Baseline Requirements concerning Minimum Cryptographic Algorithms, Key Sizes, and Certificate Extensions apply to EV Certificates with the following exceptions:\n\n1. If a Subordinate CA Certificates is issued to a Subordinate CA not controlled by the entity that controls the Root CA, the policy identifiers in the certificatePolicies extension MUST include the CA’s Extended Validation\npolicy identifier.\n\nOtherwise, it MAY contain the anyPolicy identifier.\n\n2. The following fields MUST be present if the Subordinate CA is not controlled by the entity that controls the Root CA.\n• certificatePolicies:policyQualifiers:policyQualifierId\nid-qt 1 [RFC 5280]\n• certificatePolicies:policyQualifiers:qualifier:cPSuri\nHTTP URL for the Root CA’s Certification Practice Statement\n\n3. The certificatePolicies extension in EV Certificates issued to Subscribers MUST include the following:\n• certificatePolicies:policyIdentifier (Required)\nThe Issuer’s EV policy identifier\n• certificatePolicies:policyQualifiers:policyQualifierId (Required)\nid-qt 1 [RFC 5280]\n• certificatePolicies:policyQualifiers:qualifier:cPSuri (Required)\nHTTP URL for the Subordinate CA’s Certification Practice Statement\n\n4. The cRLDistributionPoints extension MUST be present in Subscriber Certificates if the certificate does not specify OCSP responder locations in an authorityInformationAccess extension.",true,"See Section 7.1 of CPS\n"]
["9.8.1","Subject Alternative Name Extension","Certificate Field: subjectAltName:dNSName\nRequired/Optional: Required\nContents: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject’s server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This extension MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements.",true,"See Section 3.1.1 of CPS\n"]
["9.8.2","CA/Browser Forum Organization Identifier Extension","Extension Name: cabfOrganizationIdentifier (OID: 2.23.140.3.1)\nVerbose OID: {joint-iso-itu-t(2) international-organizations(23)\nca-browser-forum(140) certificate-extensions(3)\ncabf-organization-identifier(1) }\nRequired/Optional: Optional (but see below)\nContents: If the subject:organizationIdentifier is present, this field MUST be present.\n\nIf present, this extension MUST contain a Registration Reference for a Legal Entity assigned in accordance to the identified Registration Scheme.\n\nThe Registration Scheme MUST be encoded as described by the following ASN.1 grammar:\n\nid-CABFOrganizationIdentifier OBJECT IDENTIFIER ::= {\njoint-iso-itu-t(2) international-organizations(23)\nca-browser-forum(140) certificate-extensions(3)\ncabf-organizationIdentifier(1)\n}\n\next-CABFOrganizationIdentifier EXTENSION ::= {\nSYNTAX CABFOrganizationIdentifier\nIDENTIFIED BY id-CABFOrganizationIdentifier\n}\n\nCABFOrganizationIdentifier ::= SEQUENCE {\nregistrationSchemeIdentifier PrintableString (SIZE(3)),\nregistrationCountry PrintableString (SIZE(2)),\nregistrationStateOrProvince [0] IMPLICIT PrintableString\n(SIZE(0..128)) OPTIONAL,\nregistrationReference UTF8String\n}\n\nwhere the subfields have the same values, meanings, and restrictions described in Section 9.2.8. The CA SHALL validate the contents using the requirements in Section 9.2.8.\n",true]
["10. EV Certificate Request Requirements"]
["10.1.2","Role Requirements","The following Applicant roles are required for the issuance of an EV Certificate.\n\n1. Certificate Requester: The EV Certificate Request MUST be submitted by an authorized Certificate Requester. A Certificate Requester is a natural person who is either the Applicant, employed by the Applicant, an authorized agent who has express authority to represent the Applicant, or a third party (such as an ISP or hosting company) that completes and submits an EV Certificate Request on behalf of the Applicant.\n\n2. Certificate Approver: The EV Certificate Request MUST be approved by an authorized Certificate Approver. A Certificate Approver is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant to\n\ni. act as a Certificate Requester and to authorize other employees or third parties to act as a Certificate Requester, and\nii. to approve EV Certificate Requests submitted by other Certificate Requesters.\n\n3. Contract Signer: A Subscriber Agreement applicable to the requested EV Certificate MUST be signed by an authorized Contract Signer. A Contract Signer is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to sign Subscriber Agreements.\n\n4. Applicant Representative: In the case where the CA and the Subscriber are affiliated, Terms of Use applicable to the requested EV Certificate MUST be acknowledged and agreed to by an authorized Applicant Representative. An Applicant Representative is a natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to acknowledge and agree to the Terms of Use.",true,"See Section 3.2.2.13 of CPS\n"]
[10.3,"Requirements for Subscriber Agreement and Terms ofUse","Section 9.6.3 of the Baseline Requirements applies equally to EV Certificates. In cases where the Certificate Request does not contain all necessary information about the Applicant, the CA MUST additionally confirm the data with the Certificate Approver or Contract Signer rather than the Certificate Requester.",true,"See Section 3.2.2.13 of CPS"]
["11. Verification Requirements"]
["11.1.1","Verification Requirements – Overview","Before issuing an EV Certificate, the CA MUST ensure that all Subject organization information to be included in the EV Certificate conforms to the requirements of, and is verified in accordance with, these Guidelines and matches the information confirmed and documented by the CA pursuant to its verification processes. Such verification processes are intended to accomplish the following:\n\n1. Verify Applicant’s existence and identity, including;\n\nA. Verify the Applicant’s legal existence and identity (as more fully set forth in Section 11.2),\nB. Verify the Applicant’s physical existence (business presence at a physical address), and\nC. Verify the Applicant’s operational existence (business activity).\n\n2. Verify the Applicant is a registered holder, or has control, of the Domain Name(s) to be included in the EV Certificate;\n\n3. Verify a reliable means of communication with the entity to be named as the Subject in the Certificate;\n\n4. Verify the Applicant’s authorization for the EV Certificate, including;\n\nA. Verify the name, title, and authority of the Contract Signer, Certificate Approver, and Certificate Requester,\nB. Verify that a Contract Signer signed the Subscriber Agreement or that a duly authorized Applicant Representative acknowledged and agreed to the Terms of Use; and\nC. Verify that a Certificate Approver has signed or otherwise approved the EV Certificate Request.",true,"EV Certificate verification procedure conforms to the Extended Validation standard established by the CA/Browser Forum, and its verification process is clearly recorded in CPS 3.2.2.13"]
["11.1.3","Disclosure of Verification Sources","Effective as of 1 October 2020, prior to the use of an Incorporating Agency or Registration Agency to fulfill these verification requirements, the CA MUST publicly disclose Agency Information about the Incorporating Agency or Registration Agency.\nThis disclosure SHALL be through an appropriate and readily accessible online means.\n\nThis Agency Information SHALL include at least the following:\n• Sufficient information to unambiguously identify the Incorporating Agency or Registration Agency (such as a name, jurisdiction, and website); and,\n• The accepted value or values for each of the subject:jurisdictionLocalityName (OID: 1.3.6.1.4.1.311.60.2.1.1), subject:jurisdictionStateOrProvinceName (OID: 1.3.6.1.4.1.311.60.2.1.2), and subject:jurisdictionCountryName (OID: 1.3.6.1.4.1.311.60.2.1.3) fields, when a certificate is issued using information from that Incorporating Agency or Registration Agency, indicating the jurisdiction(s) that the Agency is appropriate for; and,\n• The acceptable form or syntax of Registration Numbers used by the Incorporating Agency or Registration Agency, if the CA restricts such Numbers to an acceptable form or syntax; and,\n• A revision history that includes a unique version number and date of publication for any additions, modifications, and/or removals from this list.\n\nThe CA MUST document where to obtain this information within Section 3.2 of the CA’s Certificate Policy and/or Certification Practice Statement.","N/A","Besides acting as a CA, BJCA will also act as a RA and no third party will be entrusted as the RA."]
["11.2.1","Verification Requirements","To verify the Applicant’s legal existence and identity, the CA MUST do the following.\n\n1. Private Organization Subjects\nA. Legal Existence: Verify that the Applicant is a legally recognized entity, in existence and validly formed (e.g., incorporated) with the Incorporating or Registration Agency in the Applicant’s Jurisdiction of Incorporation or Registration, and not designated on the records of the Incorporating or Registration Agency by labels such as “inactive”, “invalid”, “not current”, or the equivalent.\nB. Organization Name: Verify that the Applicant’s formal legal name as recorded with the Incorporating or Registration Agency in the Applicant’s Jurisdiction of Incorporation or Registration matches the Applicant’s name in the EV Certificate Request.\nC. Registration Number: Obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant’s Jurisdiction of Incorporation or Registration. Where the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant’s date of Incorporation or Registration.\nD. Registered Agent: Obtain the identity and address of the Applicant’s Registered Agent or Registered Office (as applicable in the Applicant’s Jurisdiction of Incorporation or Registration).\n\n2. Government Entity Subjects\nA. Legal Existence: Verify that the Applicant is a legally recognized Government Entity, in existence in the political subdivision in which such Government Entity operates.\nB. Entity Name: Verify that the Applicant’s formal legal name matches the Applicant’s name in the EV Certificate Request.\nC. Registration Number: The CA MUST attempt to obtain the Applicant’s date of incorporation, registration, or formation, or the identifier for the legislative act that created the Government Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is a Government Entity.\n\n3. Business Entity Subjects\nA. Legal Existence: Verify that the Applicant is engaged in business under the name submitted by the Applicant in the Application.\nB. Organization Name: Verify that the Applicant’s formal legal name as recognized by the Registration Agency in the Applicant’s Jurisdiction of Registration matches the Applicant’s name in the EV Certificate Request.\nC. Registration Number: Attempt to obtain the specific unique Registration Number assigned to the Applicant by the Registration Agency in the Applicant’s Jurisdiction of Registration. Where the Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant’s date of Registration.\nD. Principal Individual: Verify the identity of the identified Principal Individual.\n\n4. Non-Commercial Entity Subjects (International Organizations)\nA. Legal Existence: Verify that the Applicant is a legally recognized International Organization Entity.\nB. Entity Name: Verify that the Applicant’s formal legal name matches the Applicant’s name in the EV Certificate Request.\nC. Registration Number: The CA MUST attempt to obtain the Applicant’s date of formation, or the identifier for the legislative act that created the International Organization Entity. In circumstances where this information is not available, the CA MUST enter appropriate language to indicate that the Subject is an International Organization Entity.",true,"See Section 3.2.2.13 of CPS"]
["11.2.2 (1)","Acceptable Method of Verification","1. Private Organization Subjects: Unless verified under subsection (6), all items listed in Section 11.2.1 (1) MUST be verified directly with, or obtained directly from, the Incorporating or Registration Agency in the Applicant’s Jurisdiction of Incorporation or Registration. Such verification MAY be through use of a Qualified Government Information Source operated by, or on behalf of, the Incorporating or Registration Agency, or by direct contact with the Incorporating or Registration Agency in person or via mail, e-mail, Web address, or telephone, using an address or phone number obtained directly from the Qualified Government Information Source, Incorporating or Registration Agency, or from a Qualified Independent Information Source.\n",true,"See Section 3.2.2.13 of CPS\n"]
["11.2.2 (2)","Acceptable Method of Verification","2. Government Entity Subjects: Unless verified under subsection (6), all items listed in Section 11.2.1 (2) MUST either be verified directly with, or obtained directly from, one of the following:\n\ni. a Qualified Government Information Source in the political subdivision in which such Government Entity operates;\nii. a superior governing Government Entity in the same political subdivision as the Applicant (e.g. a Secretary of State may verify the legal existence of a specific State Department), or\niii. from a judge that is an active member of the federal, state or local judiciary within that political subdivision.\n\nAny communication from a judge SHALL be verified in the same manner as is used for verifying factual assertions that are asserted by an Attorney as set forth in Section 11.11.1.\n\nSuch verification MAY be by direct contact with the appropriate Government Entity in person or via mail, e-mail, Web address, or telephone, using an address or phone number obtained from a Qualified Independent Information Source.\n",true,"See Section 3.2.2.13 of CPS\n"]
["11.2.2 (3)","Acceptable Method of Verification","3. Business Entity Subjects: Unless verified under subsection (6), Items listed in Section 11.2.1 (3) (A) through (C) above, MUST be verified directly with, or obtained directly from, the Registration Agency in the Applicant’s Jurisdiction of Registration. Such verification MAY be performed by means of a Qualified Government Information Source, a Qualified Governmental Tax Information Source, or by direct contact with the Registration Agency in person or via mail, e-mail, Web address, or telephone, using an address or phone number obtained directly from the Qualified Government Information Source, Qualified Governmental Tax Information Source or Registration Agency, or from a Qualified Independent Information Source. In addition, the CA MUST validate a Principal Individual associated with the Business Entity pursuant to the requirements in subsection (4), below.\n",true,"See Section 3.2.2.13 of CPS\n"]
["11.2.2 (4)","Acceptable Method of Verification","4. Principal Individual: A Principal Individual associated with the Business Entity MUST be validated in a face-to-face setting. The CA MAY rely upon a face-to-face validation of the Principal Individual performed by the Registration Agency, provided that the CA has evaluated the validation procedure and concluded that it satisfies the requirements of the Guidelines for face-to-face validation procedures. Where no face-to-face validation was conducted by the Registration Agency, or the Registration Agency’s face-to-face validation procedure does not satisfy the requirements of the Guidelines, the CA SHALL perform face-to-face validation.\n\nA. Face-To-Face Validation: The face-to-face validation MUST be conducted before either an employee of the CA, a Latin Notary, a Notary (or equivalent in the Applicant’s jurisdiction), a Lawyer, or Accountant (Third-Party Validator). The Principal Individual(s) MUST present the following documentation (Vetting Documents) directly to the Third-Party Validator:\n\ni. A Personal Statement that includes the following information:\n\n1. Full name or names by which a person is, or has been, known (including all other names used);\n2. Residential Address at which he/she can be located;\n3. Date of birth; and\n4. An affirmation that all of the information contained in the Certificate Request is true and correct.\n\nii. A current signed government-issued identification document that includes a photo of the Individual and is signed by the Individual such as:\n\n1. A passport;\n2. A driver’s license;\n3. A personal identification card;\n4. A concealed weapons permit; or\n5. A military ID.\n\niii. At least two secondary documentary evidences to establish his/her identity that include the name of the Individual, one of which MUST be from a financial institution.\n\n1. Acceptable financial institution documents include:\na. A major credit card, provided that it contains an expiration date and it has not expired’\nb. A debit card from a regulated financial institution, provided that it contains an expiration date and it has not expired,\nc. A mortgage statement from a recognizable lender that is less than six months old,\nd. A bank statement from a regulated financial institution that is less than six months old.\n\n2. Acceptable non-financial documents include:\na. Recent original utility bills or certificates from a utility company confirming the arrangement to pay for the services at a fixed address (not a mobile/cellular telephone bill),\nb. A copy of a statement for payment of a lease, provided that the statement is dated within the past six months,\nc. A certified copy of a birth certificate,\nd. A local authority tax bill for the current year,\ne. A certified copy of a court order, such as a divorce certificate, annulment papers, or adoption papers.\n\nThe Third-Party Validator performing the face-to-face validation MUST:\n\ni. Attest to the signing of the Personal Statement and the identity of the signer; and\nii. Identify the original Vetting Documents used to perform the identification. In addition, the Third-Party Validator MUST attest on a copy of the current signed government-issued photo identification document that it is a full, true, and accurate reproduction of the original.\n\nB. Verification of Third-Party Validator: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicant’s jurisdiction), lawyer, or accountant in the jurisdiction of the Individual’s residency, and that the Third-Party Validator actually did perform the services and did attest to the signature of the Individual.\n\nC. Cross-checking of Information: The CA MUST obtain the signed and attested Personal Statement together with the attested copy of the current signed government-issued photo identification document. The CA MUST review the documentation to determine that the information is consistent, matches the information in the application, and identifies the Individual. The CA MAY rely on electronic copies of this documentation, provided that:\n\ni. the CA confirms their authenticity (not improperly modified when compared with the underlying original) with the Third-Party Validator; and\nii. electronic copies of similar kinds of documents are recognized as legal substitutes for originals under the laws of the CA’s jurisdiction.",true,"See Section 3.2.2.13 of CPS\n"]
["11.2.2 (5)","Acceptable Method of Verification","5. Non-Commercial Entity Subjects (International Organization): Unless verified under subsection (6), all items listed in Section 11.2.1 (4) MUST be verified either:\n\nA. With reference to the constituent document under which the International Organization was formed; or\nB. Directly with a signatory country’s government in which the CA is permitted to do business. Such verification may be obtained from an appropriate government agency or from the laws of that country, or by verifying that the country’s government has a mission to represent it at the International Organization; or\nC. Directly against any current list of qualified entities that the CA/Browser Forum may maintain at www.cabforum.org.\nD. In cases where the International Organization applying for the EV Certificate is an organ or agency - including a non-governmental organization of a verified International Organization, then the CA may verify the International Organization Applicant directly with the verified umbrella International Organization of which the Applicant is an organ or agency.\n","N/A","For applicants of EV certificates, Non-Commercial Entity Subjects (International Organizations) are not included for the time being.\n"]
["11.3.1","Verification Requirements","If, in addition to the Applicant’s formal legal name, as recorded with the applicable Incorporating Agency or Registration Agency in the Applicant’s Jurisdiction of Incorporation or Registration, the Applicant’s identity, as asserted in the EV Certificate, is to contain any assumed name (also known as “doing business as”, “DBA”, or “d/b/a” in the US, and “trading as” in the UK) under which the Applicant conducts business, the CA MUST verify that:\n\ni. the Applicant has registered its use of the assumed name with the appropriate government agency for such filings in the jurisdiction of its Place of Business (as verified in accordance with these Guidelines), and\nii. that such filing continues to be valid.\n",true,"See Section 3.2.2.2 of CPS\n"]
["11.4.1 ","Address of Applicant’s Place of Business","1. Verification Requirements: To verify the Applicant’s physical existence and business presence, the CA MUST verify that the physical address provided by the Applicant is an address where the Applicant or a Parent/Subsidiary Company conducts business operations (not, for example, a mail drop or P.O. box, or ‘care of’ (C/O) address, such as an address for an agent of the Organization), and is the address of the Applicant’s Place of Business.\n\n2. Acceptable Methods of Verification\n\nA. Place of Business in the Country of Incorporation or Registration\n\ni. For Applicants whose Place of Business is in the same country as the Applicant’s Jurisdiction of Incorporation or Registration and whose Place of Business is NOT the same as that indicated in the relevant Qualified Government Information Source used in Section 11.2 to verify legal existence:\n\n1. For Applicants listed at the same Place of Business address in the current version of either at least one QGIS (other than that used to verify legal existence), QIIS or QTIS, the CA MUST confirm that the Applicant’s address, as listed in the EV Certificate Request, is a valid business address for the Applicant or a Parent/Subsidiary Company by reference to such QGIS, QIIS, or QTIS, and MAY rely on the Applicant’s representation that such address is its Place of Business;\n2. For Applicants who are not listed at the same Place of Business address in the current version of either at least one QIIS or QTIS, the CA MUST confirm that the address provided by the Applicant in the EV Certificate Request is the Applicant’s or a Parent/Subsidiary Company’s business address, by obtaining documentation of a site visit to the business address, which MUST be performed by a reliable individual or firm. The documentation of the site visit MUST:\n\na. Verify that the Applicant’s business is located at the exact address stated in the EV Certificate Request (e.g., via permanent signage, employee confirmation, etc.),\nb. Identify the type of facility (e.g., office in a commercial building, private residence, storefront, etc.) and whether it appears to be a permanent business location,\nc. Indicate whether there is a permanent sign (that cannot be moved) that identifies the Applicant,\nd. Indicate whether there is evidence that the Applicant is conducting ongoing business activities at the site (not that it is just, for example, a mail drop, P.O. box, etc.), and\ne. Include one or more photos of\n\ni. the exterior of the site (showing signage indicating the Applicant’s name, if present, and showing the street address if possible), and\nii. the interior reception area or workspace.\n\nii. For all Applicants, the CA MAY alternatively rely on a Verified Professional Letter that indicates the address of the Applicant’s or a Parent/Subsidiary Company’s Place of Business and that business operations are conducted there.\niii. For Government Entity Applicants, the CA MAY rely on the address contained in the records of the QGIS in the Applicant’s jurisdiction.\niv. For Applicants whose Place of Business is in the same country as the Applicant’s Jurisdiction of Incorporation or Registration and where the QGIS used in Section 11.2 to verify legal existence contains a business address for the Applicant, the CA MAY rely on the address in the QGIS to confirm the Applicant’s or a Parent/Subsidiary Company’s address as listed in the EV Certificate Request, and MAY rely on the Applicant’s representation that such address is its Place of Business.\n\nB. Place of Business not in the Country of Incorporation or Registration: The CA MUST rely on a Verified Professional Letter that indicates the address of the Applicant’s Place of Business and that business operations are conducted there.",true,"See Section 3.2.2.13 of CPS\n"]
["11.5.1","Verification Requirements","To assist in communicating with the Applicant and confirming that the Applicant is aware of and approves issuance, the CA MUST verify a telephone number, fax number, email address, or postal delivery address as a Verified Method of Communication with the Applicant.",true,"See Section 3.2.2.13 of CPS\n"]
["11.5.2","Acceptable Methods of Verification","To verify a Verified Method of Communication with the Applicant, the CA MUST:\n\nA. Verify that the Verified Method of Communication belongs to the Applicant, or a Parent/Subsidiary or Affiliate of the Applicant, by matching it with one of the Applicant’s Parent/Subsidiary or Affiliate’s Places of Business in:\ni. records provided by the applicable phone company;\nii. a QGIS, QTIS, or QIIS; or\niii. a Verified Professional Letter; and\n\nB. Confirm the Verified Method of Communication by using it to obtain an affirmative response sufficient to enable a reasonable person to conclude that the Applicant, or a Parent/Subsidiary or Affiliate of Applicant, can be contacted reliably by using the Verified Method of Communication.\n",true,"See Section 3.2.2.13 of CPS"]
["11.6.1","Verification Requirements","The CA MUST verify that the Applicant has the ability to engage in business by verifying the Applicant’s, or Affiliate/Parent/Subsidiary Company’s, operational existence. The CA MAY rely on its verification of a Government Entity’s legal existence under Section 11.2 as verification of a Government Entity’s operational existence.\n",true,"See Section 3.2.2.13 of CPS\n"]
["11.6.2","Acceptable Methods of Verification","To verify the Applicant’s ability to engage in business, the CA MUST verify the operational existence of the Applicant, or its Affiliate/Parent/Subsidiary Company, by:\n\n1. Verifying that the Applicant, Affiliate, Parent Company, or Subsidiary Company has been in existence for at least three years, as indicated by the records of an Incorporating Agency or Registration Agency;\n2. Verifying that the Applicant, Affiliate, Parent Company, or Subsidiary Company is listed in either a current QIIS or QTIS;\n3. Verifying that the Applicant, Affiliate, Parent Company, or Subsidiary Company has an active current Demand Deposit Account with a Regulated Financial Institution by receiving authenticated documentation of the Applicant’s, Affiliate’s, Parent Company’s, or Subsidiary Company’s Demand Deposit Account directly from a Regulated Financial Institution; or\n4. Relying on a Verified Professional Letter to the effect that the Applicant has an active current Demand Deposit Account with a Regulated Financial Institution.\n",true,"See Section 3.2.2.13 of CPS\n"]
["11.7.1","Verification Requirements","1. For each Fully-Qualified Domain Name listed in a Certificate which is not an Onion Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant’s Parent Company, Subsidiary Company, or\nAffiliate, collectively referred to as “Applicant” for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 3.2.2.4 of the Baseline Requirements. For a Certificate issued to an Onion Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant’s control over the Onion Domain Name in accordance with Appendix B of the Baseline Requirements.\n2. Mixed Character Set Domain Names: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization.\n",true,"See Section 3.2.2.13 of CPS"]
["11.8.1","Verification Requirements","For both the Contract Signer and the Certificate Approver, the CA MUST verify the following.\n\n1. Name, Title and Agency: The CA MUST verify the name and title of the Contract Signer and the Certificate Approver, as applicable. The CA MUST also verify that the Contract Signer and the Certificate Approver are agents representing the Applicant.\n2. Signing Authority of Contract Signer: The CA MUST verify that the Contract Signer is authorized by the Applicant to enter into the Subscriber Agreement (and any other relevant contractual obligations) on behalf of the Applicant, including a contract that designates one or more Certificate Approvers on behalf of the Applicant.\n3. EV Authority of Certificate Approver: The CA MUST verify, through a source other than the Certificate Approver him- or herself, that the Certificate Approver is expressly authorized by the Applicant to do the following, as of the date of the EV Certificate Request:\n\nA. Submit, and, if applicable, authorize a Certificate Requester to submit, the EV Certificate Request on behalf of the Applicant; and\nB. Provide, and, if applicable, authorize a Certificate Requester to provide, the information requested from the Applicant by the CA for issuance of the EV Certificate; and\nC. Approve EV Certificate Requests submitted by a Certificate Requester.\n",true,"See Section 3.2.2.13 of CPS\n"]
["11.8.2","Acceptable Methods of Verification – Name, Title and Agency","Acceptable methods of verification of the name, title, and agency status of the Contract Signer and the Certificate Approver include the following.\n\n1. Name and Title: The CA MAY verify the name and title of the Contract Signer and the Certificate Approver by any appropriate method designed to provide reasonable assurance that a person claiming to act in such a role is in fact the named person designated to act in such role.\n2. Agency: The CA MAY verify the agency of the Contract Signer and the Certificate Approver by:\n\nA. Contacting the Applicant using a Verified Method of Communication for the Applicant, and obtaining confirmation that the Contract Signer and/or the Certificate Approver, as applicable, is an employee;\nB. Obtaining an Independent Confirmation From the Applicant (as described in Section 11.11.4), or a Verified Professional Letter verifying that the Contract Signer and/or the Certificate Approver, as applicable, is either an employee or has otherwise been appointed as an agent of the Applicant; or\nC. Obtaining confirmation from a QIIS or QGIS that the Contract Signer and/or Certificate Approver is an employee of the Applicant.\n\nThe CA MAY also verify the agency of the Certificate Approver via a certification from the Contract Signer (including in a contract between the CA and the Applicant signed by the Contract Signer), provided that the employment or agency status and Signing Authority of the Contract Signer has been verified.\n",true,"See Section 3.2.2.13 of CPS\n"]
["11.8.3. ","Acceptable Methods of Verification – Authority","Acceptable methods of verification of the Signing Authority of the Contract Signer, and the EV Authority of the Certificate Approver, as applicable, include:\n\n1. Verified Professional Letter: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by reliance on a Verified Professional Letter;\n2. Corporate Resolution: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by reliance on a properly authenticated corporate resolution that confirms that the person has been granted such Signing Authority, provided that such resolution is\n\ni. certified by the appropriate corporate officer (e.g., secretary), and\nii. the CA can reliably verify that the certification was validly signed by such person, and that such person does have the requisite authority to provide such certification;\n\n3. Independent Confirmation from Applicant: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by obtaining an Independent Confirmation from the Applicant (as described in Section 11.11.4);\n4. Contract between CA and Applicant: The EV Authority of the Certificate Approver MAY be verified by reliance on a contract between the CA and the Applicant that designates the Certificate Approver with such EV Authority, provided that the contract is signed by the Contract Signer and provided that the agency and Signing Authority of the Contract Signer have been verified; \n5. Prior Equivalent Authority: The signing authority of the Contract Signer, and/or the EV authority of the Certificate Approver, MAY be verified by relying on a demonstration of Prior Equivalent Authority.\n\nA. Prior Equivalent Authority of a Contract Signer MAY be relied upon for confirmation or verification of the signing authority of the Contract Signer when the Contract Signer has executed a binding contract between the CA and the Applicant with a legally valid and enforceable seal or handwritten signature and only when the contract was executed more than 90 days prior to the EV Certificate application. The CA MUST record sufficient details of the previous agreement to correctly identify it and associate it with the EV application. Such details MAY include any of the following:\n\ni. Agreement title,\nii. Date of Contract Signer’s signature,\niii. Contract reference number, and\niv. Filing location.\n\nB. Prior Equivalent Authority of a Certificate Approver MAY be relied upon for confirmation or verification of the EV Authority of the Certificate Approver when the Certificate Approver has performed one or more of the following:\n\ni. Under contract to the CA, has served (or is serving) as an Enterprise RA for the Applicant, or\nii. Has participated in the approval of one or more certificate requests, for certificates issued by the CA and which are currently and verifiably in use by the Applicant. In this case the CA MUST have contacted the Certificate Approver by phone at a previously validated phone number or have accepted a signed and notarized letter approving the certificate request.\n\n6. QIIS or QGIS: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by a QIIS or QGIS that identifies the Contract Signer and/or the Certificate Approver as a corporate officer, sole proprietor, or other senior official of the Applicant.\n7. Contract Signer’s Representation/Warranty: Provided that the CA verifies that the Contract Signer is an employee or agent of the Applicant, the CA MAY rely on the signing authority of the Contract Signer by obtaining a duly executed representation or warranty from the Contract Signer that includes the following acknowledgments:\n\nA. That the Applicant authorizes the Contract Signer to sign the Subscriber Agreement on the Applicant’s behalf,\nB. That the Subscriber Agreement is a legally valid and enforceable agreement,\nC. That, upon execution of the Subscriber Agreement, the Applicant will be bound by all of its terms and conditions,\nD. That serious consequences attach to the misuse of an EV certificate, and\nE. The contract signer has the authority to obtain the digital equivalent of a corporate seal, stamp or officer’s signature to establish the authenticity of the company’s Web site.",true,"See Section 3.2.2.13 of CPS\n"]
["11.8.4","Pre-Authorized Certificate Approver","Where the CA and Applicant contemplate the submission of multiple future EV Certificate Requests, then, after the CA:\n\n1. Has verified the name and title of the Contract Signer and that he/she is an employee or agent of the Applicant; and\n2. Has verified the Signing Authority of such Contract Signer in accordance with one of the procedures in Section 11.8.3. \n\nThe CA and the Applicant MAY enter into a written agreement, signed by the Contract Signer on behalf of the Applicant, whereby, for a specified term, the Applicant expressly authorizes one or more Certificate Approver(s) designated in such agreement to exercise EV Authority with respect to each future EV Certificate Request submitted on behalf of the Applicant and properly authenticated as originating with, or otherwise being approved by, such Certificate Approver(s). \n\nSuch an agreement MUST provide that the Applicant shall be obligated under the Subscriber Agreement for all EV Certificates issued at the request of, or approved by, such Certificate Approver(s) until such EV Authority is revoked, and MUST include\nmutually agreed-upon provisions for:\n\ni. authenticating the Certificate Approver when EV Certificate Requests are approved,\nii. periodic re-confirmation of the EV Authority of the Certificate Approver,\niii. secure procedures by which the Applicant can notify the CA that the EV Authority of any such Certificate Approver is revoked, and\niv. such other appropriate precautions as are reasonably necessary.\n","N/A","This certificate application mode is not currently supported.\n"]
[11.9,"Verification of Signature on Subscriber Agreement and\nEV Certificate Requests","Both the Subscriber Agreement and each non-pre-authorized EV Certificate Request MUST be signed. \n\nThe Subscriber Agreement MUST be signed by an authorized Contract Signer. \n\nThe EV Certificate Request MUST be signed by the Certificate Requester submitting the document, unless the Certificate Request has been pre-authorized in line with Section 11.8.4. \n\nIf the Certificate Requester is not also an authorized Certificate Approver, then an authorized Certificate Approver MUST independently approve the EV Certificate Request. \n\nIn all cases, applicable signatures MUST be a legally valid and contain an enforceable seal or handwritten signature (for a paper Subscriber Agreement and/or EV Certificate Request), or a legally valid and enforceable electronic signature (for an electronic Subscriber Agreement and/or EV Certificate Request), that binds the Applicant to the terms of each respective document.\n",true,"See Section 3.2.2.13 of CPS\n"]
["11.9.1","Verification Requirements","1. Signature: The CA MUST authenticate the signature of the Contract Signer on the Subscriber Agreement and the signature of the Certificate Requester on each EV Certificate Request in a manner that makes it reasonably certain that the person named as the signer in the applicable document is, in fact, the person who signed the document on behalf of the Applicant.\n\n2. Approval Alternative: In cases where an EV Certificate Request is signed and submitted by a Certificate Requester who does not also function as a Certificate Approver, approval and adoption of the EV Certificate Request by a Certificate Approver in accordance with the requirements of Section 11.10 can substitute for authentication of the signature of the Certificate Requester on such EV Certificate Request.\n",true,"See Section 3.2.2.13 of CPS\n"]
["11.9.2","Acceptable Methods of Signature Verification","Acceptable methods of authenticating the signature of the Certificate Requester or Contract Signer include the following:\n\n1. Contacting the Applicant using a Verified Method of Communication for the Applicant, for the attention of the Certificate Requester or Contract Signer, as applicable, followed by a response from someone who identifies themselves as such person confirming that he/she did sign the applicable document on behalf of the Applicant;\n2. A letter mailed to the Applicant’s or Agent’s address, as verified through independent means in accordance with these Guidelines, for the attention of the Certificate Requester or Contract Signer, as applicable, followed by a response through a Verified Method of Communication from someone who identifies themselves as such person confirming that he/she did sign the applicable document on behalf of the Applicant;\n3. Use of a signature process that establishes the name and title of the signer in a secure manner, such as through use of an appropriately secure login process that identifies the signer before signing, or through use of a digital signature made with reference to an appropriately verified certificate; or\n4. Notarization by a notary, provided that the CA independently verifies that such notary is a legally qualified notary in the jurisdiction of the Certificate Requester or Contract Signer.\n",true,"See Section 3.2.2.13 of CPS\n"]
["11.10.1","Verification Requirements","In cases where an EV Certificate Request is submitted by a Certificate Requester, before the CA issues the requested EV Certificate, the CA MUST verify that an authorized Certificate Approver reviewed and approved the EV Certificate Request.\n",true,"See Section 3.2.2.13 of CPS\n"]
["11.10.2","Acceptable Methods of Verification","Acceptable methods of verifying the Certificate Approver’s approval of an EV Certificate Request include:\n\n1. Contacting the Certificate Approver using a Verified Method of Communication for the Applicant and obtaining oral or written confirmation that the Certificate Approver has reviewed and approved the EV Certificate Request;\n2. Notifying the Certificate Approver that one or more new EV Certificate Requests are available for review and approval at a designated access-controlled and secure Web site, followed by a login by, and an indication of approval from, the Certificate Approver in the manner required by the Web site; or\n3. Verifying the signature of the Certificate Approver on the EV Certificate Request in accordance with Section 11.9.\n",true,"See Section 3.2.2.13 of CPS\n"]
["11.11.1","Verified Legal Opinion","1. Verification Requirements: Before relying on a legal opinion submitted to the CA, the CA MUST verify that such legal opinion meets the following requirements:\nA. Status of Author: The CA MUST verify that the legal opinion is authored by an independent legal practitioner retained by and representing the Applicant (or an in-house legal practitioner employed by the Applicant) (Legal Practitioner) who is either:\ni. A lawyer (or solicitor, barrister, advocate, or equivalent) licensed to practice law in the country of the Applicant’s Jurisdiction of Incorporation or Registration or any jurisdiction where the Applicant maintains an office or physical facility, or\nii. A Latin Notary who is currently commissioned or licensed to practice in the country of the Applicant’s Jurisdiction of Incorporation or Registration or any jurisdiction where the Applicant maintains an office or physical facility (and that such jurisdiction recognizes the role of the Latin Notary);\nB. Basis of Opinion: The CA MUST verify that the Legal Practitioner is acting on behalf of the Applicant and that the conclusions of the Verified Legal Opinion are based on the Legal Practitioner’s stated familiarity with the relevant facts and the exercise of the Legal Practitioner’s professional judgment and expertise;\nC. Authenticity: The CA MUST confirm the authenticity of the Verified Legal Opinion.\n\n2. Acceptable Methods of Verification: Acceptable methods of establishing the foregoing requirements for a Verified Legal Opinion are:\nA. Status of Author: The CA MUST verify the professional status of the author of the legal opinion by directly contacting the authority responsible for registering or licensing such Legal Practitioner(s) in the applicable jurisdiction;\nB. Basis of Opinion: The text of the legal opinion MUST make it clear that the Legal Practitioner is acting on behalf of the Applicant and that the conclusions of the legal opinion are based on the Legal Practitioner’s stated familiarity with the relevant facts and the exercise of the practitioner’s professional judgment and expertise. The legal opinion MAY also include disclaimers and other limitations customary in the Legal Practitioner’s jurisdiction, provided that the scope of the disclaimed responsibility is not so great as to eliminate any substantial risk (financial, professional, and/or reputational) to the Legal Practitioner, should the legal opinion prove to be erroneous. An acceptable form of legal opinion is attached as Appendix B;\nC. Authenticity: To confirm the authenticity of the legal opinion, the CA MUST make a telephone call or send a copy of the legal opinion back to the Legal Practitioner at the address, phone number, facsimile, or (if available) e-mail address for the Legal Practitioner listed with the authority responsible for registering or licensing such Legal Practitioner, and obtain confirmation from the Legal Practitioner or the Legal Practitioner’s assistant that the legal opinion is authentic. If a phone number is not available from the licensing authority, the CA MAY use the number listed for the Legal Practitioner in records provided by the applicable phone company, QGIS, or QIIS. In circumstances where the opinion is digitally signed, in a manner that confirms the authenticity of the document and the identity of the signer, as verified by the CA in Section 11.11.1 (2)(A), no further verification of authenticity is required.","N/A","This verification method is not currently supported.\n"]
["11.11.2","Verified Accountant Letter","1. Verification Requirements: Before relying on an accountant letter submitted to the CA, the CA MUST verify that such accountant letter meets the following\nrequirements: \n\nA. Status of Author: The CA MUST verify that the accountant letter is authored by an Accounting Practitioner retained or employed by the Applicant and licensed within the country of the Applicant’s Jurisdiction of Incorporation, Jurisdiction of Registration, or country where the Applicant maintains an office or physical facility. Verification of license MUST be through the member organization or regulatory organization in the Accounting Practitioner’s country or jurisdiction that is appropriate to contact when verifying an accountant’s license to practice in that country or jurisdiction. Such country or jurisdiction must have an accounting standards body that maintains full membership status with the International Federation of Accountants.\nB. Basis of Opinion: The CA MUST verify that the Accounting Practitioner is acting on behalf of the Applicant and that the conclusions of the Verified Accountant Letter are based on the Accounting Practitioner’s stated familiarity with the relevant facts and the exercise of the Accounting Practitioner’s professional judgment and expertise;\nC. Authenticity: The CA MUST confirm the authenticity of the Verified Accountant Letter.\n\n2. Acceptable Methods of Verification: Acceptable methods of establishing the foregoing requirements for a Verified Accountant Letter are listed here.\nA. Status of Author: The CA MUST verify the professional status of the author of the accountant letter by directly contacting the authority responsible for registering or licensing such Accounting Practitioners in the applicable jurisdiction.\nB. Basis of Opinion: The text of the Verified Accountant Letter MUST make clear that the Accounting Practitioner is acting on behalf of the Applicant and that the information in the letter is based on the Accounting Practitioner’s stated familiarity with the relevant facts and the exercise of the practitioner’s professional judgment and expertise. The Verified Accountant Letter MAY also include disclaimers and other limitations customary in the Accounting Practitioner’s jurisdiction, provided that the scope of the disclaimed responsibility is not so great as to eliminate any substantial risk (financial, professional, and/or reputational) to the Accounting Practitioner, should the Verified Accountant Letter prove to be erroneous. Acceptable forms of Verified Accountant Letter are attached as Appendix C.\nC. Authenticity: To confirm the authenticity of the accountant’s opinion, the CA MUST make a telephone call or send a copy of the Verified Accountant Letter back to the Accounting Practitioner at the address, phone number, facsimile, or (if available) e-mail address for the Accounting Practitioner listed with the authority responsible for registering or licensing such Accounting Practitioners and obtain confirmation from the Accounting Practitioner or the Accounting Practitioner’s assistant that the accountant letter is authentic. If a phone number is not available from the licensing authority, the CA MAY use the number listed for the Accountant in records provided by the applicable phone company, QGIS, or QIIS.\n\nIn circumstances where the opinion is digitally signed, in a manner that confirms the authenticity of the document and the identity of the signer, as verified by the CA in Section 11.11.2 (2)(A), no further verification of authenticity is required.","N/A","This verification method is not currently supported.\n"]
["11.11.3","Face-to-Face Validation","- 1. Verification Requirements: Before relying on face-to-face vetting documents submitted to the CA, the CA MUST verify that the Third-Party Validator meets the following requirements:\n\nA. Qualification of Third-Party Validator: The CA MUST independently verify that the Third-Party Validator is a legally-qualified Latin Notary or Notary (or legal equivalent in the Applicant’s jurisdiction), Lawyer, or Accountant in the jurisdiction of the individual’s residency;\nB. Document Chain of Custody: The CA MUST verify that the Third-Party Validator viewed the Vetting Documents in a face-to-face meeting with the individual being validated;\nC. Verification of Attestation: If the Third-Party Validator is not a Latin Notary, then the CA MUST confirm the authenticity of the attestation and vetting documents.\n\n- 2. Acceptable Methods of Verification: Acceptable methods of establishing the foregoing requirements for vetting documents are:\n\nA. Qualification of Third-Party Validator: The CA MUST verify the professional status of the Third-Party Validator by directly contacting the authority responsible for registering or licensing such Third-Party Validators in the applicable jurisdiction;\nB. Document Chain of Custody: The Third-Party Validator MUST submit a statement to the CA which attests that they obtained the Vetting Documents submitted to the CA for the individual during a face-to-face meeting with the individual;\nC. Verification of Attestation: If the Third-Party Validator is not a Latin Notary, then the CA MUST confirm the authenticity of the vetting documents received from the Third-Party Validator. The CA MUST make a telephone call to the Third-Party Validator and obtain confirmation from them or their assistant that they performed the face-to-face validation. The CA MAY rely upon self-reported information obtained from the Third-Party Validator for the sole purpose of performing this verification process. In circumstances where the attestation is digitally signed, in a manner that confirms the authenticity of the documents, and the identity of the signer as verified by the CA in Section 11.11.3 (1)(A), no further verification of authenticity is required.\n",true]
["11.11.4","Independent Confirmation From Applicant","An Independent Confirmation from the Applicant is a confirmation of a particular fact (e.g., confirmation of the employee or agency status of a Contract Signer or Certificate Approver, confirmation of the EV Authority of a Certificate Approver, etc.) that is:\n\nA. Received by the CA from a Confirming Person (someone other than the person who is the subject of the inquiry) that has the appropriate authority to confirm such a fact, and who represents that he/she has confirmed such fact;\n\nB. Received by the CA in a manner that authenticates and verifies the source of the confirmation; and\n\nC. Binding on the Applicant.\n\nAn Independent Confirmation from the Applicant MAY be obtained via the following procedure:\n\n- 1. Confirmation Request: The CA MUST initiate a Confirmation Request via an appropriate out-of-band communication, requesting verification or confirmation of the particular fact at issue as follows:\n\nA. Addressee: The Confirmation Request MUST be directed to: \ni. A position within the Applicant’s organization that qualifies as a Confirming Person (e.g., Secretary, President, CEO, CFO, COO, CIO, CSO, Director, etc.) and is identified by name and title in a current QGIS, QIIS, QTIS, Verified Legal Opinion, Verified Accountant Letter, or by contacting the Applicant using a Verified Method of Communication; or\nii. The Applicant’s Registered Agent or Registered Office in the Jurisdiction of Incorporation as listed in the official records of the Incorporating Agency, with instructions that it be forwarded to an appropriate Confirming Person; or\niii. A named individual verified to be in the direct line of management above the Contract Signer or Certificate Approver by contacting the Applicant’s Human Resources Department by phone or mail (at the phone number or address for the Applicant’s Place of Business, verified in accordance with these Guidelines).\n\nB. Means of Communication: The Confirmation Request MUST be directed to the Confirming Person in a manner reasonably likely to reach such person. The following options are acceptable:\n\ni. By paper mail addressed to the Confirming Person at:\n1. The address of the Applicant’s Place of Business as verified by the CA in accordance with these Guidelines, or\n2. The business address for such Confirming Person specified in a current QGIS, QTIS, QIIS, Verified Professional Letter, or\n3. The address of the Applicant’s Registered Agent or Registered Office listed in the official records of the Jurisdiction of Incorporation, or\n\nii. By e-mail addressed to the Confirming Person at the business e-mail address for such person listed in a current QGIS, QTIS, QIIS, Verified Legal Opinion, or Verified Accountant Letter; or\n\niii. By telephone call to the Confirming Person, where such person is contacted by calling the main phone number of the Applicant’s Place of Business (verified in accordance with these Guidelines) and asking to speak to such person, and a person taking the call identifies him- or herself as such person; or \n\niv. By facsimile to the Confirming Person at the Place of Business. The facsimile number must be listed in a current QGIS, QTIS, QIIS, Verified Legal Opinion, or Verified Accountant Letter. The cover page must be clearly addressed to the Confirming Person.\n\n- 2. Confirmation Response: The CA MUST receive a response to the Confirmation Request from a Confirming Person that confirms the particular fact at issue. Such response MAY be provided to the CA by telephone, by e-mail, or by paper mail, so long as the CA can reliably verify that it was provided by a Confirming Person in response to the Confirmation Request.\n\n3. The CA MAY rely on a verified Confirming Person to confirm their own contact information: email address, telephone number, and facsimile number. The CA MAY rely on this verified contact information for future correspondence with the Confirming Person if:\nA. The domain of the e-mail address is owned by the Applicant and is the Confirming Person’s own e-mail address and not a group e-mail alias; \nB. The Confirming Person’s telephone/fax number is verified by the CA to be a telephone number that is part of the organization’s telephone system, and is not the personal phone number for the person.\n\n\n",true]
["11.11.5","Qualified Independent Information Source","A Qualified Independent Information Source (QIIS) is a regularly-updated and publicly available database that is generally recognized as a dependable source for certain information. A database qualifies as a QIIS if the CA determines that: \n\n1. Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and\n\n2. The database provider updates its data on at least an annual basis. The CA SHALL use a documented process to check the accuracy of the database and ensure its data is acceptable, including reviewing the database provider’s terms of use. The CA SHALL NOT use any data in a QIIS that the CA knows is\ni. self-reported and\nii. not verified by the QIIS as accurate.\n\nDatabases in which the CA or its owners or affiliated companies maintain a controlling interest, or in which any Registration Authorities or subcontractors to whom the CA has outsourced any portion of the vetting process (or their owners or affiliated companies) maintain any ownership or beneficial interest, do not qualify as a QIIS.\n",true]
["11.11.6. ","Qualified Government Information Source","A Qualified Government Information Source (QGIS) is a regularly-updated and current, publicly available, database designed for the purpose of accurately providing the information for which it is consulted, and which is generally recognized as a dependable source of such information provided that it is maintained by a Government Entity, the reporting of data is required by law, and false or misleading reporting is punishable with criminal or civil penalties. Nothing in these Guidelines shall prohibit the use of third-party vendors to obtain the information from the Government Entity provided that the third party obtains the information directly from the Government Entity.\n",false]
["11.11.7. ","Qualified Government Tax Information Source","A Qualified Government Tax Information Source is a Qualified Government Information Source that specifically contains tax information relating to Private Organizations, Business Entities or Individuals (e.g., the IRS in the United States).\n",false]
["11.12.1. ","High Risk Status","The High Risk Certificate requirements of Section 4.2.1 of the Baseline Requirements apply equally to EV Certificates.\n",false]
["11.12.2","Denied Lists and Other Legal Block Lists","1. Verification Requirements: The CA MUST verify whether the Applicant, the Contract Signer, the Certificate Approver, the Applicant’s Jurisdiction of Incorporation, Registration, or Place of Business:\n\nA. Is identified on any government denied list, list of prohibited persons, or other list that prohibits doing business with such organization or person under the laws of the country of the CA’s jurisdiction(s) of operation; or\n\nB. Has its Jurisdiction of Incorporation, Registration, or Place of Business in any country with which the laws of the CA’s jurisdiction prohibit doing business. The CA MUST NOT issue any EV Certificate to the Applicant if either the Applicant, the Contract Signer, or Certificate Approver or if the Applicant’s Jurisdiction of Incorporation or Registration or Place of Business is on any such list.\n\n2. Acceptable Methods of Verification The CA MUST take reasonable steps to verify with the following lists and regulations:\n\nA. If the CA has operations in the U.S., the CA MUST take reasonable steps to verify with the following US Government denied lists and regulations:\ni. BIS Denied Persons List - https://www.bis.doc.gov/index.php/the-denied-persons-list\nii. BIS Denied Entities List - https://www.bis.doc.gov/index.php/policy-guidance/lists-of-parties-of-concern/entity-list\niii. US Treasury Department List of Specially Designated Nationals and Blocked Persons - https://www.treasury.gov/resource‐center/sanctions/sdn‐list/pages/default.aspx\niv. US Government export regulations\n\nB. If the CA has operations in any other country, the CA MUST take reasonable steps to verify with all equivalent denied lists and export regulations (if any) in such other country.\n",true,"See Section 3.2.2.13 of CPS\n"]
["11.12.3","Parent/Subsidiary/Affiliate Relationship","A CA verifying an Applicant using information of the Applicant’s Parent, Subsidiary, or Affiliate, when allowed under Section 11.4.1, Section 11.5, Section 11.6.1, or Section 11.7.1, MUST verify the Applicant’s relationship to the Parent, Subsidiary, or Affiliate. Acceptable methods of verifying the Applicant’s relationship to the Parent, Subsidiary, or Affiliate include the following:\n\n1. QIIS or QGIS: The relationship between the Applicant and the Parent, Subsidiary, or Affiliate is identified in a QIIS or QGIS;\n\n2. Independent Confirmation from the Parent, Subsidiary, or Affiliate: A CA MAY verify the relationship between an Applicant and a Parent, Subsidiary, or Affiliate by obtaining an Independent Confirmation from the appropriate Parent, Subsidiary, or Affiliate (as described in Section 11.11.4);\n\n3. Contract between CA and Parent, Subsidiary, or Affiliate: A CA MAY verify the relationship between an Applicant and a Parent, Subsidiary, or Affiliate by relying on a contract between the CA and the Parent, Subsidiary, or Affiliate that designates the Certificate Approver with such EV Authority, provided that the contract is signed by the Contract Signer and provided that the agency and Signing Authority of the Contract Signer have been verified;\n\n4. Verified Professional Letter: A CA MAY verify the relationship between an Applicant and a Parent, Subsidiary, or Affiliate by relying on a Verified Professional Letter; or\n\n5. Corporate Resolution: A CA MAY verify the relationship between an Applicant and a Subsidiary by relying on a properly authenticated corporate resolution that approves creation of the Subsidiary or the Applicant, provided that such resolution is:\ni. certified by the appropriate corporate officer (e.g., secretary), and \nii. the CA can reliably verify that the certification was validly signed by such person, and that such person does have the requisite authority to provide such certification.\n",true]
[11.13,"Final Cross-Correlation and Due Diligence","1. The results of the verification processes and procedures outlined in these Guidelines are intended to be viewed both individually and as a group. Thus, after all of the verification processes and procedures are completed, the CA MUST have a person who is not responsible for the collection of information review all of the information and documentation assembled in support of the EV Certificate application and look for discrepancies or other details requiring further explanation.\n\n2. The CA MUST obtain and document further explanation or clarification from the Applicant, Certificate Approver, Certificate Requester, Qualified Independent Information Sources, and/or other sources of information, as necessary, to resolve those discrepancies or details that require further explanation.\n\n3. The CA MUST refrain from issuing an EV Certificate until the entire corpus of information and documentation assembled in support of the EV Certificate Request is such that issuance of the EV Certificate will not communicate factual information that the CA knows, or the exercise of due diligence should discover from the assembled information and documentation, to be inaccurate,. If satisfactory explanation and/or additional documentation are not received within a reasonable time, the CA MUST decline the EV Certificate Request and SHOULD notify the Applicant accordingly.\n\n4. In the case where some or all of the documentation used to support the application is in a language other than the CA’s normal operating language, the CA or its Affiliate MUST perform the requirements of this Final Cross-Correlation and Due Diligence section using employees under its control and having appropriate training, experience, and judgment in confirming organizational identification and authorization and fulfilling all qualification requirements contained in Section 14.1. When employees under the control of the CA do not possess the language skills necessary to perform the Final Cross-Correlation and Due Diligence a CA MAY:\n\nA. Rely on language translations of the relevant portions of the documentation, provided that the translations are received from a Translator; or\n\nB. When the CA has utilized the services of an RA, the CA MAY rely on the language skills of the RA to perform the Final Cross-Correlation and Due Diligence, provided that the RA complies with Section 11.13, Subsections (1), (2) and (3). Notwithstanding the foregoing, prior to issuing the EV Certificate, the CA MUST review the work completed by the RA and determine that all requirements have been met; or\n\nC. When the CA has utilized the services of an RA, the CA MAY rely on the RA to perform the Final Cross-Correlation and Due Diligence, provided that the RA complies with this section and is subjected to the Audit Requirements of Section 17.5 and Section 17.6. \n\nIn the case of EV Certificates to be issued in compliance with the requirements of Section 14.2, the Enterprise RA MAY perform the requirements of this Final Cross-Correlation and Due Diligence section.\n",true]
[11.14,"Requirements for Re-use of Existing Documentation","For each EV Certificate Request, including requests to renew existing EV Certificates, the CA MUST perform all authentication and verification tasks required by these Guidelines to ensure that the request is properly authorized by the Applicant and that the information in the EV Certificate is still accurate and valid. This section sets forth the age limitations on for the use of documentation collected by the CA.\n",true,"See Section 4.2.1 of CPS\n"]
["11.14.1","Validation For Existing Subscribers","If an Applicant has a currently valid EV Certificate issued by the CA, a CA MAY rely on its prior authentication and verification of:\n\n1. The Principal Individual verified under Section 11.2.2 (4) if the individual is the same person as verified by the CA in connection with the Applicant’s previously\nissued and currently valid EV Certificate;\n\n2. The Applicant’s Place of Business under Section 11.4.1;\n\n3. The Applicant’s Verified Method of Communication required by Section 11.5 but still MUST perform the verification required by Section 11.5.2 (B);\n\n4. The Applicant’s Operational Existence under Section 11.6;\n\n5. The Name, Title, Agency and Authority of the Contract Signer, and Certificate Approver, under Section 11.8; and\n\n6. The Applicant’s right to use the specified Domain Name under Section 11.7, provided that the CA verifies that the WHOIS record still shows the same registrant as when the CA verified the specified Domain Name for the initial EV Certificate.\n",true]
["11.14.2","Re-issuance Requests","A CA may rely on a previously verified certificate request to issue a replacement certificate, so long as the certificate being referenced was not revoked due to fraud or other illegal conduct, if:\n\n1. The expiration date of the replacement certificate is the same as the expiration date of the EV Certificate that is being replaced, and\n\n2. The Subject Information of the Certificate is the same as the Subject in the EV Certificate that is being replaced.\n",true]
["11.14.3","Age of Validated Data","1. Except for reissuance of an EV Certificate under Section 11.14.2 and except when permitted otherwise in Section 11.14.1, the age of all data used to support issuance of an EV Certificate (before revalidation is required) SHALL NOT exceed the following limits:\n\nA. Legal existence and identity – 398 days;\nB. Assumed name – 398 days;\nC. Address of Place of Business – 398 days;\nD. Verified Method of Communication – 398 days;\nE. Operational existence – 398 days;\nF. Domain Name – 398 days;\nG. Name, Title, Agency, and Authority – 398 days, unless a contract between the CA and the Applicant specifies a different term, in which case, the term specified in such contract controls. For example, the contract MAY include the perpetual assignment of EV roles until revoked by the Applicant or CA, or until the contract expires or is terminated.\n\n2. The 398-day period set forth above SHALL begin to run on the date the information was collected by the CA.\n\n3. The CA MAY reuse a previously submitted EV Certificate Request, Subscriber Agreement, or Terms of Use, including use of a single EV Certificate Request in support of multiple EV Certificates containing the same Subject to the extent permitted under Section 11.9 and Section 11.10.\n\n4. The CA MUST repeat the verification process required in these Guidelines for any information obtained outside the time limits specified above except when permitted otherwise under Section 11.14.1.\n",true]
["12. Certificate Issuance by a Root CA"]
[12,"Certificate Issuance by a Root CA","Certificate issuance by the Root CA SHALL require an individual authorized by the CA (i.e. the CA system operator, system officer, or PKI administrator) to deliberately issue a direct command in order for the Root CA to perform a certificate signing operation.\n",true,"See Section 4.3.1 of CPS\n"]
[12,"Certificate Issuance by a Root CA","Root CA Private Keys MUST NOT be used to sign EV Certificates.\n",true,"See Section 6.1.7 of CPS\n"]
["13. Certificate Revocation and Status Checking"]
[13,"Certificate Revocation and Status Checking","The requirements in Section 4.9 of the Baseline Requirements apply equally to EV Certificates.",true,"See Section 4.9 of CPS\n"]
["14. Employee and third party issues"]
["14.1.1","Identity and Background Verification","Prior to the commencement of employment of any person by the CA for engagement in the EV Processes, whether as an employee, agent, or an independent contractor of the CA, the CA MUST:\n\n1. Verify the Identity of Such Person: Verification of identity MUST be performed through:\nA. The personal (physical) presence of such person before trusted persons who perform human resource or security functions, and\nB. The verification of well-recognized forms of government-issued photo identification (e.g., passports and/or drivers licenses); and\n\n2. Verify the Trustworthiness of Such Person: Verification of trustworthiness SHALL include background checks, which address at least the following, or their equivalent:\nA. Confirmation of previous employment,\nB. Check of professional references;\nC. Confirmation of the highest or most-relevant educational qualification obtained;\nD. Search of criminal records (local, state or provincial, and national) where allowed by the jurisdiction in which the person will be employed; and\n\n3. In the case of employees already in the employ of the CA at the time of adoption of these Guidelines whose identity and background has not previously been verified as set forth above, the CA SHALL conduct such verification within three months of the date of adoption of these Guidelines.\n",true,"See Section 5.3.1 and 5.3.2 of CPS\n"]
["14.1.2","Training and Skills Level","The requirements in Section 5.3.3 of the Baseline Requirements apply equally to EV Certificates and these Guidelines. The required internal examination must relate to the EV Certificate validation criteria outlined in these Guidelines.\n",true,"See Section 5.3.3 of CPS\n"]
["14.1.3","Separation of Duties","1. The CA MUST enforce rigorous control procedures for the separation of validation duties to ensure that no one person can single-handedly validate and authorize the\nissuance of an EV Certificate. The Final Cross-Correlation and Due Diligence steps, as outlined in Section 11.13, MAY be performed by one of the persons. For example, \none Validation Specialist MAY review and verify all the Applicant information and a second Validation Specialist MAY approve issuance of the EV Certificate.\n\n2. Such controls MUST be auditable.\n",true,"See Section 4.1.2 of CPS\n"]
["14.2.1","General","The CA MAY delegate the performance of all or any part of a requirement of these Guidelines to an Affiliate or a Registration Authority (RA) or subcontractor, provided that the process employed by the CA fulfills all of the requirements of Section 11.13. Affiliates and/or RAs must comply with the qualification requirements of Section 14.1. \n\nThe CA SHALL verify that the Delegated Third Party’s personnel involved in the issuance of a Certificate meet the training and skills requirements of Section 14 and the document retention and event logging requirements of Section 15.\n","N/A","Besides acting as a CA, BJCA will also act as a RA and no third party will be entrusted as the RA."]
["14.2.2","Enterprise RAs","The CA MAY contractually authorize a Subscriber to perform the RA function and authorize the CA to issue additional EV Certificates. In such case, the Subscriber SHALL be considered an Enterprise RA, and the following requirements SHALL apply:\n\n1. In all cases, the Subscriber MUST be an organization verified by the CA in accordance with these Guidelines;\n\n2. The CA MUST impose these limitations as a contractual requirement with the Enterprise RA and monitor compliance by the Enterprise RA; and\n\n3. The Final Cross-Correlation and Due Diligence requirements of Section 11.13 MAY be performed by a single person representing the Enterprise RA.\n\nEnterprise RAs that authorize the issuance of EV Certificates solely for its own organization are exempted from the audit requirements of Section 17.1. In all other cases, the requirements of Section 17.1 SHALL apply.\n","N/A","Besides acting as a CA, BJCA will also act as a RA and no third party will be entrusted as the RA."]
["14.2.3","Guidelines Compliance Obligation","In all cases, the CA MUST contractually obligate each Affiliate, RA, subcontractor, and Enterprise RA to comply with all applicable requirements in these Guidelines and to perform them as required of the CA itself. \n\nThe CA SHALL enforce these obligations and internally audit each Affiliate’s, RA’s, subcontractor’s, and Enterprise RA’s compliance with these Requirements on an annual basis.\n","N/A","Besides acting as a CA, BJCA will also act as a RA and no third party will be entrusted as the RA."]
["14.2.4","Allocation of Liability","As specified in Section 9.8 of the Baseline Requirements.\n"]
["15. Data Records"]
[15,"Data Records","As specified in Section 5.4 of the Baseline Requirements.\n"]
["16. Data Security"]
[16,"Data Security","As specified in Section 5 of the Baseline Requirements. In addition, systems used to process and approve EV Certificate Requests MUST require actions by at least two trusted persons before creating an EV Certificate.\n",true,"See Section 4.1.2 of CPS\n"]
["17. Audit"]
[17.1,"Eligible Audit Schemes","A CA issuing EV Certificates SHALL undergo an audit in accordance with one of the following schemes:\n\ni. WebTrust Program for CAs audit and WebTrust EV Program audit,\nii. ETSI TS 102 042 audit for EVCP, or\niii. ETSI EN 319 411-1 audit for EVCP policy. \n\nIf the CA is a Government Entity, an audit of the CA by the appropriate internal government auditing agency is acceptable in lieu of the audits specified above, provided that such internal government auditing agency publicly certifies in writing that its audit addresses the criteria specified in one of the above audit schemes and certifies that the government CA has successfully passed the audit.\n\nEV audits MUST cover all CA obligations under these Guidelines regardless of whether they are performed directly by the CA or delegated to an RA or subcontractor.\n",true,"BJCA is audited in accordance with the WebTrust Program for CAs audit and WebTrust EV Program audit."]
[17.2,"Audit Period","A CA issuing EV Certificates SHALL undergo an audit in accordance with one of the following schemes:\n\ni. WebTrust Program for CAs audit and WebTrust EV Program audit,\nii. ETSI TS 102 042 audit for EVCP, or\niii. ETSI EN 319 411-1 audit for EVCP policy. \n\nIf the CA is a Government Entity, an audit of the CA by the appropriate internal government auditing agency is acceptable in lieu of the audits specified above, provided that such internal government auditing agency publicly certifies in writing that its audit addresses the criteria specified in one of the above audit schemes and certifies that the government CA has successfully passed the audit.\n\nEV audits MUST cover all CA obligations under these Guidelines regardless of whether they are performed directly by the CA or delegated to an RA or subcontractor.\n",true,"BJCA is audited in accordance with the WebTrust Program for CAs audit and WebTrust EV Program audit.\n"]
[17.3,"Audit Record","CAs SHOULD make its audit report publicly available no later than three months after the end of the audit period. If there is a delay greater than three months and if so requested by an Application Software Supplier, the CA MUST provide an explanatory letter signed by its auditor\n",true,"So far the audit periods are continuous and have no gaps. Our audit report is made public within three months of the audit period."]
[17.4,"Pre-Issuance Readiness Audit","1. If the CA has a currently valid WebTrust Seal of Assurance for CAs, then, before issuing EV Certificates, the CA and its Root CA MUST successfully complete a point-in-time readiness assessment audit against the WebTrust EV Program.\n\n2. If the CA has a currently valid ETSI 102 042 audit, then, before issuing EV Certificates, the CA and its Root CA MUST successfully complete a point-in-time readiness assessment audit against ETSI TS 102 042.\n\n3. If the CA has a currently valid ETSI EN 319 411-1 audit for EVCP policy, then, before issuing EV Certificates, the CA and its Root CA MUST successfully complete a point-in-time readiness assessment audit against ETSI EN 319 411-1 for EVCP.\n\n4. If the CA does not have a currently valid WebTrust Seal of Assurance for CAs or an ETSI TS 102 042 EVCP audit or an ETSI EN 319 411-1 audit for EVCP policy, then, before issuing EV Certificates, the CA and its Root CA MUST successfully complete either:\ni. a point-in-time readiness assessment audit against the WebTrust for CA Program, or\nii. a point-in-time readiness assessment audit against the WebTrust EV Program, the ETSI TS 102 042 EVCP, or the ETSI EN 319 411-1 for EVCP policy.\n\nThe CA MUST complete any required point-in-time readiness assessment no earlier than twelve (12) months prior to issuing an EV Certificate. The CA MUST undergo a complete audit under such scheme within ninety (90) days of issuing the first EV Certificate.\n",true,"BJCA has a currently valid WebTrust Seal of Assurance for CAs and complies with BR regulations."]
[17.5,"Regular Self Audits","During the period in which it issues EV Certificates, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least three percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken. \n\nFor all EV Certificates where the Final Cross-Correlation and Due Diligence requirements of Section 11.13 is performed by an RA, the CA MUST strictly control its service quality by performing ongoing self audits against a randomly selected sample of at least six percent of the EV Certificates it has issued in the period beginning immediately after the last sample was taken.\n",true,"See Section 8.7 of CPS\n"]
[17.6,"Auditor Qualification","A Qualified Auditor (as defined in Section 8.2 of the Baseline Requirements) MUST perform the CA’s audit.\n",true,"See Section 8.2 of CPS\n"]
[17.7,"Root CA Key Pair Generation","All requirements in Section 6.1.1.1 of the Baseline Requirements apply equally to EV Certificates. However, for Root CA Key Pairs generated after the release of these Guidelines, the Root CA Key Pair generation ceremony MUST be witnessed by the CA’s Qualified Auditor in order to observe the process and the controls over the integrity and confidentiality of the Root CA Key Pairs produced. \n\nThe Qualified Auditor MUST then issue a report opining that the CA, during its Root CA Key Pair and Certificate generation process:\n\n1. Documented its Root CA key generation and protection procedures in its Certificate Policy, and its Certification Practices Statement;\n\n2. Included appropriate detail in its Root Key Generation Script;\n\n3. Maintained effective controls to provide reasonable assurance that the Root CA key pair was generated and protected in conformity with the procedures described in its CP/CPS and with its Root Key Generation Script;\n\n4. Performed, during the Root CA key generation process, all the procedures required by its Root Key Generation Script.\n",true,"See Section 6.1.1.1 of CPS\n"]
["18. Audit Liability and Indemnification"]
[18,"Audit Liability and Indemnification","CAs MAY limit their liability as described in Section 9.8 of the Baseline Requirements except that a CA MUST NOT limit its liability to Subscribers or Relying Parties for legally recognized and provable claims to a monetary amount less than two thousand US dollars per Subscriber or Relying Party per EV Certificate.\n\nA CA’s indemnification obligations and a Root CA’s obligations with respect to subordinate CAs are set forth in Section 9.9 of the Baseline Requirements.\n",true,"See Section 9.8 of CPS\n"]
["Appendix A - User Agent Verification (Normative)"]
["Appendix A","User Agent Verification (Normative)","The CA MUST host test Web pages that allow Application Software Suppliers to test their software with EV Certificates that chain up to each EV Root Certificate. \n\nAt a minimum, the CA MUST host separate Web pages using certificates that are:\ni. valid;\nii. revoked; and\niii. expired.\n",true,"See\nhttps://demossl-rsa-valid.bjca.org.cn\nhttps://demossl-rsa-expired.bjca.org.cn\nhttps://demossl-rsa-revoked.bjca.org.cn\nhttps://demossl-ecc-valid.bjca.org.cn\nhttps://demossl-ecc-expired.bjca.org.cn\nhttps://demossl-ecc-revoked.bjca.org.cn"]
["Appendix D - Country-Specific Interpretative Guidelines (Normative)"]
[1.1,"Non-Latin Organization Name","Where an EV Applicant’s organization name is not registered with a QGIS in Latin characters and the Applicant’s foreign character organization name and registration have been verified with a QGIS in accordance with these Guidelines, a CA MAY include a Latin character organization name in the EV Certificate. In such a case, the CA MUST follow the procedures laid down in this section.\n","N/A","Not stipulation. "]
[1.2,"Romanized Names","In order to include a transliteration/Romanization of the registered name, the Romanization MUST be verified by the CA using a system officially recognized by the Government in the Applicant’s Jurisdiction of Incorporation. If the CA can not rely on a transliteration/Romanization of the registered name using a system officially recognized by the Government in the Applicant’s Jurisdiction of Incorporation, then it MUST rely on one of the options below, in order of preference:\n\nA. A system recognized by the International Organization for Standardization (ISO);\n\nB. A system recognized by the United Nations; or\n\nC. A Lawyer’s Opinion or Accountant’s Letter confirming the proper Romanization of the registered name.\n","N/A","Not stipulation. "]
[1.3,"Translated Name","In order to include a Latin character name in the EV certificate that is not a direct Romanization of the registered name (e.g. an English Name) the CA MUST verify that the Latin character name is:\n\nA. Included in the Articles of Incorporation (or equivalent document) filed as part of the organization registration; or\n\nB. Recognized by a QTIS in the Applicant’s Jurisdiction of Incorporation as the Applicant’s recognized name for tax filings; or\n\nC. Confirmed with a QIIS to be the name associated with the registered organization; or\n\nD. Confirmed by a Verified Legal Opinion or Accountant’s Letter to be a translated trading name associated with the registered organization.\n","N/A","Not stipulation. "]
["D-1","Japan","1. Organization Names\n\nA. The Revised Hepburn method of Romanization, as well as Kunrei-shiki and Nihon-shiki methods described in ISO 3602, are acceptable for Japanese Romanizations.\n\nB. The CA MAY verify the Romanized transliteration, language translation (e.g. English name), or other recognized Roman-letter substitute of the Applicant’s formal legal name with either a QIIS, Verified Legal Opinion, or Verified Accountant Letter.\n\nC. The CA MAY use the Financial Services Agency to verify a Romanized, translated, or other recognized Roman-letter substitute name. When used, the CA MUST verify that the translated English is recorded in the audited Financial Statements.\n\nD. When relying on Articles of Incorporation to verify a Romanized, translated, or other recognized Roman-letter substitute name, the Articles of Incorporation MUST be accompanied either: by a document, signed with the original Japanese Corporate Stamp, that proves that the Articles of Incorporation are authentic and current, or by a Verified Legal Opinion or a Verified Accountant Letter. The CA MUST verify the authenticity of the Corporate Stamp.\n\nE. A Romanized, translated, or other recognized Roman-lettered substitute name confirmed in accordance with this Appendix D-1 stored in the ROBINS database operated by JIPDEC MAY be relied upon by a CA for determining the allowed organization name during any issuance or renewal process of an EV Certificate without the need to re-perform the above procedures.\n\n2. Accounting Practitioner\n\nIn Japan:\n\nA. Accounting Practitioner includes either a certified public accountant (公認会 計士 - Konin-kaikei-shi) or a licensed tax accountant (税理士 – Zei-ri-shi).\n\nB. The CA MUST verify the professional status of the Accounting Practitioner through direct contact with the relevant local member association that is affiliated with either the Japanese Institute of Certified Public Accountants (http://www.hp.jicpa.or.jp), the Japan Federation of Certified Tax Accountant’s Associations (http://www.nichizeiren.or.jp), or any other authoritative source recognized by the Japanese Ministry of Finance (http://www.mof.go.jp) as providing the current registration status of such professionals.\n\n3. Legal Practitioner\n\nIn Japan:\n\nA. Legal Practitioner includes any of the following:\n• a licensed lawyer (弁護士 ‐ Ben-go-shi),\n• a judicial scrivener (司法書士 ‐ Shiho-sho-shi lawyer),\n• an administrative solicitor (行政書士 ‐ Gyosei-sho-shi Lawyer),\n• or a notary public (公証人 ‐ Ko-sho-nin).\n\nFor purposes of the EV Guidelines, a Japanese Notary Public is considered equivalent to a Latin Notary.\n\nB. The CA MUST verify the professional status of the Legal Practitioner by direct contact through the relevant local member association that is affiliated with one of the following national associations:\n• the Japan Federation of Bar Associations (http://www.nichibenren.or.jp),\n• the Japan Federation of Shiho-Shoshi Lawyer’s Associations (http://www.shiho-shoshi.or.jp),\n• the Japan Federation of Administrative Solicitors (http://www.gyosei.or.jp),\n• the Japan National Notaries Association (http://www.koshonin.gr.jp), or\n• any other authoritative source recognized by the Japanese Ministry of Justice (http://www.moj.go.jp) as providing the current registration status of such professionals.\n\n","N/A","Not stipulation. "]