1431811 - Add Notarius Root

Status: RESOLVED WONTFIX

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

Description

[Alexandre Provost]

Attachment: Notarius Root Certificate Authority.cer

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

Steps to reproduce:

I want my Root CA to be included in Mozilla trusted store.





Actual results:

We are currently listed in CCADB by the Microsoft Root Certificate program.  We want to be also recognized by Mozilla.  We are issuing personals certificates for document signature.  We don't issue ssl certificate.  We are Webtrust Certified since 3 years, and recognize by Microsoft Root certificate program since 3 years.

Company/Owner : Notarius
CA : Notarius Root Certificate Authority
CA Owner/Certificate No: A002405
Webtrust Seal : https://cert.webtrust.org/ViewSeal?id=2240


Expected results:

We want to have our root certificate to be recognized by Mozilla, this will help us, and our clients, to get their certificate and theirs signed documents to be valid under more browser and OS.

Comment 1

[Kathleen Wilson]

Our Process is described here:
https://wiki.mozilla.org/CA/Application_Process

Information that the CA needs to provide is listed here:
https://wiki.mozilla.org/CA/Information_Checklist

Comment 2

[Alexandre Provost]

Attachment: Bug 1431811 -Mozilla Root inclusion application.pdf

Comment 3

[Alexandre Provost]

Attachment: Bug 1431811 - Mozilla application - Certificate example.pdf

Comment 4

[Alexandre Provost]

Hi Kathleen,

Thank you for your return.  I have followed all indications you submit and I have completed the application process.  You will find in attachment 2 [details] [diff] [review] PDF files in which you will find all requests application questions and a test documents including example certificate.

I will always be available to answer additional questions.


Thank you,
Alexandre Provost, CISSP.

Comment 5

[Kathleen Wilson]

Attachment: 1431811-CA-Information.pdf

The attached document lists the information that has been verified.
Search for "need" in the document to find the additional information/clarification that the CA needs to provide in this bug.

In particular, note:

1) I did not find description in the CP of how the CA/LRA verifies that the email address to be included in the certificate is owned/controlled by the certificate subscriber. This needs to be in the CP.
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control

2) It is not clear to me if/when LRA's are audited. Or how it is regularly checked that the LRA is only issuing certs that it should be issuing, and following the CP. This information should be in the CP.


Also, please note that it is time for a new audit statement. 
https://cert.webtrust.org/SealFile?seal=2240&file=pdf
Audit Statement Date: 4/10/2017
Make sure that your future audit statements satisfy section 3.1.4 of Mozilla's Root Store Policy...
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#public-audit-information
In particular: "3. Distinguished Name and SHA256 fingerprint of each root and intermediate certificate that was in scope;"

Comment 6

[Ben Wilson]

Is Notarius still interested in pursuing its root store inclusion request?
If so, it needs to update the information in the CCADB.
The public version of CCADB case no. 256 for this request is: https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000256.

Comment 7

[Alexandre Provost]

Hi Ben,
We are still interested in the inclusion. I will adjust the CP/CPS about the email validation, and will update the other information.

Comment 8

[Alexandre Provost]

Hi,
The CP and CPS has been updated to include the missing requirement.

I hope all information is now in conformity to Mozilla requirements.

https://notarius.com/wp-content/uploads/2020/11/Notarius-PKI-Certificate-Policy.pdf
https://notarius.com/wp-content/uploads/2020/11/Notarius-PKI_Certification-Practices-Statement.pdf

Comment 9

[Ben Wilson]

I don't see where the email verification procedure is adequately described. Maybe I'm missing it. Also, I compared the Notarius CP and CPS outline with the RFC 3647 format, and note the following discrepancies (Notarius CP/CPS on left, RFC 3647 on right):

1	General Provisions		1. INTRODUCTION
1.1	Overview		1.1 Overview
1.2	Document Identification and Object Identifier Numbers (OID)		1.2 Document name and identification
1.3	Definitions and Abbreviations	Should be § 1.6	1.3 PKI participants
1.3.1	Abbreviations		1.3.1 Certification authorities
1.3.2	Definitions		1.3.2 Registration authorities
1.4	Interpretation		1.3.3 Subscribers
1.5	Compliance with Applicable Standards		1.3.4 Relying parties
1.6	PKI Components	Should be § 1.3	1.3.5 Other participants
1.6.1	Certification Authority (CA)	Should be § 1.3.1	1.4 Certificate usage
1.6.2	Certificate and Repository Services Provider (C/RSP)		1.4.1. Appropriate certificate uses
1.6.3	Local Registration Authority (LRA)	Should be § 1.3.2	1.4.2 Prohibited certificate uses
1.6.4	Subscriber	Should be § 1.3.3	1.5 Policy administration
1.6.5	Other Participants	Should be § 1.3.5	1.5.1 Organization administering the document
1.7	Use of Keys and Certificates	Should be § 1.4 or § 6.1.6	1.5.2 Contact person
1.7.1	Authorized Use of Keys and Certificates		1.5.3 Person determining CPS suitability for the policy
1.7.2	Limitations of Use		1.5.4 CPS approval procedures
1.7.3	Authorized Holder		1.6 Definitions and acronyms
1.8	Policy Administration	Should be § 1.5
1.8.1	Organization Administering the Document	Should be § 1.5.1
1.8.2	Contact Person	Should be § 1.5.2
1.8.3	CP and CPS Approval Procedures	Should be § 1.5.4
2	Publication and Repository Responsibilities	OK	2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
2.1	Repositories	OK	2.1 Repositories
2.2	Publication of Certification Information	OK	2.2 Publication of certification information
2.3	Time and Frequency of Publication	OK	2.3 Time or frequency of publication
2.4	Access Controls on Repositories	OK	2.4 Access controls on repositories
3	Identification and Authentication	OK	3. IDENTIFICATION AND AUTHENTICATION
3.1	Naming	OK	3.1 Naming
3.1.1	Types of Names	OK	3.1.1 Types of names
3.1.2	Explicit Names	OK	3.1.2 Need for names to be meaningful
3.1.3	Anonymization or Use of Pseudonyms	OK	3.1.3 Anonymity or pseudonymity of subscribers
3.1.4	Rules for Interpreting Various Name Forms	OK	3.1.4 Rules for interpreting various name forms
3.1.5	Uniqueness of Names	OK	3.1.5 Uniqueness of names
3.1.6	Identification, Authentication and Role of Trademarks	OK	3.1.6 Recognition, authentication, and role of trademarks
3.2	Identity Validation	OK	3.2 Initial identity validation
3.2.1	Initial Identity Verification		3.2.1 Method to prove possession of private key
3.2.2	Identity Validation for Delivery of Activation Data		3.2.2 Authentication of organization identity
3.2.3	Identity Validation for Certificate Renewals	Should be § 4.6	3.2.3 Authentication of individual identity
3.2.4	Identity Validation for a Re-key	Should be § 3.3 or § 4.7	3.2.4 Non-verified subscriber information
3.2.5	Identity Validation for Certificate Modifications	Should be § 4.8	3.2.5 Validation of authority
			3.2.6 Criteria for interoperation
			3.3 Identification and authentication for re-key requests
			3.3.1 Identification and authentication for routine re-key
			3.3.2 Identification and authentication for re-key after revocation
			3.4 Identification and authentication for revocation request
4	Certificate Life-Cycle Operational Requirements	OK	4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS
4.1	Certificate Application	OK	4.1 Certificate Application
4.1.1	Who Can Submit a Certificate Application	OK	4.1.1 Who can submit a certificate application
			4.1.2 Enrollment process and responsibilities
4.1.2	Application Process	Should be § 4.2	4.2 Certificate application processing
			4.2.1 Performing identification and authentication functions
4.1.3	Approval or Rejection of Certificate Applications	Should be § 4.2.2	4.2.2 Approval or rejection of certificate applications
4.1.4	Time to Process Certificate Applications	Should be § 4.2.3	4.2.3 Time to process certificate applications
			4.3 Certificate issuance
			4.3.1 CA actions during certificate issuance
			4.3.2 Notification to subscriber by the CA of issuance of certificate
4.1.5	Certificate Acceptance	Should be § 4.4	4.4 Certificate acceptance
			4.4.1 Conduct constituting certificate acceptance
			4.4.2 Publication of the certificate by the CA
			4.4.3 Notification of certificate issuance by the CA to other entities
			4.5 Key pair and certificate usage
			4.5.1 Subscriber private key and certificate usage
			4.5.2 Relying party public key and certificate usage
4.2	Certificate Renewal Requests	Should be § 4.6	4.6 Certificate renewal
			4.6.1 Circumstance for certificate renewal
4.2.1	Who May Request a Renewal	Should be § 4.6.2	4.6.2 Who may request renewal
4.2.2	Certificate Renewal Procedure		4.6.3 Processing certificate renewal requests
4.2.3	Processing Certificate Renewal Requests		4.6.4 Notification of new certificate issuance to subscriber
4.2.4	Renewal Notice		4.6.5 Conduct constituting acceptance of a renewal certificate
			4.6.6 Publication of the renewal certificate by the CA
			4.6.7 Notification of certificate issuance by the CA to other entities
4.3	Certificate Recovery	Should be § 4.12	4.7 Certificate re-key
4.3.1	Who May Request a Recovery		4.7.1 Circumstance for certificate re-key
4.3.2	Procedure for Certificate Recovery		4.7.2 Who may request certification of a new public key
4.3.3	Processing a Certificate Recovery		4.7.3 Processing certificate re-keying requests
			4.7.4 Notification of new certificate issuance to subscriber
			4.7.5 Conduct constituting acceptance of a re-keyed certificate
			4.7.6 Publication of the re-keyed certificate by the CA
			4.7.7 Notification of certificate issuance by the CA to other entities
4.4	Certificate Modification Requests	Should be § 4.8	4.8 Certificate modification
			4.8.1 Circumstance for certificate modification
4.4.1	Who May Request Certificate Modifications	Should be § 4.8.2	4.8.2 Who may request certificate modification
4.4.2	Circumstances for a Modification	Should be § 4.8.1	4.8.3 Processing certificate modification requests
4.4.3	Processing Certificate Modification Requests	Should be § 4.8.3	4.8.4 Notification of new certificate issuance to subscriber
4.4.4	Notification of Modifications	Should be § 4.8.4	4.8.5 Conduct constituting acceptance of modified certificate
			4.8.6 Publication of the modified certificate by the CA
			4.8.7 Notification of certificate issuance by the CA to other entities
4.5	Certificate Revocation	Should be § 4.9	4.9 Certificate revocation and suspension
4.5.1	Circumstances for Revocation		4.9.1 Circumstances for revocation
4.5.2	Who Can Request a Revocation	Should be § 4.9.2	4.9.2 Who can request revocation
4.5.3	Who May Revoke Signature Holder Certificates		4.9.3 Procedure for revocation request
4.5.4	Revocation Request Procedure	Should be § 4.9.3	4.9.4 Revocation request grace period
4.5.5	Notice of Revocation		4.9.5 Time within which CA must process the revocation request
			4.9.6 Revocation checking requirement for relying parties
			4.9.7 CRL issuance frequency (if applicable)
			4.9.8 Maximum latency for CRLs (if applicable)
			4.9.9 On-line revocation/status checking availability
			4.9.10 On-line revocation checking requirements
			4.9.11 Other forms of revocation advertisements available
			4.9.12 Special requirements re key compromise
4.6	Certificate Suspension	Should be § 4.9.13	4.9.13 Circumstances for suspension
			4.9.14 Who can request suspension
			4.9.15 Procedure for suspension request
			4.9.16 Limits on suspension period
4.7	Certificate Status Information Functions	Should be § 4.10	4.10 Certificate status services
			4.10.1 Operational characteristics
			4.10.2 Service availability
			4.10.3 Optional features
			4.11 End of subscription
4.8	Sequestration of Keys and Escrow	Should be § 4.12	4.12 Key escrow and recovery
			4.12.1 Key escrow and recovery policy and practices
			4.12.2 Session key encapsulation and recovery policy and practices
5	Facility Management and Operational Controls	OK	5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS
5.1	Physical Controls	OK	5.1 Physical controls
5.1.1	Site Location	OK	5.1.1 Site location and construction
5.1.2	Physical Access	OK	5.1.2 Physical access
5.1.3	Power and Air Conditioning	OK	5.1.3 Power and air conditioning
5.1.4	Exposure to water damage	OK	5.1.4 Water exposures
5.1.5	Fire Prevention and Protection	OK	5.1.5 Fire prevention and protection
5.1.6	Media Storage	OK	5.1.6 Media storage
5.1.7	Waste Disposal	OK	5.1.7 Waste disposal
5.1.8	Off-site Backup	OK	5.1.8 Off-site backup
5.1.9	Disaster Recovery
5.2	Procedural Controls	OK	5.2 Procedural controls
5.2.1	Trusted Roles	OK	5.2.1 Trusted roles
5.2.2	Number of Persons Required per Task	OK	5.2.2 Number of persons required per task
5.2.3	Identification and Authentication for Each Role	OK	5.2.3 Identification and authentication for each role
5.2.4	Roles Requiring Separation of Duties	OK	5.2.4 Roles requiring separation of duties
5.2.5	Risk Analysis
5.3	Personnel Controls	OK	5.3 Personnel controls
5.3.1	Qualifications, Experience, and Clearance Requirements	OK	5.3.1 Qualifications, experience, and clearance requirements
5.3.2	Background Check Procedures	OK	5.3.2 Background check procedures
5.3.3	Training Requirements	OK	5.3.3 Training requirements
5.3.4	Retraining Frequency and Requirements	OK	5.3.4 Retraining frequency and requirements
5.3.5	Job Rotation Frequency and Sequence	OK	5.3.5 Job rotation frequency and sequence
5.3.6	Sanctions for Unauthorized Actions	OK	5.3.6 Sanctions for unauthorized actions
5.3.7	Independent Contractor Requirements	OK	5.3.7 Independent contractor requirements
5.3.8	Documentation Provided to Personnel	OK	5.3.8 Documentation supplied to personnel
5.4	Audit Log Procedure	OK	5.4 Audit logging procedures
5.4.1	Types of Events Recorded	OK	5.4.1 Types of events recorded
5.4.2	Frequency of Processing Log	OK	5.4.2 Frequency of processing log
5.4.3	Retention Period for Audit Logs	OK	5.4.3 Retention period for audit log
5.4.4	Protection of Audit Logs	OK	5.4.4 Protection of audit log
5.4.5	Audit Log Backup Procedure	OK	5.4.5 Audit log backup procedures
5.4.6	Notification of recorded events sent to the originating source	OK	5.4.6 Audit collection system (internal vs. external)
5.4.7	Vulnerability Assessments	OK	5.4.7 Notification to event-causing subject
			5.4.8 Vulnerability assessments
5.5	Records Archival	OK	5.5 Records archival
5.5.1	Types of Records Archived	OK	5.5.1 Types of records archived
5.5.2	Archive Retention Period	OK	5.5.2 Retention period for archive
5.5.3	Protection of Archives	OK	5.5.3 Protection of archive
5.5.4	Requirements for Timestamping of Records	OK	5.5.4 Archive backup procedures
5.5.5	Archive Collection System	OK	5.5.5 Requirements for time-stamping of records
5.5.6	Procedures for Obtaining and Verifying Archive Information	OK	5.5.6 Archive collection system (internal or external)
			5.5.7 Procedures to obtain and verify archive information
5.6	Key Changeover	OK	5.6 Key changeover
5.7	Compromised Keys and Disaster Recovery	OK	5.7 Compromise and disaster recovery
5.7.1	Incident and Compromised Key Handling Procedures	OK	5.7.1 Incident and compromise handling procedures
5.7.2	Corrupted Computing Resources, Software and/or Data	OK	5.7.2 Computing resources, software, and/or data are corrupted
5.7.3	Compromised Private Key Procedures for Entities	OK	5.7.3 Entity private key compromise procedures
5.7.4	Business Continuity Capabilities after a Disaster	OK	5.7.4 Business continuity capabilities after a disaster
5.8	Termination of Activities	OK	5.8 CA or RA termination
5.8.1	CA Termination
5.8.2	C/RSP Termination
5.8.3	LRA Termination
5.8.4	End of Life of the PKI
6	Technical Security Controls	OK	6. TECHNICAL SECURITY CONTROLS
6.1	Key Pair Generation and Installation	OK	6.1 Key pair generation and installation
6.1.1	Key Pair Generation	OK	6.1.1 Key pair generation
6.1.2	Private Key Delivery to Subscribers	OK	6.1.2 Private key delivery to subscriber
6.1.3	CA Public Key Delivery to Relying Parties		6.1.3 Public key delivery to certificate issuer
6.1.4	Key Sizes	Should be § 6.1.5	6.1.4 CA public key delivery to relying parties
6.1.5	Generating Public Key Parameters and Quality Control	Should be § 6.1.6	6.1.5 Key sizes
6.1.6	Key Usage	Should be § 6.1.7	6.1.6 Public key parameters generation and quality checking
			6.1.7 Key usage purposes (as per X.509 v3 key usage field)
6.2	Protection of Private Keys and Cryptographic Modules	OK	6.2 Private Key Protection and Cryptographic Module Engineering Controls
6.2.1	Cryptographic Module Standards and Controls	OK	6.2.1 Cryptographic module standards and controls
6.2.2	Protection of the CA’s Private Keys (and their control by multiple individuals)	OK	6.2.2 Private key (n out of m) multi-person control
6.2.3	Private Key Escrow	OK	6.2.3 Private key escrow
6.2.4	Private Key Backup	OK	6.2.4 Private key backup
6.2.5	Private Key Archiving	OK	6.2.5 Private key archival
6.2.6	Private Key Transfer into or from a Cryptographic Module	OK	6.2.6 Private key transfer into or from a cryptographic module
6.2.7	Private Key Storage in the Cryptographic Module	OK	6.2.7 Private key storage on cryptographic module
6.2.8	Multi-user Control (m of n)		6.2.8 Method of activating private key
6.2.9	Protecting Subscribers’ Private Keys		6.2.9 Method of deactivating private key
6.2.10	Private Key Activation Method	Should be § 6.2.8	6.2.10 Method of destroying private key
6.2.11	Private Key Deactivation Method	Should be § 6.2.9	6.2.11 Cryptographic Module Rating
6.2.12	Private Key Destruction Method	Should be § 6.2.10
6.2.13	Evaluation of the Cryptographic Module
6.3	Other Aspects of Key and Certificate Management	OK	6.3 Other aspects of key pair management
6.3.1	Public Key Archival	OK	6.3.1 Public key archival
6.3.2	Certificate and Key Usage Periods	OK	6.3.2 Certificate operational periods and key pair usage periods
6.4	Activation Data	OK	6.4 Activation data
6.4.1	Activation Data Generation and Installation	OK	6.4.1 Activation data generation and installation
6.4.2	Activation Data Protection	OK	6.4.2 Activation data protection
6.4.3	Other Aspects of Activation Data	OK	6.4.3 Other aspects of activation data
6.5	Computer Security Controls	OK	6.5 Computer security controls
			6.5.1 Specific computer security technical requirements
			6.5.2 Computer security rating
6.6	Life Cycle Technical Controls	OK	6.6 Life cycle technical controls
			6.6.1 System development controls
			6.6.2 Security management controls
			6.6.3 Life cycle security controls
6.7	Network Security Controls	OK	6.7 Network security controls
6.8	Timestamping and dating system	OK	6.8 Time-stamping
7	Certificate, CRL, OCSP, and TSA Profiles	OK	7. CERTIFICATE, CRL, AND OCSP PROFILES
7.1	Certificate Profile	OK	7.1 Certificate profile
			7.1.1 Version number(s)
			7.1.2 Certificate extensions
			7.1.3 Algorithm object identifiers
			7.1.4 Name forms
			7.1.5 Name constraints
			7.1.6 Certificate policy object identifier
			7.1.7 Usage of Policy Constraints extension
			7.1.8 Policy qualifiers syntax and semantics
			7.1.9 Processing semantics for the critical Certificate Policies extension
7.2	CRL Profile	OK	7.2 CRL profile
			7.2.1 Version number(s)
			7.2.2 CRL and CRL entry extensions
7.3	OCSP Profile	OK	7.3 OCSP profile
7.4	TSA Profile		7.3.1 Version number(s)
			7.3.2 OCSP extensions
8	Compliance Audit and Other Assessments	OK	8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS
8.1	Frequency and/or Circumstances of Assessments	OK	8.1 Frequency or circumstances of assessment
8.2	Identity/Qualification of Assessor	OK	8.2 Identity/qualifications of assessor
8.3	Assessor’s Relationships to Assessed Entity	OK	8.3 Assessor's relationship to assessed entity
8.4	Topics Covered by the Assessment	OK	8.4 Topics covered by assessment
8.5	Actions Taken as a Result of Deficiency	OK	8.5 Actions taken as a result of deficiency
8.6	Communication of Results	OK	8.6 Communication of results
9	Other Business-Related and Legal Matters	OK	9. OTHER BUSINESS AND LEGAL MATTERS
9.1	Fees	OK	9.1 Fees
9.1.1	Subscription Fees	OK	9.1.1 Certificate issuance or renewal fees
9.1.2	CRL Access Fees and Certificate Status	Should be § 9.1.3	9.1.2 Certificate access fees
9.1.3	Identity Verification Fees		9.1.3 Revocation or status information access fees
9.1.4	Fees for Other Services	OK	9.1.4 Fees for other services
9.1.5	Refund Policy	OK	9.1.5 Refund policy
9.2	Financial Responsibility	OK	9.2 Financial responsibility
9.2.1	Insurance Coverage	OK	9.2.1 Insurance coverage
9.2.2	Other Assets	OK	9.2.2 Other assets
9.2.3	Insurance or Warranty Coverage for User Entities	OK	9.2.3 Insurance or warranty coverage for end-entities
9.3	Confidentiality of Business Information	OK	9.3 Confidentiality of business information
9.3.1	Scope of Confidential Information	OK	9.3.1 Scope of confidential information
9.3.2	Information Not Within the Scope of Confidential Information	OK	9.3.2 Information not within the scope of confidential information
9.3.3	Responsibility to Protect Confidential Information	OK	9.3.3 Responsibility to protect confidential information
9.4	Protection of Personal Information	OK	9.4 Privacy of personal information
9.4.1	Privacy Plan	OK	9.4.1 Privacy plan
9.4.2	Information Deemed Private	OK	9.4.2 Information treated as private
9.4.3	Information Not Deemed Private	OK	9.4.3 Information not deemed private
9.4.4	Responsibility to Protect Private Information	OK	9.4.4 Responsibility to protect private information
9.4.5	Notice and Consent to Use Private Information	OK	9.4.5 Notice and consent to use private information
9.4.6	Disclosure Pursuant to Judicial or Administrative Process	OK	9.4.6 Disclosure pursuant to judicial or administrative process
9.4.7	Other Information Disclosure Circumstances	OK	9.4.7 Other information disclosure circumstances
9.5	Intellectual Property Rights	OK	9.5 Intellectual property rights
9.6	Representation and Warranties	OK	9.6 Representations and warranties
9.6.1	Regarding Information Contained in Certificates		9.6.1 CA representations and warranties
9.6.2	Regarding Information in the Repository		9.6.2 RA representations and warranties
			9.6.3 Subscriber representations and warranties
			9.6.4 Relying party representations and warranties
			9.6.5 Representations and warranties of other participants
9.7	Disclaimers of Warranties	OK	9.7 Disclaimers of warranties
9.8	Limitations of Liability	OK	9.8 Limitations of liability
9.9	Indemnities	OK	9.9 Indemnities
9.10	Approval Procedures	OK	9.10 Term and termination
9.10.1	CP Approval Procedure		9.10.1 Term
9.10.2	CPS Approval Procedure		9.10.2 Termination
9.10.3	Term of validity		9.10.3 Effect of termination and survival
9.11	Individual notices and communications with participants	OK	9.11 Individual notices and communications with participants
9.12	Amendments	OK	9.12 Amendments
			9.12.1 Procedure for amendment
			9.12.2 Notification mechanism and period
			9.12.3 Circumstances under which OID must be changed
9.13	Dispute Resolution Provisions	OK	9.13 Dispute resolution provisions
9.14	Governing Law	OK	9.14 Governing law
9.15	Interpretation		9.15 Compliance with applicable law
9.15.1	Applicable Laws		9.16 Miscellaneous provisions
9.15.2	Validity of Provisions		9.16.1 Entire agreement
9.16	Force majeure	Should be § 9.16.5	9.16.2 Assignment
9.17	Review		9.16.3 Severability
9.18	Effective Date		9.16.4 Enforcement (attorneys' fees and waiver of rights)
			9.16.5 Force Majeure
			9.17 Other provisions

Comment 10

[Alexandre Provost]

Hi,

You will find the email verification process describe in sections 3.2.1 (Initial Identity Verification) in CP and CPS. The email is validated by using the holder email to initiate the second authentication factor.

You will also find reference at 4.1.2 in CPS (Application Process) and at 3.2.2 (Identity Validation for Delivery of Activation Data) in CPS.

Also, some mentions about email validation at 1.6.4.2, third dot. (subscribers must)

I will forward your email to the conformity team about the RFC 3647 vs our CP/CPS.

I hope everything conforms.

Comment 11

[Ben Wilson]

Do you have any updates?

Comment 12

[Alexandre Provost]

Hi, I reply to Comment9 last january.

Here are the new CP and CPS link since we have change our Website.

https://www.notarius.com/hubfs/document/en/notarius-pki-certificate-policy.pdf
https://www.notarius.com/hubfs/document/en/notarius-pki-certification-practices-statement.pdf

Case 00000256 has also be updated : https://ccadb.force.com/s/case/5001J00000YbG09/include-notarius-root

(In reply to Alexandre Provost from comment #10)

Hi,

You will find the email verification process describe in sections 3.2.1 (Initial Identity Verification) in CP and CPS. The email is validated by using the holder email to initiate the second authentication factor.

You will also find reference at 4.1.2 in CPS (Application Process) and at 3.2.2 (Identity Validation for Delivery of Activation Data) in CPS.

Also, some mentions about email validation at 1.6.4.2, third dot. (subscribers must)

I will forward your email to the conformity team about the RFC 3647 vs our CP/CPS.

I hope everything conforms.

Comment 13

[Ben Wilson]

We need updated information in the CCADB. I need to hear back from Notarius by Friday, 17-Dec-2021.

Comment 14

[Ben Wilson]

Here are my comments to the Notarius CPS.

Review of Notarius CPS v. 3.3 dated 2021-11-24

General Comment: A good resource for reviewing the SMIME issues that might potentially arise in the context of this CPS is here: https://github.com/cabforum/smime/blob/preSBR/SBR.md (the “pre-SBRs”).

General Comment: Use of the term “keys” throughout the CP and CPS implies that keys are provided to the subscriber (rather than having the subscriber generate their own keys). This relationship should be clarified. Use of the term “signatures” should also be clarified.

Page 3 states, “Any reproduction, printing or transmission of this document is strictly prohibited. For any reproduction in whole or in part, obtain prior written permission from Solutions Notarius Inc.” However, Mozilla Policy requires that CP and CPS documents submitted to us must be made available on at least Creative Commons, Attribution-NoDerivs (CC-BY-ND) 4.0 basis. See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#3-documentation - Should be fixed

Section 1.3.1 – SLA should be “Service Level Agreement” not “Service Legal Agreement” – Please fix

Section 1.3.2 – The definition of “Digital Signature” is non-standard. For instance, the definition says, “A Digital Signature remains valid until it expires or is revoked.” The use of the term “Digital Signature” in many parts of the CP and CPS should be modified or replaced with the more common term, “Digital Certificate” or “Digital Signature Certificate”. Or, if Notarius’ solution includes subscriber access to keys that can “expire” or be “revoked”, then that should be made more clear. Please fix

Section 1.5 - RFC 3647 has not been followed as requested in Comment #9 – This needs to be fixed

Section 1.8.2 (should be section 1.5.2, according to RFC 3647) needs to explain that the contact information may be used by third parties who want to present Notarius with proof of private key compromise, so that corresponding certificates can be revoked. This can also be discussed in section 4.5 (and section 4.5 should be changed and renumbered to be section 4.9, according to RFC 3647). – Please fix

Section 2.2 – “The CPS (coming soon)” has a URL of https://www.notarius.com/hubfs/document/en/notarius-pki-certification-practices-statement.pdf

Section 2.3 should specify that the CP and CPS are reviewed and re-published at least once every 365 days with a new date and a new version number, even if there are no other changes. Should fix

Section 3.2.1 states, “· Have PSC/R confirm/validate his professional e-mail address. · Defined its Security Questions by replying the PSC/R's email validating his business email.” Should fix to explicitly define the email verification practice that is used by Notarius.

For SMIME certificates, the domain part of the email address cannot be delegated to an external, third-party RA. Notarius is required to ensure that the full email address is verified through a challenge-response function, or that the domain part is validated, if email address verification is delegated to an Enterprise RA. See item #2 here https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#22-validation-practices, which says,

For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA SHALL NOT delegate validation of the domain portion of an email address. The CA MAY rely on validation the CA has performed for an Authorization Domain Name (as specified in the Baseline Requirements) as being valid for subdomains of that Authorization Domain Name. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs to perform this verification.

See https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Email_Challenge-Response and https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control.

Section 4.5.1 – Reasons for revocation - Notarius should compare its list of revocation reasons with Mozilla Root Store Policy section 6.2 and ensure that all of Mozilla’s required revocation reasons are covered - see https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#62-smime (e.g. “5. the CA receives notice or otherwise becomes aware of any circumstance indicating that use of the email address in the certificate is no longer legally permitted;”)

Sections 4.5.2.1 and 4.5.3 - “Who may request revocation” should allow third parties to prove private key compromise by digitally signing a request to revoke the certificate using the private key. Should fix

Re: Section 4.5.4.1 –Section 4.9.12 of the CPS should explain how a third party with the possession of the private key can prove key compromise and request revocation. That section must “clearly specify the methods that parties may use to demonstrate private key compromise.” See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation. Must fix

Section 4.9.12 - See preceding comment.

Sections 5, 6.5 and 6.7 – Notarius should incorporate by reference and attest to compliance with the CA/Browser Forum’s Network and Certificate System Security Requirements, https://cabforum.org/network-security-requirements/ See Item #2 in https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#21-ca-operations

Section 5.7.3 – In the event of CA private key compromise, Notarius must inform Mozilla and other root stores that have included the Notarius CA certificate hierarchies. (The phrase “as well as third parties with whom the CA has signed agreements” does not adequately ensure that Mozilla will be notified.) See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#41-additional-requirements – “f the revocation of an intermediate certificate chaining up to a root in Mozilla’s root store is due to a security concern, as well as performing the actions defined in the CCADB Policy, a security bug MUST be filed in Bugzilla.” - Should fix

Section 5.8 – Also, in the event of CA termination, Mozilla should be notified in advance. Should fix

Sections 6.5 and 6.7 - See comments above regarding the CA/Browser Forum’s Network and Certificate Systems Security Requirements.

Certificate Profiles

The CPS does not contain any certificate profile for an S/MIME certificate where the EKU contains emailProtection. This needs to be fixed.

Also, the CA that issues S/MIME certificates must also have the emailProtection EKU.

According to section 5.3 of the MRSP, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#53-intermediate-certificates:

Intermediate certificates created after January 1, 2019, with the exception of cross-certificates that share a private key with a corresponding root certificate:

MUST contain an EKU extension; and,

MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and,

MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same certificate.

Comment 15

[Alexandre Provost]

We are reviewing the latest comments about our CPS. We will apply most of the suggested modification from Ben's comment.

PKI Officer will review the CPS in June. I will keep the bug updated as soon the CPS update and online.

Thank you.

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:kwilson, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 17

[Ben Wilson]

The following information is needed: root key generation report, updated company and root information (Add/Update Root Request in the CCADB), value statement (https://wiki.mozilla.org/CA/Quantifying_Value), and compliance self-assessment (for those parts relevant to SMIME issuance) - https://wiki.mozilla.org/CA/Compliance_Self-Assessment.

Comment 18

[Ben Wilson]

Back in January 2023, this CA indicated that they were no longer pursuing this request.