Closed Bug 511380 Opened 15 years ago Closed 10 years ago

Add NIC (India) Root CA Certificate

Categories

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

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

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

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

References

Details

(Whiteboard: Public Discussion Action Items - Update CPS)

Attachments

(10 files)

NICCA certificate
1.51 KB, application/x-x509-ca-cert
Details
CCA Root Certificate
1.14 KB, application/x-x509-ca-cert
Details
NICCA Hierarchy
31.71 KB, image/jpeg
Details
Initial Information Gathering Document
34.19 KB, application/pdf
Details
Inputs to Initial Information Gathering Document
25.00 KB, application/msword
Details
Audit Equivalency Certificate
119.82 KB, application/pdf
Details
Contact Details of Mr.Debopriya Kar
23.50 KB, application/msword
Details
Audit Equivalency Certificate of NICCA - 2010
389.26 KB, application/pdf
Details
Completed Information Gathering Document
163.51 KB, application/pdf
Details
Updated Information Gathering Document
186.31 KB, application/pdf
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Build Identifier: 

1.	General information about the CA’s associated organization (i.e., the company, nonprofit organization, or government agency operating the CA)
      1. Name – National Informatics Centre 
      2. Website URL – https://nicca.nic.in 
      3. Organizational type – Government
      4. Primary market / customer base – Issued to subscribers in the 
         Government, PSU, Statutory Bodies, and Govt. Registered Companies in
         India.
2.	For each root CA whose certificate is to be included in Mozilla (or whose metadata is to be modified): 
         1. The name of the root CA – NIC Certifying Authority
         2. The root CA certificate – https://nicca.nic.in
         3. The X.509 certificate version – Version 3
         4. SHA-1 fingerprint - 48 22 82 4e ce 7e d1 45 0c 03 9a a0 77 dc 1f 8a 
            e3 48 9b bf
         5. Type of signing key - RSA 
         6. Signing key parameters - 2048 bits 
         7. Valid from (YYYY-MM-DD) - Monday, July 02, 2007 12:11:59 PM
         8. Valid to (YYYY-MM-DD) - Saturday, July 04, 2015 12:00:00 PM
         9. A description of the PKI hierarchy rooted at or otherwise 
            associated with this root CA certificate, including: 
             1.	A list (or summary description) of CAs with certificates signed
                by this root – NICCA - Sub-CA for e-passport 
             2.	A list of any other root CAs that have issued cross-signing 
                certificates for this root CA- No
             3.	The extent and nature of contractual and technical controls
                exercised over subordinate CAs – Sub-CAs are created for
                different organizations and agencies, for ease of operations 
                and management. Sub-CAs are created purely in a technical
                context, to be part of the NICCA’s technical infrastructure.
                The keys created for Sub-Ca are located only on NICCA’s 
                technical infrastructure.
                    1.	Whether or not subordinate CAs are constrained to issue
                        certificates only within certain domains. Sub-CAs can
                        issue Certificates only in the specified domain for
                        which the sub-CA has been created. Agencies for whom
                        the Sub-CAs are created have to be reflected in the
                        corresponding certificate as ‘NICCA – Sub-CA for <name
                        of agency for whom Sub-CA has been set up>’. 
                   2.	Whether or not subordinate CAs can create their own
                        subordinates. No. The certificate issuing authority for
                        the Sub-CA always remains only with NICCA. 
             4.	The extent and nature of audits performed against subordinate
                CAs, including –NICCA - Sub-CA for e-passport
                   1.	Whether or not subordinate CAs are included within the
                        scope of any audit(s) done against the root CA. 
                   2.	Whether or not subordinate CAs are subject to 
                        third-party audits independent of any audit(s) done   
                        against the root CA. 
                   3.	The frequency at which any audit(s) for subordinate CAs 
                        are done. 
         10. Whether certificates are issued for any of the following purposes 
             within the hierarchy rooted at this root CA certificate: 
             1.	Certificates usable for enabling web or other servers to 
                support SSL/TLS connections. Yes 
             2.	Certificates usable for signing and encrypting email messages 
                e.g., using S/MIME). Yes 
             3.	Certificates usable for digitally signing executable code 
                objects. Yes 
       11. If SSL certificates are issued within the hierarchy rooted at this 
           root CA certificate: 
             1.	Whether or not the domain name referenced in the certificate is 
               verified to be owned/controlled by the certificate subscriber - 
               Yes
             2.	Whether or not the value of the Organization attribute is 
                verified to be that associated with the certificate subscriber 
                - Yes 
             3.	Whether verification of the certificate subscriber conforms to 
                the Extended Validation Certificate Guidelines issued by the 
                CAB Forum – Not issued
       12. If email certificates are issued within the hierarchy rooted at this 
           root CA certificate: 
             1.	Whether or not the email account associated with the email 
                address in the certificate is verified to be owned/controlled 
                by the certificate subscriber – Yes verification is done
             2.	Whether or not the identity information in the certificate is 
                verified to be that of the certificate subscriber - Yes 
                verification is done
       13. If code signing certificates are issued within the hierarchy rooted 
           at this root CA certificate, whether or not the identity information 
           in the certificate is verified to be that of the certificate 
           subscriber – Yes verification is done
       14. If EV certificates are issued within the hierarchy rooted at this 
           root, the EV policy OID(s) associated with those EV certificates – 
           Not issued 
       15. Example certificate(s) issued within the hierarchy rooted at this 
           root, including the full certificate chain(s) where applicable – 
           Examples will be included at the time of submission (There should be 
           at least one example certificate for each of the major types of 
           certificates issued, e.g., email vs. SSL vs. code signing, or EV vs. 
           OV vs. DV. For SSL certificates this should also include URLs of one 
           or more web servers using the certificate(s).) 
     16. Whether or not the validity of end entity and CA certificates issued   
         within the hierarchy rooted at this root may be verified using 
         Certificate Revocation Lists (CRLs) and, if so, the URL(s) at which 
         the CRL(s) may be obtained – https://nicca.nic.in/crl_2783.crl
     17. Whether or not the validity of end entity and CA certificates issued 
         within the hierarchy rooted at this root may be verified using the 
         Online Certificate Status Protocol (OCSP) and, if so, the URL(s) for 
         the associated OCSP responder(s) – Currently not provided
     18. The maximum time elapsing from the revocation of an end entity or CA 
         certificate until CRLs and/or OCSP responders are updated to reflect 
         that revocation – CRL updated immediately after the 
         suspension/revocation
     19. The published document(s) describing how certificates are issued 
         within the hierarchy rooted at this root, as well as other practices 
         associated with the root CA and other CAs in the hierarchy, including 
         in particular the Certification Practice Statement(s) (CPS) and 
         related documents – https://nicca.nic.in/pdf/niccacps.pdf
     20. The published document(s) relating to independent audit(s) of the root 
         CA and any CAs within the hierarchy rooted at the root. (For example, 
         for WebTrust for CAs audits this would be the "audit report and 
         management assertions" document available from the webtrust.org site 
         or elsewhere.) – not publicly available 


Reproducible: Always
Accepting this bug, and starting the Information Gathering and Verification phase as described at https://wiki.mozilla.org/CA:How_to_apply
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
On the NIC website I found the zip file containing the certs as follows

Download Certificate Chain (NICCA & CCA certs): http://nicca.nic.in/cert/chain.zip

However, I am unable to extract the files from the .zip file. 
I get an error about unknown compression method.

Would you please attach the NIC CA root cert to this bug? Use uncompressed, .crt or .cer format.
Thank you for your email. As desired by you, I am attaching the requisite file. However, before I proceed further, I would like to give you a brief background.
 
National Informatics Centre(NIC), is a premier IT Organisation of the Department of Information Technology,  Govt. of India, has been instrumental in steering Information and Technology applications in various Government Departments at Central, State and District levels. NIC has set up the state of art  Certifying Authority (NICCA) in May, 2003, under license from the Controller of Certifying Authorities  (CCA).

The Government of India established the CCA, under section 17 of the Information Technology (IT) Act 2000, an Act which was passed by the Indian Parliament in June 2000. The Act defines the legal and administrative framework for establishment of a Public Key Infrastructure (PKI) in the country for creating trust in the electronic environment. The CCA is the apex regulatory body to issue license to Certifying Authorities, in accordance with the provisions of the IT Act 2000. 

CCA has set up the The Root Certifying Authority of India (RCAI), which is at the root of trust in the hierarchical PKI established in the country. The Certifying Authorities, which meet the requisite criteria specified in the IT Act 2000, are issued licenses to operate by CCA and come under the RCAI.  As on date, there are eight CAs that are operating under RCAI in India and NICCA is one of them.

Having given you this brief background, I am attaching the file which contains the NICCA trust chain i.e. both the NICCA Certificate and the CCA Root Certificate. 

Best Regards,

Prateek Kr Saha
Chief Operations Manager, NICCA
Attached file NICCA certificate — 
I am attaching both NICCA Certificate and the CCA Root Certificate for the complete trust chain.
Attached file CCA Root Certificate — 
I am attaching both NICCA Certificate and the CCA Root Certificate for the complete trust chain.
It looks like “CCA India 2007” is the root certificate, and “NIC Certifying Authority” is an intermediate CA.
Mozilla only includes root certificates, not intermediate CAs.
An official representative of the organization that operates the CCA root will need to request inclusion of the root.
We have the technical capability to treat any CA certificate as a trust anchor,
whether it's a root or not.  So, in cases where a root does not qualify under
Mozilla's policy, or chooses not to apply, but a subordinate CA does qualify
and does apply, it is feasible for Mozilla to go ahead an approve the cert 
for that subordinate CA to be treated like a root in Mozilla's trusted list.

Now, some policy questions arise when considering such a case.  For example:
1) if a subordinate CA applies for admission to Mozilla's list, and its 
superior root CA does not apply, how long should Mozilla wait before deciding
to go ahead and and grant trust anchor status to the subordinate?  

I suppose these questions are best discussed in the policy discussion group.
We've discussed this in the past and the resolution is exactly as Nelson explained it. Some concerns could be raised, but none apply to this case IIRC. Therefore this request should enter the queue for public discussion after the normal procedures.
The contents of Comment #6 & Comment #7 has to be seen in the Indian context. I would like to point out that in the Indian PKI regime, NICCA is not an intermediate CA or Sub-CA, in the real sense. This is further explained in the  following lines wherein I have tried to present the Indian PKI model. 

Controller of Certifying Authorities (CCA) is the government Licensing and Regulatory Authority, which has been set up under the Information Technology (IT) Act 2000. The IT Act was passed by the Indian Parliament in June 2000 and defines the legal and administrative framework for establishment of a PKI in the country. The  Act requires that for a Digital Signature Certificate to be valid in an Indian court of law, it has to be issued by a Certifying Authority which has been licensed to operate by the CCA. 

CCA has set up the The Root Certifying Authority of India (RCAI), which is at the root of trust in the well established hierarchical PKI system in the country. The CCA issues license to a Certifying Authority only after overseeing and ensuring the compliance of the “Technical Requirements” and  “Operating Standards” under the IT Act 2000, by the participating CA. These standards are at par with the existing international practices and a comparison between the audit program requirements of CCA and WebTrust shows a clear equivalence. As on date, there are eight CAs that are operating under RCAI in India and NICCA is one of them.

So in the Indian PKI hierarchy, CCA operates a root CA, but technically it is a licensing body whose end entity is a CA only. It may please be noted that CCA does not issue certificates to individuals. Only the licensed CAs in India issue certificates to the general public and others, in accordance with the respective CA’s CPS.

The point in Comment #7 for inclusion of CCA’s Certificate is well taken. It may be reiterated here that CCA is a facilitator for the proliferation of PKI technology in India and NICCA would approach CCA in due course with a request for enrolment of CCA’s Certificate in the firefox browser.
It sounds like I should go ahead with processing this request, assuming that it will be OK for the NICCA to be a trust anchor in Mozilla.

CA Hierarchy:
I am not quite clear on the CA-hierarchy below the NICCA. I saw that the NICCA signs a sub-CA for e-passport, but I’m not sure what that is. Does the NICCA sign end-entity certificates directly?  Are there separate sub-CAs for each verification level/class? It looks like the main use of NICCA is to sign sub-CAs for other organizations for their own internal use within the domain for which the sub-CA was created.  My understanding is that all of the sub-CAs under the NICCA are operated by NICCA, and not by any other third party.


Section 7 of http://www.mozilla.org/projects/security/certs/policy/

The Policy Overview section in the CPS describes how the identity of the certificate subscriber is verified depending on the class/assurance level. 
Class 1 Verification Process: Simply Checks for the certainty of the details given in the DSC Request Form as authenticated by Head of Office
Class 2 Verification Process: Checks for the certainty of the details given in the DSC Request Form as authenticated by Head of Applicant’s Organisation, which is further authenticated by HOD/SIO/DIO/ NICCoordinator. Applicant’s Organisation utilizes various procedures to obtain evidence in respect of identity of the applicants by way of documentary evidence of one of the items under point no 8 (Identification details), resulting in stronger assurance level.
Class 3 Verification Process: In addition to the verification process required for the class II certificates, the subscriber’s of class III certificates are required to be personally present with some proof of identity at NICCA/RA, for issuance of DSC.

Email 
For section 7a of the Mozilla CA Policy there also needs to be procedures for verifying that the email address that is to be referenced in the certificate is owned/controlled by the subscriber. I could not find the text in the CPS or DSC Request Form that explains the steps taken to verify that the certificate subscriber owns/controls the email address to be referenced in the certificate.

Domain (SSL)
For section 7b of the Mozilla CA Policy there also needs to be procedures for SSL certs in which it is verified that the domain to be referenced in the certificate is owned/controlled by the certificate subscriber. I could not find any text in the CPS or DSC Request Form that explains the steps taken to verify that the certificate subscriber owns/controls the domain name to be referenced in the certificate.


Potentially Problematic Practices: http://wiki.mozilla.org/CA:Problematic_Practices
Please review the list of potentially problematic practices and identify which ones may be applicable. For those, please provide further information.

Audit
I believe that the auditor requirements documented in the CPS also meet the requirements of the Mozilla CA Policy.
What is the frequency of the audits?
I understand that the audit report itself is not publicly available.
Would it be possible to get a statement from the auditor saying when the last audit was performed and stating that the audit included all of the criteria for WebTrust CA?
1. CA hierarchy

NICCA has only one Sub-CA which is e-passport. Sub-CAs are allowed to be created for different organizations and agencies, for ease of operations and management. However, Sub-CAs are created purely in a technical context, to be part of the NICCA’s technical infrastructure. The keys created for Sub-CA are located only on NICCA’s technical infrastructure. Agencies for whom the Sub-CAs are created, have to be reflected in the corresponding certificate as ‘‘NICCA – Sub-CA for <name of agency for whom Sub-CA has been set up>’’. The public key of the Sub-CA key pair shall be certified by NICCA’s key, which is in turn certified by CCA. The certificate issuing authority for the Sub-CA shall remain only with NICCA.

There are no separate Sub-CAs for individual verification level/class. NICCA issues certificates directly to the users and user systems.

2. E-mail

E-mail verification is done by the way of sending the user-id/password to the end-user to enable the submission of the Certificate Signing Request to NICCA system. This ensures that the person who has requested for the certificate, also has the control over the e-mail mentioned in the request form.

3. Domain (SSL)

The current version of the CPS which is displayed on the website is NICCA CPS ver 4.3. Depending on the requirement, the CPS is revised from time to time and the next NICCA CPS ver 4.4 is due to be published shortly. Domain name verification procedure has been elaborated and clarity to certain other sections/sub-sections of the CPS have been incorporated in the NICCA CPS ver 4.4. However, there is an elaborate procedure for obtaining both internal and external approvals for authorizing the changes in the CPS of CA. The final approved version is expected to be available in about a week’s time and the same shall be put up on the NICCA website.


4. Audit
The audit of NICCA is conducted annually by CCA accredited external auditor. An internal audit is also required to be done every six months. The audit report is not publicly available but a statement from the auditor stating when the last audit was performed and that the audit included all of the criteria for WebTrust CA, can be obtained at short notice, depending upon requirement.

It has been stated in comment No.9 that The CCA issues license to a Certifying Authority only after overseeing and ensuring the compliance of the “Technical Requirements” and  “Operating Standards” under the IT Act 2000, by the participating CA. These standards are at par with the existing international practices and a comparison between the audit program requirements of CCA and WebTrust shows a clear equivalence.
1. CA hierarchy

> NICCA has only one Sub-CA which is e-passport. Sub-CAs are allowed to be
> created for different organizations and agencies, for ease of operations and
> management. 

Would you please provide a CA Hierarchy diagram showing both the current sub-CA and (in general terms) the possible future sub-CAs? This would probably answer my questions most efficiently. Eg: Will NICCA always have only one sub-CA? What does the e-passport sub-CA sign?  Which CA signs end-entity certs?

The SSL cert for the website https://nicca.nic.in looks to be signed directly by the NICCA. So does the NICCA sign end-entity certs directly? 

> However, Sub-CAs are created purely in a technical context, to be
> part of the NICCA’s technical infrastructure. The keys created for Sub-CA are
> located only on NICCA’s technical infrastructure. Agencies for whom the 
> Sub-CAs are created, have to be reflected in the corresponding certificate 
> as ‘‘NICCA – Sub-CA for <name of agency for whom Sub-CA has been set up>’’. 
> The public key of the Sub-CA key pair shall be certified by NICCA’s key, 
> which is in turn certified by CCA. 

So, is the way that the sub-CAs are handled for the NICCA different from typical CA hierarchies?

Also, I have to raise the question again about which CA should be the trust anchor in Mozilla. Should it be the CCA or the NICCA?

> The certificate issuing authority for the Sub-CA shall remain
> only with NICCA.

So when sub-CAs are created for other organizations, the NIC will still do the verification and issuance for the end-entity certs that those sub-CAs sign. Did I understand correctly?

> There are no separate Sub-CAs for individual verification level/class. 

So the class (verification level) of an end-entity cert is determined solely by the Policy OID within the cert?

> NICCA issues certificates directly to the users and user systems.

Again, I think a diagram will be very useful, because I’m confused about the purpose of the e-passport sub-CA, and which CA(s) actually sign end-entity certs.


2. E-mail

> E-mail verification is done by the way of sending the user-id/password to the
> end-user to enable the submission of the Certificate Signing Request to NICCA
> system. This ensures that the person who has requested for the certificate,
> also has the control over the e-mail mentioned in the request form.

Is it done this way for all class/verification levels?  Is this procedure documented in a publicly available and audited document?

3. Domain (SSL)

> The current version of the CPS which is displayed on the website is NICCA CPS
> ver 4.3. Depending on the requirement, the CPS is revised from time to time and
> the next NICCA CPS ver 4.4 is due to be published shortly. Domain name
> verification procedure has been elaborated and clarity to certain other
> sections/sub-sections of the CPS have been incorporated in the NICCA CPS ver
> 4.4. However, there is an elaborate procedure for obtaining both internal and
> external approvals for authorizing the changes in the CPS of CA. The final
> approved version is expected to be available in about a week’s time and the
> same shall be put up on the NICCA website.

My interpretation of the current CPS is that all three of the class/verification levels can be used for issuing SSL certs. Is this correct?

Will the documented procedures for verifying the domain name be specific to class/verification levels? Or will it be the same regardless of class/verification levels?

4. Audit

> The audit report
> is not publicly available but a statement from the auditor stating when the
> last audit was performed and that the audit included all of the criteria for
> WebTrust CA, can be obtained at short notice, depending upon requirement.

Yes, that would be a great help in showing that the audit meets the requirements of the Mozilla CA Policy.
Attached image NICCA Hierarchy — 

    
    

    
  
1. CA hierarchy
   The diagram depicting NICCA hierarchy is attached.

   The SSL cert for the website https://nicca.nic.in looks to be signed  
   directly by the NICCA. So does the NICCA sign end-entity certs directly? –   
   Clarified in the diagram

2. E-mail
   NICCA issues Certificates to the subscribers in the Government, PSUs, 
   Statutory Bodies, and Govt. Registered Companies in India. All details 
   filled by the applicant in the DSC Application form, inclusive of E-mail, 
   are authenticated by the “Head of Office or JS (Admn.) for Government 
   Sector/Superior Authority for Banking Sector of Applicant/ Company Secretary 
   of Govt. Registered Companies, ” before being formally submitted to NICCA 
   for processing. This is given in the “Verification Process” in CPS. The 
   procedure  mentioned in Comment #11 for verification of Emails is documented 
   and internal to NICCA and additionally ensures that the person who has 
   requested for the certificate, also has the control over the e-mail 
   mentioned in the request form.

3. Domain (SSL)
   My interpretation of the current CPS is that all three of the
   class/verification levels can be used for issuing SSL serts. Is        
   this correct? – Yes

   Will the documented procedures for verifying the domain name be  specific to 
   class/verification levels? Or will it be the same  regardless of   
   class/verification levels? – 

   The verification procedure will be specific to class-verification levels and 
   is elaborated in the NICCA CPS ver-4.4, which is expected to be available in 
   about a week’s time.

4. Audit

   We will submit the statement from auditor as soon as the above issues are 
   resolved.

    
    

    
  
Thank you for the updates, I have incorporated them into my local copy of the information gathering document, which I will publish when it is completed -- after the rest of the information has been provided and reviewed: version 4.4 of the CPS and the auditor’s statement.

    
    

    
  
The updated NICCA CPS ver 4.4 is now available at the NICCA website (https: nicca.nic.in) . In this revised edition, Domain name verification procedure has been elaborated. Besides this, clarity to certain sections/sub-sections of the CPS have also been incorporated.

    
    

    
  
Thanks. It looks like the only remaining item is the auditor's statement.

    
    

    
  


  

    
    

    
  
Thank you for providing the auditor’s statement.

The statement is signed by Debopriyo Kar, Head of Information Security Practice of CyberQ Consulting Pvt. Ltd.

The email listed in the auditor’s statement is cyberq@cyberqindia.com.

CyberQ is an accredited auditor as per the India Controller of Certifying Authorities (CCA), http://cca.gov.in/rw/pages/auditors.en.do

When audit reports or statements are provided by the company requesting CA inclusion rather than having an audit report posted on a website such as cert.webtrust.org, the Mozilla process requires doing an independent verification of the authenticity of the audit reports or statements that have been provided.

Is there a direct email address for Mr. Debopriyo Kar at cyberqindia.com?  Or shall I use the cyberq@cyberqindia.com email address.

    
    

    
  


  

    
    

    
  
I have received email from the CCA, stating their intent to apply for inclusion of the CCA root certificate in Mozilla.

Since the NICCA root (the inclusion request in this bug) is signed by the CCA root, I believe that we should proceed with processing the CCA root as the trust anchor.  That would mean that this NICCA root would not be included separately within Mozilla products.

When I process the CCA request, we will have to review all of the sub-CAs, so the information that has been provided in this bug will be used.

    
    

    
  
Before taking any decision to exclude NICCA’s root certificate from the Mozilla Firefox browser, we need to understand the PKI regime that is followed in India, as mentioned in Comment #9 of this bug, wherein it is explained how NICCA is not an intermediate CA or Sub-CA, in the true sense.  

While the requirement of such a root certificate program to include only the Root Certificate as the trust anchor and exclude all other so called intermediate CAs is understandable in a heterogeneous PKI environment, a similar Root Certificate program may not be desirable or relevant, in a country like India,  which has a well established hierarchical PKI regime, with CCA as the apex regulatory body, overseeing and ensuring the compliance of the “Technical Requirements” and  “Operating Standards” under the IT Act 2000, by the CAs under it’s domain. 

It has been pointed out earlier in Comment#7 and Comment#8 that it is technically feasible to include any CA certificate (whether root or not) as trust anchor in Firefox. It is reiterated once again that the Controller of Certifying Authorities (CCA) is the government licensing body and does not issue certificates to any end user. Let it be known and understood that inclusion of only the CCA’s certificate will not benefit even a single end user, when it comes to verification of certificates, thereby defeating the very purpose of inclusion of Root Certificates in Mozilla Firefox.

Similar efforts are also being made with regard to other popular browsers where inclusion of both CCA and NICCA certificates in the same browser is underway. It may please be noted that inclusion of the Root Certificate of only CCA or only NICCA (or  any of the other 7 CAs under CCA’s hierarchy for that matter), will not help the end user for verification of the certificate trust chain in the Indian PKI regime.

In view of above, we therefore urge you to kindly reconsider the matter and include  NICCA’s Certificate in the Mozilla Firefox browser.

    
    

    
  
In accordance with Mozilla's policy, Mozilla should add and trust either 
a) the CCA root but not the NICCA intermediate, or 
b) the NICCA cert (trusted as if it was a root) and not the CCA root.

Assuming that the NIC CA meets all of Mozilla's qualifications, then IMO, the 
decision should be based on whether the CCA's policies suffice to ensure that 
all the subordinate CAs whose certs it issues also meet Mozilla's 
qualifications or not.  

Comment 24 above suggests that the writer believes that distribution of 
intermediate CA certificates with the browser is the only way for them to 
be distributed.  But in fact it is not the normal or expected way for 
intermediate CA certificates to be distributed.  Intermediate CA certificates are expected to be distributed to the certificate subjects (the holders of 
the private keys) together with the subjects' own certificates.  Those subject parties (e.g. SSL servers) are then expected to send out the intermediate CA certificates together with their own certificates whenever they are asked to 
send out their certificates.  That is required by SSL/TLS.
Summary: Add NIC Certifying Authority Root Certificate → Add NIC (India) Root CA Certificate

    
  
Whiteboard: On Hold - Pending decision on CCA vs NICCA as trust anchor

    
  
Blocks: 557167

    
    

    
  
CCA submitted a request for inclusion of the root certificate in bug #557167. Upon reviewing the request I found that the hierarchy is very large: https://bugzilla.mozilla.org/show_bug.cgi?id=557167#c15

The approach that we are going to take with this CA hierarchy is as follows.

1) There will be a separate bug for each of the 7 intermediate CAs to be separately evaluated for inclusion as a trust anchor in NSS. 

2) After all 7 of the intermediate CAs have been approved/included, then
I will proceed with the process of evaluating the CCA root certificate for inclusion in NSS.

3) If the CCA root certificate is approved for inclusion in NSS, then the 7
intermediate CAs will be removed from NSS at the same time that the CCA root is
included.
Whiteboard: On Hold - Pending decision on CCA vs NICCA as trust anchor → Information incomplete

    
    

    
  
Prateek, I have reviewed my notes for this request, and I have a few things to follow up on.

1) I have not yet confirmed the authenticity of the audit statement as per comment #21. I will need to do so. Has there been a more recent audit?

2) In regards to verification of domain name ownership/control, the CPS says "For SSL Certificates, appropriate Domain Registry shall be queried for verification of details." 

Based on prior root inclusion requests I know that this will not be sufficient information. We will need more detail about how the information retrieved from the Domain Registry is used to confirm that the domain name is owned/controlled by the subscriber. This information needs to be in a public and audited document, such as the CPS.

3) The CPS talks about RA's. Section 1.4 says: "These RAs have complete charge of the authentication and validation of each Subscriber within the organization."

Does it mean that RAs can only issue certificates for internal use within their organization?

What controls and auditing are in place to ensure that the RAs are following appropriate procedures?

    
    

    
  
1) I have not yet confirmed the authenticity of the audit statement as per comment #21. I will need to do so. Has there been a more recent audit?

>Yes, conducted from 5th Feb to 22nd Feb, 2010


2) With regard to verification of domain name ownership/control, the CPS says "For SSL Certificates, appropriate Domain Registry shall be queried for verification of details." 

Based on prior root inclusion requests I know that this will not be sufficient information. We will need more detail about how the information retrieved from the Domain Registry is used to confirm that the domain name is owned/controlled by the subscriber. This information needs to be in a public and audited document, such as the CPS.

>The procedure for retrieval of information from Domain registry and its usage >for verification of Domain name owned/controlled by the subscriber is >contained in an Audited document. NICCA adheres to the same for confirmation >of Domain names, wherever applicable.

3) The CPS talks about RA's. Section 1.4 says: "These RAs have complete charge of the authentication and validation of each Subscriber within the organization."

Does it mean that RAs can only issue certificates for internal use within their organization?

>This particular statement is for RAs working for a particular organisation. >It is one of the types of RA, functioning under NICCA, as is evident from the >complete text of Section 1.4 of the CPS.

4)What controls and auditing are in place to ensure that the RAs are following appropriate procedures?

>Proper third party audits of RAs, by CCA accredited Auditors are conducted as >per CCA guidelines.

    
    

    
  
> New Audit -- Yes, conducted from 5th Feb to 22nd Feb, 2010

That's great. Please have the auditor create a new statement to summarize the criteria and findings of the new audit, similar to the previous one:
https://bug511380.bugzilla.mozilla.org/attachment.cgi?id=405987
in order to meet the requirements of sections 8, 9, and 10 of the Mozilla CA Certificate Policy (http://www.mozilla.org/projects/security/certs/policy/)

It would be good if the new statement could also summarize which certificates were included in the audit; e.g. that the audit was in regards to operations of the "NIC Certifying Authority" sub-CA, and also list it's sub-CAs that were included in the audit.


>The procedure for retrieval of information from Domain registry and its usage
>for verification of Domain name owned/controlled by the subscriber is
>contained in an Audited document. NICCA adheres to the same for confirmation
>of Domain names, wherever applicable.

Please provide the url and section number where I can find this text that describes the main steps that are taken to verify that the certificate subscriber owns/controls the domain name to be included in the certificate.

https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership


> RAs -- Proper third party audits of RAs, by CCA accredited Auditors 
> are conducted as per CCA guidelines.

Good. Is that part of the audit that was conducted from 5th Feb to 22nd Feb, 2010? If so, can the auditor also make a statement that the RA practices have also been audited?

    
    

    
  
1) Please have the auditor create a new statement to summarize the criteria and findings of the new audit, similar to the previous one:
https://bug511380.bugzilla.mozilla.org/attachment.cgi?id=405987
in order to meet the requirements of sections 8, 9, and 10 of the Mozilla CA Certificate Policy.

> The last Annual Audit of NICCA was conducted from 5th Feb to 22nd Feb, 2010. Scanned copy of the latest Audit Equivalency Certificate from CCA accredited third party auditor - M/s CyberQ Consultants Pvt. Ltd. is uploaded for your ready referencel.

2) It would be good if the new statement could also summarize which certificates were included in the audit; e.g. that the audit was in regards to operations of the "NIC Certifying Authority" sub-CA, and also list it's sub-CAs that were included in the audit.

> Included in the statement of the latest Audit Equivalency Certificate.

3) Please provide the url and section number where I can find this text that describes the main steps that are taken to verify that the certificate subscriber owns/controls the domain name to be included in the certificate. 

> The procedure for retrieval of information from Domain registry and its usage for verification of Domain name owned/controlled by the subscriber is contained in an Audited document under General Section category of NICCA Documentation. NICCA adheres to the same for confirmation of Domain names wherever applicable. The text of this document inter-alia includes the following : 

The SSL Certificate is issued after properly verifying the Domain Name. The applicant is required to send a physical copy of DSC Application form with full details of the Custodian of the Server, Department to which the server belongs, Ministry, Official address and Contact Number etc. In the Application form, the Server related details viz. IP Address, URL/Domain name and Physical Location of the Server etc. are also furnished. Before issuing SSL certificate, NICCA ensures the correctness of the furnished information by making NSLOOKUP query /  WHOIS Lookup query as applicable, and in case of any doubt, communicating with the  applicant and resolving the matter over phone, email or personal interaction.


4) Good. Is that part of the audit that was conducted from 5th Feb to 22nd Feb, 2010? If so, can the auditor also make a statement that the RA practices have also been audited?

> Included in the statement of the latest Audit Equivalency Certificate. As per CCA guidelines, RAs are audited along with the Annual CA audit on a sample basis with the stipulation that any new RA has to be compulsorily audited.

    
    

    
  
As per Mozilla practice, I have sent email to the auditor to confirm the authenticity of the audit statement that has been attached to this bug.

> The procedure for retrieval of information from Domain registry and its usage 
> for verification of Domain name owned/controlled by the subscriber is 
> contained in an Audited document under General Section category of NICCA 
> Documentation. NICCA adheres to the same for confirmation of Domain names 
> wherever applicable. The text of this document inter-alia includes the 
> following

Please provide the url to this particular document.

    
    

    
  
I have exchanged email with a representative of CyberQ Consulting Pvt. Ltd., who has confirmed the authenticity of the Audit Equivalency Certificate that was attached in Comment #30.

    
  
Whiteboard: Information incomplete → Information confirmed complete

    
    

    
  
This request is near the top of the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

I will post a comment in this bug when I begin the discussion.

    
    

    
  
I am now opening the first public discussion period for this request from National Informatics Centre (NIC) to add the “NIC Certifying Authority” root certificate and enable all three trust bits.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

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

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-security-policy
news://news.mozilla.org/mozilla.dev.security.policy

The discussion thread is called “NIC Root Inclusion Request”

Please actively review, respond, and contribute to the discussion.

A representative of NIC must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: Information confirmed complete → In public discussion

    
    

    
  
> A representative of NIC must promptly respond directly in the discussion 
> thread to all questions that are posted.

Two questions have been posted for a few days now. A representative of this CA must post a response to the questions in the discussion ASAP.

    
    

    
  
The first round of discussion about this request from National Informatics Centre (NIC) to add the “NIC Certifying Authority” root certificate and enable all three trust bits has been closed.

The discussion resulted in action items for NIC to update their CPS as follows.

1) Add text to Section 3.1.6, Authentication of Organization Identity, to describe the minimum steps that the RA must take to perform this authentication. If this information is already provided in another document (e.g. from CCA), then please directly reference that information in this section, so that it is clear the steps that must be followed.

2) Add text to describe the minimum steps that must be taken to verify that the certificate subscriber owns/controls the domain name to be included in the certificate. When the domain name is already registered with NIC, how does the RA use the information from the NIC database to confirm that the information provided by the subscriber is accurate and that the subscriber owns/controls that domain name? When whois is used, what information is used from whois, and how is that information used to confirm that the subscriber owns/controls that domain name?

3) Add text to section 6.1.2 in regards to “NICCA itself does not generate Private Key for the end users. We send crypto device having no keys on it, which carries users personal information printed on it. End users generate their own keys at their place. In case user find some problem, they can visit NICCA office for generating their key pairs. … End users with the help of web interface logins to NICCA site and generate key pairs on the crypto device at their place.”

4) Update section 4.4.1 to be more in line with the Mozilla CA Certificate Policy in regards to revocation. According to section 2 of http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html
there are certain circumstances where the CA must revoke a certificate. The CPS language should reflect that the CA is required to revoke in the listed circumstances (rather than at the CA's discretion).

Please add a comment to this bug when the CPS has been updated. Then I will confirm the completion of these action items, and start a second round of discussion in mozilla.dev.security.policy.

Thanks,
Kathleen
Whiteboard: In public discussion → Public Discussion Action Items - Update CPS

    
    

    
  
NICCA has published CPS Addendum dated 10 Jan 2013 under repository Certficate Practice Statement as shown below.

"CPS Addendum dated 10 Jan 2013 for enrolling Root Certificate under MOZILLA [.pdf]" 


Manoj Kumar Kulshreshth
Chief Operations Manager, NICCA

    
    

    
  
I apologize for the delay in my response. My work on root inclusion requests was postponed for a while.

I will have to review and update my notes on this request. I have added this to my to-do list.

In the meantime, please respond to the recent CA Communication.
https://wiki.mozilla.org/CA:Communications#January_10.2C_2013

    
    

    
  


  
Attached are my current notes on this request. The items highlighted in yellow indicate where further information or clarification is needed.

Please also add a comment to this bug to indicate NIC CA's response to the recent CA Communication: https://wiki.mozilla.org/CA:Communications#January_10.2C_2013

    
    

    
  
In light of the recent misissued certificates issued by this organization (http://googleonlinesecurity.blogspot.com/2014/07/maintaining-digital-certificate-security.html) it should be clear that this request must be rejected and this organization permanently barred from root inclusion.

    
    

    
  
From the inactivity here, it seems like NIC India are not currently interested in pursuing this application. But if it is revived, then the incident you note, and NIC India's reactions to it and the level of transparency they display in the days afterwards, will certainly be a topic of conversation.

Gerv

    
    

    
  
http://googleonlinesecurity.blogspot.com/2014/07/maintaining-digital-certificate-security.html
"The intermediate CA certificates held by NIC were revoked on July 3"

So I think it's safe to assume that this particular inclusion request may be closed.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX

    
  
Product: mozilla.org → NSS

    
    

    
  
Can the process of adding the Indian CA be reinitiated and the Indian CA be part of the Trust Root?


In India as per the Legislation, only Indian CA is valid and they do not recognize Foreign CA.


Product: NSS → CA Program

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: