562764 - Add IDRBT root certificate

Status: RESOLVED WONTFIX

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

Description

[Kathleen Wilson]

IDRBT (http://idrbtca.org.in/)
http://cca.gov.in/rw/pages/licensed_ca_idrbt.en.do
Organization Type: Bank/Semi-Government
Customer Base: Banks
CPS: http://idrbtca.org.in/Download/IDRBT-CPS-v3.1.pdf
Details: https://bugzilla.mozilla.org/attachment.cgi?id=436980

This is a sub-CA of the India CCA root certificate. 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.

Comment 1

[Kathleen Wilson]

Beginning Information Gathering and Verification:
https://wiki.mozilla.org/CA:How_to_apply#Information_gathering_and_verification

Comment 2

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

The attached document summarizes the information that has been gathered and
verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.

Comment 3

[Ramachandran]

Attachment: Letter from Auditor

A letter from Auditor is  attached

Comment 4

[Ramachandran]

Attachment: Screen shots of security certificate

A screen shot of  security certificate is attached

Comment 5

[Ramachandran]

1. Test Website: Invalid Security Certificate
CA E-mail address Alias:  [e-mail]
https://services.idrbtca.org.in
The digital certificate has been issued to services.idrbtca.org.in as per the screen shot enclosed. 

2. CRL URL :  http://idrbtca.org.in/crl.crl
CRL Issuance frequency for end-entity certificates is available in Section 4.6.9 of CPS V 3.1 

(http://idrbtca.org.in/Downloads/IDRBT CA CPS-v3.1)
OCSP Responder URL :  None;  OCSP is currently not provided

3.Audit:  Scanned copy of the Letter from the External Auditor (CCA Approved auditor) is enclosed for reference.

4. Domain Name ownership/control
The official authorized by the organization to apply for SSL Certificate should enclose the proof of registration of domain 

name along with the application form in order to get a digital certificate for the domain name. 

5. E-mail address ownership/control
E-mail verification is done by sending user id and password across e-mail to the end-user to enable submission of Digital 

certificate Request to IDRBT.  This ensures that the official who has requested for digital certificate also has the 

ownership/control over the e-mail address.
Subscribers are personally and solely responsible for the confidentiality and integrity of their private keys.  

 
6. Potentially problematic practices
Distribution of generated private keys in PKCS#12 files
The file containing the private key, public key and the digital certificate can be downloaded by logging in to the Secured 

site of IDRBT using the user id and password provided to the end-entity.  The file is also protected by a password.  

7. Issuing SSL Certificates for internal domains:
SSL Certificates have NOT been issued for internal domains SO FAR.  
OCSP Responses signed by a certificate under a different root 
Not applicable.  OCSP currently not provided. 
CRL with critical CIDP Extension
CRL is a full CRL and there is/are no partitioned CRL(s) that is/are identified by the presence of a CRL Issuing Distribution 

Point (CIDP) Extension flagged as critical.

Comment 6

[Kathleen Wilson]

When I try to browse to https://services.idrbtca.org.in in my Firefox browser (IDRBT CA has been imported into my browser), I get the error:

services.idrbtca.org.in uses an invalid security certificate.
The certificate is only valid for 10.0.65.60
(Error code: ssl_error_bad_cert_domain)

When I inspect the cert I don't see a “Certificate Subject Alt Name” Extension. Firefox expects to find all DNS names in the SAN. Perhaps this is the problem. Have you tested this in a Firefox browser?

Comment 7

[Ramachandran]

Now IDRBT has changed their  certificate  and  https://services.idrbtca.org.in  is accessible.

Comment 8

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

The attached document summarizes the information that has been gathered and
verified.

The items highlighted in yellow indicate where further information or
clarification is still needed.

Comment 9

[Prianceu Pandey]

Attachment: Updated CPS of IDBRT

IDBRT has updated its CPS to suit Mozilla's requirements.
The updated CPS is being attached.

Prianceu Pandey

Comment 10

[Prianceu Pandey]

Attachment: Comments from IDBRT

The comments/responses from IDBRT on potentially problematic practices is being attached.

-Prianceu Pandey

Comment 11

[Kathleen Wilson]

I was trying to work on this today, but I can't seem to connect to the IDRBT website, because the connection attempt keeps timing out.

Are the following URLs still correct?
IDRBT Repository: https://services.idrbtca.org.in/
IDRBT CPS (English): http://idrbtca.org.in/CPS.html 
Test website: https://services.idrbtca.org.in/

Please add a comment in this bug to provide IDRBT's answers to the action items listed in Mozilla's January CA Communication:
https://wiki.mozilla.org/CA:Communications#January_10.2C_2013

In regards to the attachment in Comment #10, there are a few items that said: "Recommend modification in the CPS..." 
Does that mean that I should be able to find those updates in the current CPS on your website?

Comment 12

[Prianceu Pandey]

The website is currently accessible at my place. Please let us know in case you face any problems.

Yes, the modified CPS (ver 3.2) is available on IDBRT's website.

PS: I donot represent IDBRT , but I work for the Office of Controller of Certifying Authorities(CCA) , India . Someone from IDBRT will respond shortly to further queries here.

Thanks and Regards,

Prianceu Pandey.

Comment 13

[Kathleen Wilson]

I just tried again.

Connection timed out for
IDRBT Repository: https://services.idrbtca.org.in/
Test website: https://services.idrbtca.org.in/

I was able to connect to
IDRBT CPS (English): http://idrbtca.org.in/CPS.html 
And download CPS version 3.2.

Comment 14

[Sudhir Kumar Jha]

Dear Sir/Madam,

The https://services.idrbtca.org.in will be accessiable soon.Shortly the same will be updated here.

(In reply to Kathleen Wilson from comment #6)
> When I try to browse to https://services.idrbtca.org.in in my Firefox
> browser (IDRBT CA has been imported into my browser), I get the error:
> 
> services.idrbtca.org.in uses an invalid security certificate.
> The certificate is only valid for 10.0.65.60
> (Error code: ssl_error_bad_cert_domain)
> 
> When I inspect the cert I don't see a “Certificate Subject Alt Name”
> Extension. Firefox expects to find all DNS names in the SAN. Perhaps this is
> the problem. Have you tested this in a Firefox browser?

Comment 15

[Sudhir Kumar Jha]

https://services.idrbtca.org.in is accessiable now. Kindly check and do let me know if this not reachable. 

For your information- I am from IDRBT CA,please drop me mail on([e-mail] or [e-mail]) or update this ticket for any assistance from IDRBT CA side.

Comment 16

[Kathleen Wilson]

(In reply to Sudhir Kumar Jha from comment #15)
> https://services.idrbtca.org.in is accessiable now. Kindly check and do let
> me know if this not reachable. 

Now I get a much quicker response, but I get the error:
"The certificate is not trusted because no issuer chain was provided."

https://wiki.mozilla.org/CA:Information_checklist#Technical_information_about_each_root_certificate
"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.
Certificate authorities MUST advise their subscribers that all intermediate certificates should be installed in the servers containing the dependent subscriber certificates."

Comment 17

[Sudhir Kumar Jha]

The certificate with complete chain has been deployed over https://services.idrbtca.org.in  . 

Kindly check and confirm the same.Do let me know if issue persist anymore.

Comment 18

[Sudhir Kumar Jha]

The certificate with complete chain has been deployed over https://services.idrbtca.org.in  . 

Kindly check and confirm the same.Do let me know if issue persist anymore.

Comment 19

[Kathleen Wilson]

My current notes indicate that this inclusion request is for the 2007 cert:
http://idrbtca.org.in/Download/IDRBTCA2007.cer

Should I change my notes to have this inclusion request be for the 2011 cert instead?
http://idrbtca.org.in/Download/CA_Certificate_SHA2.cer

Comment 20

[Sudhir Kumar Jha]

Yes you can.
http://idrbtca.org.in/Download/CA_Certificate_SHA2.cer will be the right one for inclusion.

Comment 21

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

The items highlighted in yellow indicate where further information is needed. Primarily: current audit statement, compliance with the Baseline Requirements, OCSP, and response to the recent CA Communication.

Comment 22

[Sudhir Kumar Jha]

Reply for attachment 750128 [details](attach the document with sticky note on Yellow marked item)
CRL: As per the latest IDRBT CA CPS-v3.2 --
The IDRBT CA shall update and issue the CRL whenever certificates are revoked or suspended or on the first working day of each month or 30 days after the last update or as and when necessary, whichever occurs first as per CCA guidelines But IDRBT CA will make every effort to publish new CRL in every last working day of the week.

OCSP:We don't have any OSCP in place. We use CRL. (Clarrification: Do we need to have this to have our certificate incorporated in Mozilla browser ?)

Comments in line for compliance with the Baseline Requirements mentioned in https://wiki.mozilla.org/CA:Communications#January_10.2C_2013

1.Review the proposed changes to Mozilla’s CA Certificate Policy, and assess the impact of those changes to your CA operations
 CA Stand: a) The proposed updates to Mozilla’s CA Certificate Policy do not require further change to our CA operations, because our CA operations already comply with the proposed policy.

2) Confirm compliance with the CA/Browser Forum’s Baseline Requirements. 
CA Stand: a) Our CA operations conform to the CA/Browser Forum’s Baseline Requirements for issuance of SSL certificates, and our next audit will include verification of this conformance.


3)Scan your certificate database for certificates that incorrectly have basicConstraints with the cA boolean set to true, or are incorrectly enabled with the keyCertSign Key Usage bit. 

CA Stand: what you mean by cA boolean set to true in terms of x509.v3 certificate.Please elobrate this.(indeed by reading the https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates/ seems not applicable to IDRBT CA ).

4) Deprecate issuance of SSL certificates containing a Reserved IP Address or Internal Server Name

IDRBT CA Stand: We don't have any such occurrence in past as well as present for issuance of SSL certificate for Reserved IP address but we issuse over Internal Server name(excluding domain names with extension .int).

5) For each root certificate or trust anchor you control that is included in Mozilla’s CA Certificate Program and has the SSL trust bit enabled by default, please provide a URL to a website (which may be a test site) whose SSL certificate chains up to it

IDRBT CA Stand: As per the  guidlines stipulated by the Office of the Controller of Certifying Authorities, New Delhi, issuance of SHA1 certificates has been stopped with effect form 1st Jan 2012. The use of SHA2 SSL certificate for protecting the web sites leads to download compatibility issues with older OS used by clients.

Audit Statment for year 2013 will be uploaded Shortly.

Comment 23

[Kathleen Wilson]

(In reply to Sudhir Kumar Jha from comment #22)

Please carefully review the CA/Browser Forum's Baseline Requirements (BR) document, which is available here: https://www.cabforum.org/documents.html
Enablement of the websites (SSL/TLS) trust bit for a root certificate in Mozilla's program requires compliance with the BRs.

> CRL

BR #13.2.2: If 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*

Also, please let CCA know that their CRL does not import correctly into Firefox.
http://cca.gov.in/rw/resources/CCAIndia2011Latest.crl  -- Error: Code:ffffe009
ffffe009 is equivalent to -8183, “Security library: improperly formatted DER-encoded message.”
It means that the reply contained anything other than a valid DER-encoded CRL.
Typical Resolution: Change encoding from PEM to DER.


> 
> OCSP:We don't have any OSCP in place. We use CRL. (Clarrification: Do we
> need to have this to have our certificate incorporated in Mozilla browser ?)

Yes.
BR #13.2.2: The CA SHALL update information provided via an Online Certificate Status Protocol at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days ... Effective 1 January 2013, the CA SHALL support an OCSP capability using the GET method for Certificates issued
in accordance with these Requirements.


> 3)Scan your certificate database for certificates that incorrectly have
> basicConstraints with the cA boolean set to true, or are incorrectly enabled
> with the keyCertSign Key Usage bit. 
> 
> CA Stand: what you mean by cA boolean set to true in terms of x509.v3
> certificate.Please elobrate this.(indeed by reading the
> https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-
> certficates/ seems not applicable to IDRBT CA ).

While I agree that the part about subCA certs doesn't apply to IDRBT, please see the rest of #3: 
While you are scanning your certificate databases ... please also check for compliance with the following practices.
- All certificates with basicConstraints:CA:TRUE have the basicConstraints marked critical.
- All intermediate certificates with basicConstraints:CA:TRUE have cRLDistributionPoints containing a well-formed and compliant URL that returns a valid CRL.
- All certificates that share a common issuer name contain unique serial numbers (independent of certificate expiration).
- All end-entity certificates with RSA key sizes smaller than 2048 bits expire no later than December 2013.
- Certificates are not issued with sequential serial numbers. If it is found that certificates have been issued with contiguous serial numbers, then the subject of those certificates must contain unpredictable data that is not under the control of the certificate subscriber. 


Thanks,
Kathleen

Comment 24

[Kathleen Wilson]

As per information provided by CCA India, there is a new CA hierarchy and inclusion of certificates in the old CA hierarchy is no longer requested.