Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Disig Request to include Renewed Roots
222 views
Skip to first unread message
Kathleen Wilson
Nov 14, 2012, 6:25:47 PM11/14/12
to mozilla-dev-s...@lists.mozilla.org
Disig has applied to include the “CA Disig Root R1” root certificate
that will eventually replace the “CA Disig” root certificate that is
currently included in Mozilla products (Bugzilla #455878). This request
is to also include the “CA Disig Root R2” SHA-256 root certificate. All
three trust bits are requested for both certs, and EV is not requested
at this time.
Disig is a private corporation located in Slovakia. Disig provides
certification service mainly for Slovakian market, issuing certificates
to general public, private companies, and government organizations.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=792377
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Disig
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=672565
Noteworthy points:
* The primary documents are the CP and CPS, which are translated into
English.
CP (Slovak): http://www.disig.sk/_pdf/cp-disig.pdf
CP (English): http://www.disig.eu/_pdf/cp-cadisig-eng.pdf
CPS (Slovak): http://www.disig.sk/_pdf/cps_ra_cadisig.pdf
CPS (English): http://www.disig.eu/_pdf/cps_ra_cadisig_eng.pdf
Both the “CA Disig Root R1” and “CA Disig Root R2” root certificates
will sign internally-operated intermediate certificates that will sign
entity certificates for SSL, digital signature, sending/receiving
e-mail, and code signing.
This request is to enable all three trust bits for both of the new root
certificates.
* CP section 3.1.9: CMA (Certificate Management Authority) has to
guarantee that the certificate issued for hardware or software component
(code signing) that is able to use the certificate, that the component
identity and the public key are bonded together.
For this reason the component has to be assigned to a specific person or
to a person that is authorized to deal on behalf of a company that is
administrating the component. (see section 5.2).
Person is obliged to provide following information to CMA, as described
in sections 3.1.10 and 5.2:
- identification of component (name for software component),
- public key of the component (part of certificate request),
- authorization of component and its characteristics (URL and
application description for software component),
- contact information, that CMA may, if necessary, to communicate with
this person,
CMA will be verify the accuracy of any authorization (values of
distinguishing name) to be listed in the certificate and verify the data
submitted. Methods to implement this authentication and control data
include:
- verify the identity of the person in accordance with the requirements
of section 3.1.8,
- verify the identity of the organization, which includes the component,
in accordance with the requirements of section 3.1.7,
- verify the competency of using data to be introduced in individual
items of the certificate, with an emphasis on CommonName. (Note: The
typical value of this item will be fully registered domain name.)
In the case of using the domain name is the condition that the second
level domain is owned by an entity which is an applicant for a
certificate for the server. Subject has to demonstrate to RA operator
that it is the holder of the domain for which calls for issuance of the
certificate.
The existence of a domain and its owner has been verified through WHOIS
services provided by the web top level domain sponsoring
organization(e.g. for domain ".sk" is the sponsoring organization SK-NIC
- www.sk-nic.sk; for domain ".eu" is the sponsoring organization EURid
vzw/asbl established in Belgium for the domain ".com" is sponsoring
organization VeriSign Global Registry Services based in the U.S.).
Full domain name will be verified by sending an e-mail which will
contain secret information to some unforeseeable e-mail accounts for the
domain listed in the record obtained from the WHOIS service respectively
on the e-mail from that domain for these possible accounts: admin,
administrator, webmaster, hostmaster or postmaster.
An applicant for a certificate for the domain shall send back
verification information as proof of ownership of the domain within
specified period of time.
If from the data obtained from the above sources is not possible to
reliably determine that the applicant is the owner of the domain or
person acting on behalf of the owner of the domain, CA Disig refuses to
issue a certificate to that request.
Registration Authority verifies a written confirmation from independent
sources on the Internet such as www.sk-nic.sk for SK domain respectively
www.eurid.eu for EU domain, etc.
In the case of registered IP addresses RA will not investigate whether
the body - the applicant for a certificate for the server uses the
registered IP address legitimately e.g. whether the registered IP
address is the address segment, which is registered in the RIPE
organization for the entity - the applicant for a certificate for the
server. In this case, is automatically assumed that that subject - the
applicant for a certificate for the server use in the application for
the certificate registered IP address and applicant gave to CA Disig a
solemn declaration that the IP address used lawfully and that he is
aware of all the consequences and responsibility for any unauthorized
use of the IP address.
The CA Disig implements a process that prevents an OU attribute from
including a name, DBA, tradename, trademark, address, location, or other
text that refers to a specific natural person or Legal Entity unless the
CA Disig has verified this information.
* CP section 4.1.2:
9. In connection with the verification of an e-mail address in the
request for certificate which is used to sign electronic messages
(extension "Secure Email (1.3.6.1.5.5.7.3.4)") perform RA worker
verification checks of e-mail addresses in the certificate request, via
the responds to the e-mail, from which request was send. Verification is
carried out so that to the e-mail address is sending a mail message
containing secret unpredictable information (authentication
information). An applicant for a certificate shall send back to the CA
Disig verification information as evidence of control of the e-mail
addresses. In case that the verification of e-mail address runs
unsuccessfully, CA Disig refuses to issue the certificate. If the
certificate request for issuing subsequent certificate is sent via
e-mail and that e-mail is signed with the valid electronic signature and
certificate was issued by CA Disig and e-mail in the request is
identical with the sender e-mail, verifying od e-mail address is not
required.
* CPS section 4.1.1.3:
2. In the case when certificate request sent in advance contains the
same e- mail address as from which it was sent, the RA staff shall
verify validity of this e-mail address. . Verification is carried out so
that to the e-mail address is sending a mail message containing secret
unpredictable information (authentication information). An applicant for
a certificate shall send back to the CA Disig verification information
as evidence of control of the e-mail addresses. The answer shall be send
within a specified period of time sufficient for sending email. In case
that the verification of e-mail address runs unsuccessfully, CA Disig
refuses to issue the certificate. Detailed procedure is described in the
RA working manuals and is also subject to the initial training of RA staff.
* Root Cert URLs
http://www.disig.sk/rootcar1/cert/rootcar1.der
http://www.disig.sk/rootcar2/cert/rootcar2.der
* Test Websites
https://testssl-valid-r1i1.disig.sk
https://testssl-valid-r2i1.disig.sk
* CRL
http://www.disig.sk/rootcar1/crl/rootcar1.crl
http://www.disig.sk/subcar1i1/crl/subcar1i1.crl
http://www.disig.sk/rootcar2/crl/rootcar2.crl
http://www.disig.sk/subcar2i1/crl/subcar2i1.crl
CP section 4.4.3: immediate upon revocation, otherwise every 24 hours
* OCSP:
http://rootcar1-ocsp.disig.sk/ocsp/rootcar1
http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1
http://rootcar2-ocsp.disig.sk/ocsp/rootcar2
http://subcar2i1-ocsp.disig.sk/ocsp/subcar2i1
* Audit: Disig is audited according to the ETSI 102 042 criteria, and
the audit conclusion and ETSI certificate are provided on Disig’s website.
http://www.disig.sk/_pdf/Audit_Statement_2011_CA_Disig.pdf
I confirmed the authenticity of the document by exchanging email with
the auditor who is listed on the ISACA website,
http://www.isaca.sk/priprava-na-certifikaty/zoznam-drzitelov-certifikatov/
* Potentially Problematic Practices – None noted
(http://wiki.mozilla.org/CA:Problematic_Practices)
This begins the discussion of the request from Disig to add the “CA
Disig Root R1” and “CA Disig Root R2” root certificates and enable all
three trust bits for both certs. At the conclusion of this discussion I
will provide a summary of issues noted and action items. If there are
outstanding issues, then an additional discussion may be needed as
follow-up. If there are no outstanding issues, then I will recommend
approval of this request in the bug.
Kathleen
that will eventually replace the “CA Disig” root certificate that is
currently included in Mozilla products (Bugzilla #455878). This request
is to also include the “CA Disig Root R2” SHA-256 root certificate. All
three trust bits are requested for both certs, and EV is not requested
at this time.
Disig is a private corporation located in Slovakia. Disig provides
certification service mainly for Slovakian market, issuing certificates
to general public, private companies, and government organizations.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=792377
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Disig
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=672565
Noteworthy points:
* The primary documents are the CP and CPS, which are translated into
English.
CP (Slovak): http://www.disig.sk/_pdf/cp-disig.pdf
CP (English): http://www.disig.eu/_pdf/cp-cadisig-eng.pdf
CPS (Slovak): http://www.disig.sk/_pdf/cps_ra_cadisig.pdf
CPS (English): http://www.disig.eu/_pdf/cps_ra_cadisig_eng.pdf
Both the “CA Disig Root R1” and “CA Disig Root R2” root certificates
will sign internally-operated intermediate certificates that will sign
entity certificates for SSL, digital signature, sending/receiving
e-mail, and code signing.
This request is to enable all three trust bits for both of the new root
certificates.
* CP section 3.1.9: CMA (Certificate Management Authority) has to
guarantee that the certificate issued for hardware or software component
(code signing) that is able to use the certificate, that the component
identity and the public key are bonded together.
For this reason the component has to be assigned to a specific person or
to a person that is authorized to deal on behalf of a company that is
administrating the component. (see section 5.2).
Person is obliged to provide following information to CMA, as described
in sections 3.1.10 and 5.2:
- identification of component (name for software component),
- public key of the component (part of certificate request),
- authorization of component and its characteristics (URL and
application description for software component),
- contact information, that CMA may, if necessary, to communicate with
this person,
CMA will be verify the accuracy of any authorization (values of
distinguishing name) to be listed in the certificate and verify the data
submitted. Methods to implement this authentication and control data
include:
- verify the identity of the person in accordance with the requirements
of section 3.1.8,
- verify the identity of the organization, which includes the component,
in accordance with the requirements of section 3.1.7,
- verify the competency of using data to be introduced in individual
items of the certificate, with an emphasis on CommonName. (Note: The
typical value of this item will be fully registered domain name.)
In the case of using the domain name is the condition that the second
level domain is owned by an entity which is an applicant for a
certificate for the server. Subject has to demonstrate to RA operator
that it is the holder of the domain for which calls for issuance of the
certificate.
The existence of a domain and its owner has been verified through WHOIS
services provided by the web top level domain sponsoring
organization(e.g. for domain ".sk" is the sponsoring organization SK-NIC
- www.sk-nic.sk; for domain ".eu" is the sponsoring organization EURid
vzw/asbl established in Belgium for the domain ".com" is sponsoring
organization VeriSign Global Registry Services based in the U.S.).
Full domain name will be verified by sending an e-mail which will
contain secret information to some unforeseeable e-mail accounts for the
domain listed in the record obtained from the WHOIS service respectively
on the e-mail from that domain for these possible accounts: admin,
administrator, webmaster, hostmaster or postmaster.
An applicant for a certificate for the domain shall send back
verification information as proof of ownership of the domain within
specified period of time.
If from the data obtained from the above sources is not possible to
reliably determine that the applicant is the owner of the domain or
person acting on behalf of the owner of the domain, CA Disig refuses to
issue a certificate to that request.
Registration Authority verifies a written confirmation from independent
sources on the Internet such as www.sk-nic.sk for SK domain respectively
www.eurid.eu for EU domain, etc.
In the case of registered IP addresses RA will not investigate whether
the body - the applicant for a certificate for the server uses the
registered IP address legitimately e.g. whether the registered IP
address is the address segment, which is registered in the RIPE
organization for the entity - the applicant for a certificate for the
server. In this case, is automatically assumed that that subject - the
applicant for a certificate for the server use in the application for
the certificate registered IP address and applicant gave to CA Disig a
solemn declaration that the IP address used lawfully and that he is
aware of all the consequences and responsibility for any unauthorized
use of the IP address.
The CA Disig implements a process that prevents an OU attribute from
including a name, DBA, tradename, trademark, address, location, or other
text that refers to a specific natural person or Legal Entity unless the
CA Disig has verified this information.
* CP section 4.1.2:
9. In connection with the verification of an e-mail address in the
request for certificate which is used to sign electronic messages
(extension "Secure Email (1.3.6.1.5.5.7.3.4)") perform RA worker
verification checks of e-mail addresses in the certificate request, via
the responds to the e-mail, from which request was send. Verification is
carried out so that to the e-mail address is sending a mail message
containing secret unpredictable information (authentication
information). An applicant for a certificate shall send back to the CA
Disig verification information as evidence of control of the e-mail
addresses. In case that the verification of e-mail address runs
unsuccessfully, CA Disig refuses to issue the certificate. If the
certificate request for issuing subsequent certificate is sent via
e-mail and that e-mail is signed with the valid electronic signature and
certificate was issued by CA Disig and e-mail in the request is
identical with the sender e-mail, verifying od e-mail address is not
required.
* CPS section 4.1.1.3:
2. In the case when certificate request sent in advance contains the
same e- mail address as from which it was sent, the RA staff shall
verify validity of this e-mail address. . Verification is carried out so
that to the e-mail address is sending a mail message containing secret
unpredictable information (authentication information). An applicant for
a certificate shall send back to the CA Disig verification information
as evidence of control of the e-mail addresses. The answer shall be send
within a specified period of time sufficient for sending email. In case
that the verification of e-mail address runs unsuccessfully, CA Disig
refuses to issue the certificate. Detailed procedure is described in the
RA working manuals and is also subject to the initial training of RA staff.
* Root Cert URLs
http://www.disig.sk/rootcar1/cert/rootcar1.der
http://www.disig.sk/rootcar2/cert/rootcar2.der
* Test Websites
https://testssl-valid-r1i1.disig.sk
https://testssl-valid-r2i1.disig.sk
* CRL
http://www.disig.sk/rootcar1/crl/rootcar1.crl
http://www.disig.sk/subcar1i1/crl/subcar1i1.crl
http://www.disig.sk/rootcar2/crl/rootcar2.crl
http://www.disig.sk/subcar2i1/crl/subcar2i1.crl
CP section 4.4.3: immediate upon revocation, otherwise every 24 hours
* OCSP:
http://rootcar1-ocsp.disig.sk/ocsp/rootcar1
http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1
http://rootcar2-ocsp.disig.sk/ocsp/rootcar2
http://subcar2i1-ocsp.disig.sk/ocsp/subcar2i1
* Audit: Disig is audited according to the ETSI 102 042 criteria, and
the audit conclusion and ETSI certificate are provided on Disig’s website.
http://www.disig.sk/_pdf/Audit_Statement_2011_CA_Disig.pdf
I confirmed the authenticity of the document by exchanging email with
the auditor who is listed on the ISACA website,
http://www.isaca.sk/priprava-na-certifikaty/zoznam-drzitelov-certifikatov/
* Potentially Problematic Practices – None noted
(http://wiki.mozilla.org/CA:Problematic_Practices)
This begins the discussion of the request from Disig to add the “CA
Disig Root R1” and “CA Disig Root R2” root certificates and enable all
three trust bits for both certs. At the conclusion of this discussion I
will provide a summary of issues noted and action items. If there are
outstanding issues, then an additional discussion may be needed as
follow-up. If there are no outstanding issues, then I will recommend
approval of this request in the bug.
Kathleen
Erwann Abalea
Nov 16, 2012, 11:19:10 AM11/16/12
to mozilla-dev-s...@lists.mozilla.org
Bonjour,
Le jeudi 15 novembre 2012 00:25:55 UTC+1, Kathleen Wilson a écrit :
> * Test Websites
> https://testssl-valid-r1i1.disig.sk
> https://testssl-valid-r2i1.disig.sk
Non-blocking: the AIA:caIssuer point to a properly formatted object, with a wrong MIME-type (application/octet-stream instead of application/pkix-cert).
Non-blocking: the certificatePolicies chaining results in an empty policy set when validating the EE certificates.
> * OCSP:
> http://rootcar1-ocsp.disig.sk/ocsp/rootcar1
> http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1
> http://rootcar2-ocsp.disig.sk/ocsp/rootcar2
> http://subcar2i1-ocsp.disig.sk/ocsp/subcar2i1
Since you're using a CABForum OID in your EE certificate, I'm assuming you're following CABForum BR (it's written so in your CP, at least for the verification operations). BR clause 13.2.5 states that ocspNoCheck extension is mandatory. This extension is missing in your OCSP responder certificates, while they have a "netscapeCertType" extension with "SSL Server" role, which is useless and improper.
Blocking: your OCSP responders also doesn't answer to GET requests (the request stalls). While you're applying to Mozilla and Mozilla products only support POST so far, this might change (it's even desired).
Le jeudi 15 novembre 2012 00:25:55 UTC+1, Kathleen Wilson a écrit :
> * Test Websites
> https://testssl-valid-r1i1.disig.sk
> https://testssl-valid-r2i1.disig.sk
Non-blocking: the certificatePolicies chaining results in an empty policy set when validating the EE certificates.
> * OCSP:
> http://rootcar1-ocsp.disig.sk/ocsp/rootcar1
> http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1
> http://rootcar2-ocsp.disig.sk/ocsp/rootcar2
> http://subcar2i1-ocsp.disig.sk/ocsp/subcar2i1
Blocking: your OCSP responders also doesn't answer to GET requests (the request stalls). While you're applying to Mozilla and Mozilla products only support POST so far, this might change (it's even desired).
Peter Miskovic
Nov 19, 2012, 6:27:13 AM11/19/12
to mozilla-dev-s...@lists.mozilla.org, mozilla-dev-s...@lists.mozilla.org
Hello Erwann,
CA Disig responses are written at each topics bellow.
Regards,
Peter Miskovic
senior consultant
Disig, a.s.
Dňa piatok, 16. novembra 2012 17:19:14 UTC+1 Erwann Abalea napísal(-a):
Bonjour,
Le jeudi 15 novembre 2012 00:25:55 UTC+1, Kathleen Wilson a écrit :
> * Test Websites
> https://testssl-valid-r1i1.disig.sk
> https://testssl-valid-r2i1.disig.sk
Non-blocking: the AIA:caIssuer point to a properly formatted object, with a wrong MIME-type (application/octet-stream instead of application/pkix-cert).
Disig response: FIXED
Non-blocking: the certificatePolicies chaining results in an empty policy set when validating the EE certificates.
Disig response: We are not sure what do you mean.
Could you explain this in more detail, please? Thank you.
> * OCSP:
> http://rootcar1-ocsp.disig.sk/ocsp/rootcar1
> http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1
> http://rootcar2-ocsp.disig.sk/ocsp/rootcar2
> http://subcar2i1-ocsp.disig.sk/ocsp/subcar2i1
Since you're using a CABForum OID in your EE certificate, I'm assuming you're following CABForum BR (it's written so in your CP, at least for the verification operations). BR clause 13.2.5 states that ocspNoCheck extension is mandatory. This extension is missing in your OCSP responder certificates, while they have a "netscapeCertType" extension with "SSL Server" role, which is useless and improper.
Disig response: We will fix this by issuing the new OCSP responder certificates
for rootcar1, rootcar2, subcar1i1 and subcar2i1 with ocspNoCheck extension and
without "netscapeCertType" extension.
Blocking: your OCSP responders also doesn't answer to GET requests (the request stalls). While you're applying to Mozilla and Mozilla products only support POST so far, this might change (it's even desired).
Disig response: According CA Browser forum document "Baseline Requirements
for the Issuance and Management of Publicly-Trusted Certificates, v.1.0"
paragraph 13.2.2 "Effective 1 January 2013, the CA SHALL support an
OCSP capability using the GET method for Certificates issued in accordance
with these Requirements". We are in preparation for OCSP using GET method and
we are in testing phase now. On effective date January 1st, 2013 this method
will by fully supported.
CA Disig responses are written at each topics bellow.
Regards,
Peter Miskovic
senior consultant
Disig, a.s.
Dňa piatok, 16. novembra 2012 17:19:14 UTC+1 Erwann Abalea napísal(-a):
Bonjour,
Le jeudi 15 novembre 2012 00:25:55 UTC+1, Kathleen Wilson a écrit :
> * Test Websites
> https://testssl-valid-r1i1.disig.sk
> https://testssl-valid-r2i1.disig.sk
Non-blocking: the AIA:caIssuer point to a properly formatted object, with a wrong MIME-type (application/octet-stream instead of application/pkix-cert).
Non-blocking: the certificatePolicies chaining results in an empty policy set when validating the EE certificates.
Could you explain this in more detail, please? Thank you.
> * OCSP:
> http://rootcar1-ocsp.disig.sk/ocsp/rootcar1
> http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1
> http://rootcar2-ocsp.disig.sk/ocsp/rootcar2
> http://subcar2i1-ocsp.disig.sk/ocsp/subcar2i1
Since you're using a CABForum OID in your EE certificate, I'm assuming you're following CABForum BR (it's written so in your CP, at least for the verification operations). BR clause 13.2.5 states that ocspNoCheck extension is mandatory. This extension is missing in your OCSP responder certificates, while they have a "netscapeCertType" extension with "SSL Server" role, which is useless and improper.
for rootcar1, rootcar2, subcar1i1 and subcar2i1 with ocspNoCheck extension and
without "netscapeCertType" extension.
Blocking: your OCSP responders also doesn't answer to GET requests (the request stalls). While you're applying to Mozilla and Mozilla products only support POST so far, this might change (it's even desired).
for the Issuance and Management of Publicly-Trusted Certificates, v.1.0"
paragraph 13.2.2 "Effective 1 January 2013, the CA SHALL support an
OCSP capability using the GET method for Certificates issued in accordance
with these Requirements". We are in preparation for OCSP using GET method and
we are in testing phase now. On effective date January 1st, 2013 this method
will by fully supported.
Peter Miskovic
Nov 19, 2012, 6:42:15 AM11/19/12
to mozilla-dev-s...@lists.mozilla.org, mozilla-dev-s...@lists.mozilla.org
Hello Erwann,
CA Disig responses are written at each topics bellow.
Regards,
Peter Miskovic
senior consultant
Disig, a.s.
Dňa piatok, 16. novembra 2012 17:19:14 UTC+1 Erwann Abalea napísal(-a):
CA Disig responses are written at each topics bellow.
Regards,
Peter Miskovic
senior consultant
Disig, a.s.
Dňa piatok, 16. novembra 2012 17:19:14 UTC+1 Erwann Abalea napísal(-a):
Bonjour,
Le jeudi 15 novembre 2012 00:25:55 UTC+1, Kathleen Wilson a écrit :
> * Test Websites
> https://testssl-valid-r1i1.disig.sk
> https://testssl-valid-r2i1.disig.sk
Non-blocking: the AIA:caIssuer point to a properly formatted object, with a wrong MIME-type (application/octet-stream instead of application/pkix-cert).
Disig response: FIXED
Le jeudi 15 novembre 2012 00:25:55 UTC+1, Kathleen Wilson a écrit :
> * Test Websites
> https://testssl-valid-r1i1.disig.sk
> https://testssl-valid-r2i1.disig.sk
Non-blocking: the AIA:caIssuer point to a properly formatted object, with a wrong MIME-type (application/octet-stream instead of application/pkix-cert).
Non-blocking: the certificatePolicies chaining results in an empty policy set when validating the EE certificates.
Disig response: We are not sure what do you mean.
Could you explain this in more detail, please? Thank you.
Could you explain this in more detail, please? Thank you.
> * OCSP:
> http://rootcar1-ocsp.disig.sk/ocsp/rootcar1
> http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1
> http://rootcar2-ocsp.disig.sk/ocsp/rootcar2
> http://subcar2i1-ocsp.disig.sk/ocsp/subcar2i1
Since you're using a CABForum OID in your EE certificate, I'm assuming you're following CABForum BR (it's written so in your CP, at least for the verification operations). BR clause 13.2.5 states that ocspNoCheck extension is mandatory. This extension is missing in your OCSP responder certificates, while they have a "netscapeCertType" extension with "SSL Server" role, which is useless and improper.
> http://rootcar1-ocsp.disig.sk/ocsp/rootcar1
> http://subcar1i1-ocsp.disig.sk/ocsp/subcar1i1
> http://rootcar2-ocsp.disig.sk/ocsp/rootcar2
> http://subcar2i1-ocsp.disig.sk/ocsp/subcar2i1
Since you're using a CABForum OID in your EE certificate, I'm assuming you're following CABForum BR (it's written so in your CP, at least for the verification operations). BR clause 13.2.5 states that ocspNoCheck extension is mandatory. This extension is missing in your OCSP responder certificates, while they have a "netscapeCertType" extension with "SSL Server" role, which is useless and improper.
Disig response: We will fix this by issuing the new OCSP responder certificates
for rootcar1, rootcar2, subcar1i1 and subcar2i1 with ocspNoCheck extension and
without "netscapeCertType" extension.
for rootcar1, rootcar2, subcar1i1 and subcar2i1 with ocspNoCheck extension and
without "netscapeCertType" extension.
Blocking: your OCSP responders also doesn't answer to GET requests (the request stalls). While you're applying to Mozilla and Mozilla products only support POST so far, this might change (it's even desired).
Erwann Abalea
Nov 19, 2012, 2:31:33 PM11/19/12
to mozilla-dev-s...@lists.mozilla.org
Bonsoir,
Le lundi 19 novembre 2012 12:27:13 UTC+1, Peter Miskovic a écrit :
> Dňa piatok, 16. novembra 2012 17:19:14 UTC+1 Erwann Abalea napísal(-a):
[...]
While validating the certificate chain I get from the first test website, here's the chain I obtain:
... CN=CA Disig Root R1
... CN=CA Disig R1I1 Certification Service (certificatePolicies={1.3.158.35975946.0.0.0.1.1.4.5})
... CN=testssl-valid-r1i1.disig.sk (certificatePolicies={1.3.158.35975946.0.0.0.1.1.4.5, 2.23.140.1.2.2})
If you follow the normative validation algorithm (pick either the X.509 one of the RFC5280 one), the result of this chain will be that the end-entity certificate is valid for policyId 1.3.158.35975946.0.0.0.1.1.4.5 only. Read the definition of the certificatePolicies extension.
Right now it's not a problem at all.
[...]
I'm OK with this request.
Le lundi 19 novembre 2012 12:27:13 UTC+1, Peter Miskovic a écrit :
> Dňa piatok, 16. novembra 2012 17:19:14 UTC+1 Erwann Abalea napísal(-a):
> Non-blocking: the certificatePolicies chaining results in an empty policy set when validating the EE certificates.
>
> Disig response: We are not sure what do you mean.
> Could you explain this in more detail, please? Thank you.
I am partly wrong, the policy set is not empty, it just won't include the CABForum OID.
>
> Disig response: We are not sure what do you mean.
> Could you explain this in more detail, please? Thank you.
While validating the certificate chain I get from the first test website, here's the chain I obtain:
... CN=CA Disig Root R1
... CN=CA Disig R1I1 Certification Service (certificatePolicies={1.3.158.35975946.0.0.0.1.1.4.5})
... CN=testssl-valid-r1i1.disig.sk (certificatePolicies={1.3.158.35975946.0.0.0.1.1.4.5, 2.23.140.1.2.2})
If you follow the normative validation algorithm (pick either the X.509 one of the RFC5280 one), the result of this chain will be that the end-entity certificate is valid for policyId 1.3.158.35975946.0.0.0.1.1.4.5 only. Read the definition of the certificatePolicies extension.
Right now it's not a problem at all.
[...]
> Blocking: your OCSP responders also doesn't answer to GET requests (the request stalls). While you're applying to Mozilla and Mozilla products only support POST so far, this might change (it's even desired).
>
> Disig response: According CA Browser forum document "Baseline Requirements
> for the Issuance and Management of Publicly-Trusted Certificates, v.1.0"
> paragraph 13.2.2 "Effective 1 January 2013, the CA SHALL support an
> OCSP capability using the GET method for Certificates issued in accordance
> with these Requirements". We are in preparation for OCSP using GET method and
> we are in testing phase now. On effective date January 1st, 2013 this method
> will by fully supported.
You're right, OCSP becomes mandatory on 1st January 2013, with support for GET requests. POST support is not mandatory for CABForum, but since Mozilla only uses POST requests they're also MUST requirements (for Mozilla only).
>
> Disig response: According CA Browser forum document "Baseline Requirements
> for the Issuance and Management of Publicly-Trusted Certificates, v.1.0"
> paragraph 13.2.2 "Effective 1 January 2013, the CA SHALL support an
> OCSP capability using the GET method for Certificates issued in accordance
> with these Requirements". We are in preparation for OCSP using GET method and
> we are in testing phase now. On effective date January 1st, 2013 this method
> will by fully supported.
I'm OK with this request.
Kathleen Wilson
Nov 26, 2012, 5:46:33 PM11/26/12
to mozilla-dev-s...@lists.mozilla.org
Does anyone else have comments or questions on this request?
Kathleen
Kathleen Wilson
Dec 11, 2012, 5:01:24 PM12/11/12
to mozilla-dev-s...@lists.mozilla.org
Thank you to those of you who reviewed this request from Disig and
participated in this discussion. Disig has applied to include the “CA
I am closing this discussion, and I will recommend approval in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=792377
Any further follow-up on this request should be added directly to the bug.
Thanks,
Kathleen
participated in this discussion. Disig has applied to include the “CA
Disig Root R1” root certificate that will eventually replace the “CA
Disig” root certificate that is currently included in Mozilla products
(Bugzilla #455878). This request is to also include the “CA Disig Root
R2” SHA-256 root certificate. All three trust bits are requested for
both certs, and EV is not requested at this time.
There are no action items resulting from this discussion.
Disig” root certificate that is currently included in Mozilla products
(Bugzilla #455878). This request is to also include the “CA Disig Root
R2” SHA-256 root certificate. All three trust bits are requested for
both certs, and EV is not requested at this time.
I am closing this discussion, and I will recommend approval in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=792377
Any further follow-up on this request should be added directly to the bug.
Thanks,
Kathleen
0 new messages