Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
IdenTrust Root Renewal Request
446 views
Skip to first unread message
Kathleen Wilson
Oct 30, 2014, 2:17:41 PM10/30/14
to mozilla-dev-s...@lists.mozilla.org
IdenTrust has applied to include the “IdenTrust Commercial Root CA 1”
and “IdenTrust Public Sector Root CA 1” root certificates, and turn on
the Websites and Email trust bits for both. The “IdenTrust Commercial
Root CA 1” root will eventually replace the “DST Root X3” certificate,
and the “IdenTrust Public Sector Root CA 1” root will eventually replace
the “DST ACES X6” certificate. Both of the currently-included root
certificates were included via Bugzilla Bug #394733.
IdenTrust is a for-profit corporation serving the private, commercial,
and government sectors.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1037590
And in the pending certificates list:
http://www.mozilla.org/projects/security/certs/pending/
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8504852
Noteworthy points:
* The primary documents are in English
Documentation for the “IdenTrust Commercial Root CA 1” root:
TrustID Document Repository:
https://secure.identrust.com/certificates/policy/ts/
TrustID CPS:
https://secure.identrust.com/certificates/policy/ts/identrust_trustid_cps_v2.3_20140109.pdf
TrustID CP:
https://secure.identrust.com/certificates/policy/ts/TrustID_CP_v1.6.1_20130912.pdf
Documentation for the “IdenTrust Public Sector Root CA 1” root:
ACES Document Repository:
https://secure.identrust.com/certificates/policy/aces/
ACES CPS:
https://secure.identrust.com/certificates/policy/aces/dst-aces-cps-v20040617.pdf
ACES CPS Addendum:
https://secure.identrust.com/certificates/policy/aces/IdenTrust-Addendum-2013-11-26.pdf
* CA Hierarchy:
** “IdenTrust Commercial Root CA 1” root:
The intent is to generate the subordinate CA Certificates that will
support the current lines of business under the root being replaced. At
this time not all of the subordinate CA certificates have been generated
(names may change)
- [Internal]TrustID CA A52 (s/mime certificates)
- [Internal]TrustID CA A12 (Device/SSL Certificates)
In the future, there is the possibility of issuance of externally
operated CAs under this root. In such case, IdenTrust will favor the
independently audited and publicly disclose subordinate CA model of
operation.
Note that the “DST Root X3” root has signed one subordinate CA that is
externally operated. This subordinate CA has a policy publicly
published and has been audited under the WebTrust regime.
** “IdenTrust Public Sector Root CA 1” root:
The intent is to generate the following subordinate under this root:
- [Internal]IdenTrust ACES CA 2 (s/mime, device/SSL certificates)
There are no plans to have externally operated subordinate CAs off this
root at this time
Note that there are no externally-operated subordinate CAs that have
been signed by the “DST ACES X6” root.
* This request is to turn on the Websites and Email trust bits for both
root certs. EV treatment is not requested.
** “IdenTrust Commercial Root CA 1” root:
*** TrustID CPS section 3.2.7.1: To ensure that requests for TrustID SSL
Certificates are properly verified, IdenTrust and RAs conduct two
additional checks when necessary:
(1) IdenTrust and RAs maintain internal lists of prior denied
applications identified as posing a risk; and
(2) IdenTrust and RAs will check high risk domain requests against an
authoritative third party list prior to issuance.
Information returned from such checks is used during the application
process by an LRA within IdenTrust or an RA when identifying potentially
illegitimate Certificate requests. If an RA is elected to perform
verification processes, IdenTrust will verify that the RA’s processes
used to identify high risk domain requests and prior denied requests
provide a level of assurance that is equal to or exceeds the same level
of assurance provided by the process described below.
*** TrustID CPS section 3.2.7.2: IdenTrust verifies that the PKI Sponsor
has the right to use or has control of the FQDN(s) or IP address(es)
listed in the Certificate application by following the steps listed below.
The LRA confirms the Domain registrant’s rights by doing the following:
1) The Domain(s) supplied by the PKI Sponsor is placed into a search
engine (e.g. WHOIS) and the LRA records the contact information for the
Domain Name Registrant.
2) Once the Domain Name registrant is identified from a database record
he or she is contacted via email. In this email the Domain Name
registrant will be asked:
a. to confirm or deny the right of the PKI Sponsor to be issued a Device
Certificate for the Domain Name(s) for which the PKI Sponsor has applied;
b. if they would like to provide the names other potential PKI
Sponsor(s) that may request the same type of Certificate; and
c. with respect only to applications for Wildcard Certificates, to
confirm or deny control over the entire Domain Namespace of the FQDN
provided and that such control is rightful.
If the PKI Sponsor applies for a Domain Name that contains a two-letter
country code (ccTLD) (e.g. www.identrust.uk as opposed to
www.identrust.com), this confirmation will be sought from the Domain
Name level to which the ccTLD applies. This means that the LRA cannot
obtain verification from www.identrust.com if the PKI Sponsor is
applying for a Domain Name from www.identrust.uk.
*** Trust ID CPS section 3.2.5:
Email verification when required can be done in two ways; electronically
and manually through a list submitted by a Trusted Agent. If the
application for a Certificate requires email verification the
application cannot be approved until the specified steps for electronic
or manual verification is complete.
- Electronic Verification of Email: When an Applicant/PKI Sponsor
submits an application through a secure online form, an automated email
is sent to the personal email address provided in the application.
Within that automated email message there is a link that guides the
Applicant/PKI Sponsor to a server-authenticated SSL/TLS secured web site
and instructions to provide out-of-band information, including an
Account Password. This Account Password was created during the
application by the Applicant/PKI Sponsor and it is secure only to the
Applicant/PKI Sponsor. When the Applicant/PKI Sponsor provides and
submits the Account Password created during the application accurately
the verification of the email address is completed and the verification
status is automatically updated within the Applicant/PKI Sponsor’s
application record.
- Manual Verification of Email: When a Trusted Agent provides the list
of authorized Applicants/PKI Sponsors, the email address is validated by
the Trusted Agent based on the internal knowledge of the Sponsoring
Organization. The Trusted Agent may use internal databases and
directories to ensure the email accuracy.
** “IdenTrust Public Sector Root CA 1” root:
*** ACES CPS Addendum section 3.1.9.4:
Verification of Authorization by Domain Name Registrant
IdenTrust verifies that the PKI Sponsor has the right to issue or has
control of the Fully-Qualified Domain Name(s) from the SAN extension and
public IP address(es) listed in the Certificate application by following
the steps listed below.
The LRA confirms the rights by the Domain Registrant by doing the following:
(1)The domain(s) supplied by the PKI Sponsor is placed into a search
engine (e.g. WHOIS) and the LRA records the contact information for the
Domain Name Registrant.
(2) Once the Domain Name Registrant is identified from a database record
he or she are contacted via email to confirm the information provided by
the PKI Sponsor to confirm or deny the right of the PKI Sponsor to be
issued the certificate for the Domain Name(s) for which the PKI Sponsor
has applied. It is through this process that IdenTrust ensures that SSL
Certificates are issued with the consent of the owner of each FQDN
contained within the Certificate.During this exchange the Domain Name
Registrant will have the opportunity to name other potential PKI Sponsor(s).
If the PKI Sponsor applies for a domain that is a two-letter country
code (ccTLD), this confirmation will be sought from the Domain Name
level to which the ccTLD applies.
*** ACES Addendum section 3.1.9.7
Email verification when required can be done in two ways; electronically
and manually through a list submitted by a Trusted Agent. If the
application for a Certificate requires email verification the
application cannot be approved until the specified steps for electronic
or manual of verification is complete.
- Electronic Verification of Email: When an Applicant/PKI Sponsor
submits an application through a secure online form, an automated email
is sent to the Applicant/PKI Sponsor’s email address provided in the
application. Within that automated email message there is a link that
guides the Applicant/PKI Sponsor to a server-authenticated SSL/TLS
secured web site and instructions to provide out-of-band information,
including in Account passphrase Password. This Account Password was
created during the application by the Applicant/PKI Sponsor and it is
secure only to the Applicant/PKI Sponsor. When the Applicant/PKI Sponsor
provides and submits the passphrase Account Password created during the
application accurately the verification of the email address is
completed and the verification status is automatically updated within
the Applicant/PKI Sponsor’s application record.
- Manual Verification of Email: When a Trusted Agent provides the list
of authorized Applicants/PKI Sponsors, the email address is validated by
the Trusted Agent based on the internal knowledge of the Sponsoring
Organization. The Trusted Agent may use internal databases and
directories to ensure the email accuracy.
* EV Policy OID: Not requesting EV treatment
* Root Cert URLs
https://bugzilla.mozilla.org/attachment.cgi?id=8473319
http://validation.identrust.com/roots/commercialrootca1.p7c
https://bugzilla.mozilla.org/attachment.cgi?id=8473320
http://validation.identrust.com/roots/publicrootca1.p7c
* Test Websites
https://sha2ssl-trustidvalid.identrustssl.com/
https://sha2ssl-acesvalid.identrust.com/
Comprehensive list: http://testssl.identrust.com/
* CRL
http://validation.identrust.com/crl/commercialrootca1.crl
http://validation.identrust.com/crl/trustidcaa52.crl
http://validation.identrust.com/crl/publicrootca1.crl
http://validation.identrust.com/crl/acesca2.crl
* OCSP
http://commercial.ocsp.identrust.com
http://public.ocsp.identrust.com
* Audit: Annual audits are performed by BrightLine according to the
WebTrust CA and WebTrust Baseline Requirements audit criteria.
https://cert.webtrust.org/SealFile?seal=1720&file=pdf
https://cert.webtrust.org/SealFile?seal=1720&file=pdf
https://secure.identrust.com/certificates/policy/ts/current-baseline-requirements-audit.pdf
* Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices)
** Delegation of Domain / Email validation to third parties
IdenTrust validates Domains for SSL certificates issued and does not
delegate such validation. See TrustID CPS section 3.2.7.2 and ACES CPS
Addendum 3.1.9.4.
IdenTrust allows Trusted Agents to, in particular cases, manually
validate the email of certificates. Trusted Agents are employees of the
organizations requesting the certificate and are under agreement with
IdenTrust. Trusted Agents validation is limited to emails within their
organization and only in circumstances where automatic validation is not
possible. See TrustID CPS section 3.2.5 and ACES CPS Addendum section
3.1.9.7 for detail.
This begins the discussion of the request from IdenTrust to include the
“IdenTrust Commercial Root CA 1” and “IdenTrust Public Sector Root CA 1”
root certificates, and turn on the Websites and Email trust bits for
both. 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
and “IdenTrust Public Sector Root CA 1” root certificates, and turn on
the Websites and Email trust bits for both. The “IdenTrust Commercial
Root CA 1” root will eventually replace the “DST Root X3” certificate,
and the “IdenTrust Public Sector Root CA 1” root will eventually replace
the “DST ACES X6” certificate. Both of the currently-included root
certificates were included via Bugzilla Bug #394733.
IdenTrust is a for-profit corporation serving the private, commercial,
and government sectors.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1037590
And in the pending certificates list:
http://www.mozilla.org/projects/security/certs/pending/
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8504852
Noteworthy points:
* The primary documents are in English
Documentation for the “IdenTrust Commercial Root CA 1” root:
TrustID Document Repository:
https://secure.identrust.com/certificates/policy/ts/
TrustID CPS:
https://secure.identrust.com/certificates/policy/ts/identrust_trustid_cps_v2.3_20140109.pdf
TrustID CP:
https://secure.identrust.com/certificates/policy/ts/TrustID_CP_v1.6.1_20130912.pdf
Documentation for the “IdenTrust Public Sector Root CA 1” root:
ACES Document Repository:
https://secure.identrust.com/certificates/policy/aces/
ACES CPS:
https://secure.identrust.com/certificates/policy/aces/dst-aces-cps-v20040617.pdf
ACES CPS Addendum:
https://secure.identrust.com/certificates/policy/aces/IdenTrust-Addendum-2013-11-26.pdf
* CA Hierarchy:
** “IdenTrust Commercial Root CA 1” root:
The intent is to generate the subordinate CA Certificates that will
support the current lines of business under the root being replaced. At
this time not all of the subordinate CA certificates have been generated
(names may change)
- [Internal]TrustID CA A52 (s/mime certificates)
- [Internal]TrustID CA A12 (Device/SSL Certificates)
In the future, there is the possibility of issuance of externally
operated CAs under this root. In such case, IdenTrust will favor the
independently audited and publicly disclose subordinate CA model of
operation.
Note that the “DST Root X3” root has signed one subordinate CA that is
externally operated. This subordinate CA has a policy publicly
published and has been audited under the WebTrust regime.
** “IdenTrust Public Sector Root CA 1” root:
The intent is to generate the following subordinate under this root:
- [Internal]IdenTrust ACES CA 2 (s/mime, device/SSL certificates)
There are no plans to have externally operated subordinate CAs off this
root at this time
Note that there are no externally-operated subordinate CAs that have
been signed by the “DST ACES X6” root.
* This request is to turn on the Websites and Email trust bits for both
root certs. EV treatment is not requested.
** “IdenTrust Commercial Root CA 1” root:
*** TrustID CPS section 3.2.7.1: To ensure that requests for TrustID SSL
Certificates are properly verified, IdenTrust and RAs conduct two
additional checks when necessary:
(1) IdenTrust and RAs maintain internal lists of prior denied
applications identified as posing a risk; and
(2) IdenTrust and RAs will check high risk domain requests against an
authoritative third party list prior to issuance.
Information returned from such checks is used during the application
process by an LRA within IdenTrust or an RA when identifying potentially
illegitimate Certificate requests. If an RA is elected to perform
verification processes, IdenTrust will verify that the RA’s processes
used to identify high risk domain requests and prior denied requests
provide a level of assurance that is equal to or exceeds the same level
of assurance provided by the process described below.
*** TrustID CPS section 3.2.7.2: IdenTrust verifies that the PKI Sponsor
has the right to use or has control of the FQDN(s) or IP address(es)
listed in the Certificate application by following the steps listed below.
The LRA confirms the Domain registrant’s rights by doing the following:
1) The Domain(s) supplied by the PKI Sponsor is placed into a search
engine (e.g. WHOIS) and the LRA records the contact information for the
Domain Name Registrant.
2) Once the Domain Name registrant is identified from a database record
he or she is contacted via email. In this email the Domain Name
registrant will be asked:
a. to confirm or deny the right of the PKI Sponsor to be issued a Device
Certificate for the Domain Name(s) for which the PKI Sponsor has applied;
b. if they would like to provide the names other potential PKI
Sponsor(s) that may request the same type of Certificate; and
c. with respect only to applications for Wildcard Certificates, to
confirm or deny control over the entire Domain Namespace of the FQDN
provided and that such control is rightful.
If the PKI Sponsor applies for a Domain Name that contains a two-letter
country code (ccTLD) (e.g. www.identrust.uk as opposed to
www.identrust.com), this confirmation will be sought from the Domain
Name level to which the ccTLD applies. This means that the LRA cannot
obtain verification from www.identrust.com if the PKI Sponsor is
applying for a Domain Name from www.identrust.uk.
*** Trust ID CPS section 3.2.5:
Email verification when required can be done in two ways; electronically
and manually through a list submitted by a Trusted Agent. If the
application for a Certificate requires email verification the
application cannot be approved until the specified steps for electronic
or manual verification is complete.
- Electronic Verification of Email: When an Applicant/PKI Sponsor
submits an application through a secure online form, an automated email
is sent to the personal email address provided in the application.
Within that automated email message there is a link that guides the
Applicant/PKI Sponsor to a server-authenticated SSL/TLS secured web site
and instructions to provide out-of-band information, including an
Account Password. This Account Password was created during the
application by the Applicant/PKI Sponsor and it is secure only to the
Applicant/PKI Sponsor. When the Applicant/PKI Sponsor provides and
submits the Account Password created during the application accurately
the verification of the email address is completed and the verification
status is automatically updated within the Applicant/PKI Sponsor’s
application record.
- Manual Verification of Email: When a Trusted Agent provides the list
of authorized Applicants/PKI Sponsors, the email address is validated by
the Trusted Agent based on the internal knowledge of the Sponsoring
Organization. The Trusted Agent may use internal databases and
directories to ensure the email accuracy.
** “IdenTrust Public Sector Root CA 1” root:
*** ACES CPS Addendum section 3.1.9.4:
Verification of Authorization by Domain Name Registrant
IdenTrust verifies that the PKI Sponsor has the right to issue or has
control of the Fully-Qualified Domain Name(s) from the SAN extension and
public IP address(es) listed in the Certificate application by following
the steps listed below.
The LRA confirms the rights by the Domain Registrant by doing the following:
(1)The domain(s) supplied by the PKI Sponsor is placed into a search
engine (e.g. WHOIS) and the LRA records the contact information for the
Domain Name Registrant.
(2) Once the Domain Name Registrant is identified from a database record
he or she are contacted via email to confirm the information provided by
the PKI Sponsor to confirm or deny the right of the PKI Sponsor to be
issued the certificate for the Domain Name(s) for which the PKI Sponsor
has applied. It is through this process that IdenTrust ensures that SSL
Certificates are issued with the consent of the owner of each FQDN
contained within the Certificate.During this exchange the Domain Name
Registrant will have the opportunity to name other potential PKI Sponsor(s).
If the PKI Sponsor applies for a domain that is a two-letter country
code (ccTLD), this confirmation will be sought from the Domain Name
level to which the ccTLD applies.
*** ACES Addendum section 3.1.9.7
Email verification when required can be done in two ways; electronically
and manually through a list submitted by a Trusted Agent. If the
application for a Certificate requires email verification the
application cannot be approved until the specified steps for electronic
or manual of verification is complete.
- Electronic Verification of Email: When an Applicant/PKI Sponsor
submits an application through a secure online form, an automated email
is sent to the Applicant/PKI Sponsor’s email address provided in the
application. Within that automated email message there is a link that
guides the Applicant/PKI Sponsor to a server-authenticated SSL/TLS
secured web site and instructions to provide out-of-band information,
including in Account passphrase Password. This Account Password was
created during the application by the Applicant/PKI Sponsor and it is
secure only to the Applicant/PKI Sponsor. When the Applicant/PKI Sponsor
provides and submits the passphrase Account Password created during the
application accurately the verification of the email address is
completed and the verification status is automatically updated within
the Applicant/PKI Sponsor’s application record.
- Manual Verification of Email: When a Trusted Agent provides the list
of authorized Applicants/PKI Sponsors, the email address is validated by
the Trusted Agent based on the internal knowledge of the Sponsoring
Organization. The Trusted Agent may use internal databases and
directories to ensure the email accuracy.
* EV Policy OID: Not requesting EV treatment
* Root Cert URLs
https://bugzilla.mozilla.org/attachment.cgi?id=8473319
http://validation.identrust.com/roots/commercialrootca1.p7c
https://bugzilla.mozilla.org/attachment.cgi?id=8473320
http://validation.identrust.com/roots/publicrootca1.p7c
* Test Websites
https://sha2ssl-trustidvalid.identrustssl.com/
https://sha2ssl-acesvalid.identrust.com/
Comprehensive list: http://testssl.identrust.com/
* CRL
http://validation.identrust.com/crl/commercialrootca1.crl
http://validation.identrust.com/crl/trustidcaa52.crl
http://validation.identrust.com/crl/publicrootca1.crl
http://validation.identrust.com/crl/acesca2.crl
* OCSP
http://commercial.ocsp.identrust.com
http://public.ocsp.identrust.com
* Audit: Annual audits are performed by BrightLine according to the
WebTrust CA and WebTrust Baseline Requirements audit criteria.
https://cert.webtrust.org/SealFile?seal=1720&file=pdf
https://cert.webtrust.org/SealFile?seal=1720&file=pdf
https://secure.identrust.com/certificates/policy/ts/current-baseline-requirements-audit.pdf
* Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices)
** Delegation of Domain / Email validation to third parties
IdenTrust validates Domains for SSL certificates issued and does not
delegate such validation. See TrustID CPS section 3.2.7.2 and ACES CPS
Addendum 3.1.9.4.
IdenTrust allows Trusted Agents to, in particular cases, manually
validate the email of certificates. Trusted Agents are employees of the
organizations requesting the certificate and are under agreement with
IdenTrust. Trusted Agents validation is limited to emails within their
organization and only in circumstances where automatic validation is not
possible. See TrustID CPS section 3.2.5 and ACES CPS Addendum section
3.1.9.7 for detail.
This begins the discussion of the request from IdenTrust to include the
“IdenTrust Commercial Root CA 1” and “IdenTrust Public Sector Root CA 1”
root certificates, and turn on the Websites and Email trust bits for
both. 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
Kathleen Wilson
Nov 6, 2014, 2:52:30 PM11/6/14
to mozilla-dev-s...@lists.mozilla.org
On 10/30/14, 11:16 AM, Kathleen Wilson wrote:
> IdenTrust has applied to include the “IdenTrust Commercial Root CA 1”
> and “IdenTrust Public Sector Root CA 1” root certificates, and turn on
> the Websites and Email trust bits for both. The “IdenTrust Commercial
> Root CA 1” root will eventually replace the “DST Root X3” certificate,
> and the “IdenTrust Public Sector Root CA 1” root will eventually replace
> the “DST ACES X6” certificate. Both of the currently-included root
> certificates were included via Bugzilla Bug #394733.
>
> IdenTrust is a for-profit corporation serving the private, commercial,
> and government sectors.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1037590
>
> And in the pending certificates list:
> http://www.mozilla.org/projects/security/certs/pending/
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=8504852
>
Does anyone of comments or questions about this root renewal request
> IdenTrust has applied to include the “IdenTrust Commercial Root CA 1”
> and “IdenTrust Public Sector Root CA 1” root certificates, and turn on
> the Websites and Email trust bits for both. The “IdenTrust Commercial
> Root CA 1” root will eventually replace the “DST Root X3” certificate,
> and the “IdenTrust Public Sector Root CA 1” root will eventually replace
> the “DST ACES X6” certificate. Both of the currently-included root
> certificates were included via Bugzilla Bug #394733.
>
> IdenTrust is a for-profit corporation serving the private, commercial,
> and government sectors.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1037590
>
> And in the pending certificates list:
> http://www.mozilla.org/projects/security/certs/pending/
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=8504852
>
from Identrust?
Kathleen
Erwann Abalea
Nov 7, 2014, 8:35:37 AM11/7/14
to mozilla-dev-s...@lists.mozilla.org
Le jeudi 30 octobre 2014 19:17:41 UTC+1, Kathleen Wilson a écrit :
> IdenTrust has applied to include the "IdenTrust Commercial Root CA 1"
> and "IdenTrust Public Sector Root CA 1" root certificates, and turn on
> the Websites and Email trust bits for both. The "IdenTrust Commercial
> Root CA 1" root will eventually replace the "DST Root X3" certificate,
> and the "IdenTrust Public Sector Root CA 1" root will eventually replace
> the "DST ACES X6" certificate. Both of the currently-included root
> certificates were included via Bugzilla Bug #394733.
[...]
> IdenTrust has applied to include the "IdenTrust Commercial Root CA 1"
> and "IdenTrust Public Sector Root CA 1" root certificates, and turn on
> the Websites and Email trust bits for both. The "IdenTrust Commercial
> Root CA 1" root will eventually replace the "DST Root X3" certificate,
> and the "IdenTrust Public Sector Root CA 1" root will eventually replace
> the "DST ACES X6" certificate. Both of the currently-included root
> certificates were included via Bugzilla Bug #394733.
> * Root Cert URLs
> https://bugzilla.mozilla.org/attachment.cgi?id=8473319
> http://validation.identrust.com/roots/commercialrootca1.p7c
> https://bugzilla.mozilla.org/attachment.cgi?id=8473320
> http://validation.identrust.com/roots/publicrootca1.p7c
>
> * Test Websites
> https://sha2ssl-trustidvalid.identrustssl.com/
> https://sha2ssl-acesvalid.identrust.com/
> Comprehensive list: http://testssl.identrust.com/
>
> * CRL
> http://validation.identrust.com/crl/commercialrootca1.crl
> http://validation.identrust.com/crl/trustidcaa52.crl
> http://validation.identrust.com/crl/publicrootca1.crl
> http://validation.identrust.com/crl/acesca2.crl
>
> * OCSP
> http://commercial.ocsp.identrust.com
> http://public.ocsp.identrust.com
Nothing's obviously wrong on the certificates, CRLs, CP/CPS.
> https://bugzilla.mozilla.org/attachment.cgi?id=8473319
> http://validation.identrust.com/roots/commercialrootca1.p7c
> https://bugzilla.mozilla.org/attachment.cgi?id=8473320
> http://validation.identrust.com/roots/publicrootca1.p7c
>
> * Test Websites
> https://sha2ssl-trustidvalid.identrustssl.com/
> https://sha2ssl-acesvalid.identrust.com/
> Comprehensive list: http://testssl.identrust.com/
>
> * CRL
> http://validation.identrust.com/crl/commercialrootca1.crl
> http://validation.identrust.com/crl/trustidcaa52.crl
> http://validation.identrust.com/crl/publicrootca1.crl
> http://validation.identrust.com/crl/acesca2.crl
>
> * OCSP
> http://commercial.ocsp.identrust.com
> http://public.ocsp.identrust.com
Intermediate certificates include EKU OIDs for IPSec {Tunnel, User, End System}, which is weird; why would anyone want a *public* certificate to authentify against a virtual *private* network? That's not a blocker. These EKU OIDs are obsolete anyway.
The sha2ssl-acesvalid subscriber certificate includes the BR IV policyId OID, but this OID isn't granted to the issuer. Not a blocker, but if a RP explicitely requires this OID to be present, this chain will be rejected (see recent discussions on CABForum about CP OID chaining).
The OCSP responders both include too many certificates, this has a performance impact for your users; no need to include intermediate and root certificates in the response. Not a blocker.
The OCSP responders answer "unknown" when asked to verify the 2 given intermediate certificates. Not a blocker, but probably not expected.
Matthias Hunstock
Nov 7, 2014, 10:46:32 AM11/7/14
to mozilla-dev-s...@lists.mozilla.org
Am 07.11.2014 um 14:35 schrieb Erwann Abalea:
> Intermediate certificates include EKU OIDs for IPSec {Tunnel, User, End System},
> which is weird; why would anyone want a *public* certificate to authentify
> against a virtual *private* network?
If an organisation is already using a "proper" PKI, why should they use
> Intermediate certificates include EKU OIDs for IPSec {Tunnel, User, End System},
> which is weird; why would anyone want a *public* certificate to authentify
> against a virtual *private* network?
a separate one for VPN?
Renne Rodriguez
Nov 18, 2014, 7:03:29 PM11/18/14
to mozilla-dev-s...@lists.mozilla.org
Erwann,
Thank you for your input, it was insightful. See our responses below.
Comment 1:
Comment 2:
Comment 3:
However, this approach is consistent with the RFC 6960 section 4.2.2 - Basic Response: "The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature."
In our experience, SSL certificates are used by clients other than browsers; and, unfortunately, some clients are not able to do proper path construction. For those cases, and we have had some, we provide those certificates.
Comment 4:
Thank you for your input, it was insightful. See our responses below.
Comment 1:
Intermediate certificates include EKU OIDs for IPSec {Tunnel, User, End System}, which is weird; why would anyone want a *public* certificate to authentify against a virtual *private* network? That's not a blocker. These EKU OIDs are obsolete anyway.
[IdenTrust answer] These Intermediate CAs are used to issue both SSL and device certificates. Some of those device certificates still require those EKU OIDs, in some cases in combination with Server Auth EKU OID. At this time, there is not a strict requirement of separation of SSL versus other device certificates. We are following discussions about the idea of having a dedicated intermediate CA to SSL. If this were to become a requirement, we will become compliant that that time.
Comment 2:
The sha2ssl-acesvalid subscriber certificate includes the BR IV policyId OID, but this OID isn't granted to the issuer. Not a blocker, but if a RP explicitely requires this OID to be present, this chain will be rejected (see recent discussions on CABForum about CP OID chaining).
[IdenTrust answer] We have followed the discussion in CAB Forum and we agree with the approaches that were discussed there. We will be making a change to either the subordinate CA (resigning) or to the end-entity profiles (removing second OID). We will update the list on what approach we will take.
Comment 3:
The OCSP responders both include too many certificates, this has a performance impact for your users; no need to include intermediate and root certificates in the response. Not a blocker.
[IdenTrust] You are correct that there is some performance impact.
However, this approach is consistent with the RFC 6960 section 4.2.2 - Basic Response: "The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature."
In our experience, SSL certificates are used by clients other than browsers; and, unfortunately, some clients are not able to do proper path construction. For those cases, and we have had some, we provide those certificates.
Comment 4:
The OCSP responders answer "unknown" when asked to verify the 2 given intermediate certificates. Not a blocker, but probably not expected.
[IdenTrust] Our configuration was incorrect in the OCSP. We have corrected it and you should be able to receive the appropriate responses.
Brian Smith
Nov 20, 2014, 3:23:41 PM11/20/14
to Renne Rodriguez, mozilla-dev-s...@lists.mozilla.org
Renne Rodriguez <Renne.R...@identrust.com> wrote:
> Comment 3:
> The OCSP responders both include too many certificates, this has a performance impact for your users; no need to include intermediate and root certificates in the response. Not a blocker.
> [IdenTrust] You are correct that there is some performance impact.
> However, this approach is consistent with the RFC 6960 section 4.2.2 - Basic Response: "The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature."
> In our experience, SSL certificates are used by clients other than browsers; and, unfortunately, some clients are not able to do proper path construction. For those cases, and we have had some, we provide those certificates.
How does this fit with Section 4.2.2.2, though? Either the OCSP
> Comment 3:
> The OCSP responders both include too many certificates, this has a performance impact for your users; no need to include intermediate and root certificates in the response. Not a blocker.
> [IdenTrust] You are correct that there is some performance impact.
> However, this approach is consistent with the RFC 6960 section 4.2.2 - Basic Response: "The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature."
> In our experience, SSL certificates are used by clients other than browsers; and, unfortunately, some clients are not able to do proper path construction. For those cases, and we have had some, we provide those certificates.
response has to be signed by the issuing certificate, in which case no
certificates need to be included in the OCSP response, or it must be
signed with a delegated OCSP responder certificate that is directly
issued by the issuing certificate, in which case only one certificate
is required. It seems to me like a correct implementation of OCSP
response verification should never need more than one certificate in a
reasonably-produced OCSP response, at least in the way that such
things are used by browsers.
Thanks,
Brian
[1] http://tools.ietf.org/html/rfc6960#section-4.2.2.2
kirk...@trendmicro.com
Nov 20, 2014, 6:20:11 PM11/20/14
to mozilla-dev-s...@lists.mozilla.org
Kathleen, out of curiosity -- what's the difference between a "Root Renewal Request" and a simple request to add a new root to the Mozilla root store? Are they essentially the same process, or is a root renewal request treated differently?
Erwann Abalea
Nov 21, 2014, 12:11:15 PM11/21/14
to mozilla-dev-s...@lists.mozilla.org
Bonsoir,
Le mercredi 19 novembre 2014 01:03:29 UTC+1, Renne Rodriguez a écrit :
[...]
> Comment 3:
> The OCSP responders both include too many certificates, this has a performance impact for your users; no need to include intermediate and root certificates in the response. Not a blocker.
> [IdenTrust] You are correct that there is some performance impact.
> However, this approach is consistent with the RFC 6960 section 4.2.2 - Basic Response: "The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature."
> In our experience, SSL certificates are used by clients other than browsers; and, unfortunately, some clients are not able to do proper path construction. For those cases, and we have had some, we provide those certificates.
I've read that argument before for some Java software, where the client sets issuerKeyHash with an empty value and only populates the issuerNameHash field.
Including the whole certificate chain isn't forbidden, of course. But I'd be tempted to say that those RP should die. This minority forces a penalty to be paid by the majority (browsers, good players). In order to lower that penalty, you could maybe consider to not include the root in the response. What value could have a root certificate transmitted that way, since trust in a TA MUST come out-of-band?
> Comment 4:
> The OCSP responders answer "unknown" when asked to verify the 2 given intermediate certificates. Not a blocker, but probably not expected.
> [IdenTrust] Our configuration was incorrect in the OCSP. We have corrected it and you should be able to receive the appropriate responses.
That seems to be done for the "Commercial" root, but not for the "Public" root. Trying to validate certificate for intermediate CA "IdenTrust ACES CA 2" still gives an unknown answer.
Again, no opposition from my side to this request.
Le mercredi 19 novembre 2014 01:03:29 UTC+1, Renne Rodriguez a écrit :
[...]
> Comment 3:
> The OCSP responders both include too many certificates, this has a performance impact for your users; no need to include intermediate and root certificates in the response. Not a blocker.
> [IdenTrust] You are correct that there is some performance impact.
> However, this approach is consistent with the RFC 6960 section 4.2.2 - Basic Response: "The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature."
> In our experience, SSL certificates are used by clients other than browsers; and, unfortunately, some clients are not able to do proper path construction. For those cases, and we have had some, we provide those certificates.
Including the whole certificate chain isn't forbidden, of course. But I'd be tempted to say that those RP should die. This minority forces a penalty to be paid by the majority (browsers, good players). In order to lower that penalty, you could maybe consider to not include the root in the response. What value could have a root certificate transmitted that way, since trust in a TA MUST come out-of-band?
> Comment 4:
> The OCSP responders answer "unknown" when asked to verify the 2 given intermediate certificates. Not a blocker, but probably not expected.
> [IdenTrust] Our configuration was incorrect in the OCSP. We have corrected it and you should be able to receive the appropriate responses.
Again, no opposition from my side to this request.
Erwann Abalea
Nov 21, 2014, 12:19:10 PM11/21/14
to mozilla-dev-s...@lists.mozilla.org
Le jeudi 20 novembre 2014 21:23:41 UTC+1, Brian Smith a écrit :
This:
[...]
1. Matches a local configuration of OCSP signing authority for the
certificate in question, or
[...]
was present in RFC2560, and is still present in RFC6960, same section (4.2.2.2), it just has moved to the end of the section.
This justifies that in some cases (not under CABF BR rules), a whole chain of certificates needs to be included in the response.
[...]
1. Matches a local configuration of OCSP signing authority for the
certificate in question, or
[...]
was present in RFC2560, and is still present in RFC6960, same section (4.2.2.2), it just has moved to the end of the section.
This justifies that in some cases (not under CABF BR rules), a whole chain of certificates needs to be included in the response.
Renne Rodriguez
Nov 21, 2014, 1:37:05 PM11/21/14
to mozilla-dev-s...@lists.mozilla.org, Brian Smith
> Comment 3:
> The OCSP responders both include too many certificates, this has a performance impact for your users; no need to include intermediate and root certificates in the response. Not a blocker.
> [IdenTrust] You are correct that there is some performance impact.
> However, this approach is consistent with the RFC 6960 section 4.2.2 - Basic Response: "The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature."
> In our experience, SSL certificates are used by clients other than browsers; and, unfortunately, some clients are not able to do proper path construction. For those cases, and we have had some, we provide those certificates.
How does this fit with Section 4.2.2.2, though? Either the OCSP response has to be signed by the issuing certificate, in which case no certificates need to be included in the OCSP response, or it must be signed with a delegated OCSP responder certificate that is directly issued by the issuing certificate, in which case only one certificate is required. It seems to me like a correct implementation of OCSP response verification should never need more than one certificate in a reasonably-produced OCSP response, at least in the way that such things are used by browsers.
[IdenTrust Response]
> The OCSP responders both include too many certificates, this has a performance impact for your users; no need to include intermediate and root certificates in the response. Not a blocker.
> [IdenTrust] You are correct that there is some performance impact.
> However, this approach is consistent with the RFC 6960 section 4.2.2 - Basic Response: "The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature."
> In our experience, SSL certificates are used by clients other than browsers; and, unfortunately, some clients are not able to do proper path construction. For those cases, and we have had some, we provide those certificates.
How does this fit with Section 4.2.2.2, though? Either the OCSP response has to be signed by the issuing certificate, in which case no certificates need to be included in the OCSP response, or it must be signed with a delegated OCSP responder certificate that is directly issued by the issuing certificate, in which case only one certificate is required. It seems to me like a correct implementation of OCSP response verification should never need more than one certificate in a reasonably-produced OCSP response, at least in the way that such things are used by browsers.
Brian,
Thank you for your comment.
IdenTrust uses delegated OCSP for the subordinate CA and Root CA, which is contemplated in Section 4.2.2.2. From the perspective of SSL certificates used within the browser context, we concur with your point and any certificate other than the OCSP signer is unnecessary.
Our current implementation, however, includes use cases where SSL certificates, or device certificates, are used by legacy applications that need the additional certificates to perform proper validation. With this said, we are evaluating whether separating those offerings make business sense. In the end, we believe the OCSP responses provided by our system are RFC compliant though not as efficient as possible for the browser context.
Kathleen Wilson
Nov 23, 2014, 10:35:03 AM11/23/14
to mozilla-dev-s...@lists.mozilla.org
On 11/20/14 3:19 PM, kirk...@trendmicro.com wrote:
> Kathleen, out of curiosity -- what's the difference between a "Root Renewal Request" and a simple request to add a new root to the Mozilla root store? Are they essentially the same process, or is a root renewal request treated differently?
>
Same process.
> Kathleen, out of curiosity -- what's the difference between a "Root Renewal Request" and a simple request to add a new root to the Mozilla root store? Are they essentially the same process, or is a root renewal request treated differently?
>
The only difference is that there are two different queues for public
discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Currently-included CAs get priority over new CAs regarding the
discussions, and I will have up to 4 concurrent discussions for
currently-included CAs. But for new CAs I try to keep it to one
discussion at a time. As you can see from the discussion queues the
queue for new CAs is smaller than the queue for currently-included CAs.
Kathleen
Renne Rodriguez
Dec 2, 2014, 2:39:58 PM12/2/14
to Erwann Abalea, mozilla-dev-s...@lists.mozilla.org
> Comment 3:
> The OCSP responders both include too many certificates, this has a performance impact for your users; no need to include intermediate and root certificates in the response. Not a blocker.
> [IdenTrust] You are correct that there is some performance impact.
> However, this approach is consistent with the RFC 6960 section 4.2.2 - Basic Response: "The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature."
> In our experience, SSL certificates are used by clients other than browsers; and, unfortunately, some clients are not able to do proper path construction. For those cases, and we have had some, we provide those certificates.
> The OCSP responders both include too many certificates, this has a performance impact for your users; no need to include intermediate and root certificates in the response. Not a blocker.
> [IdenTrust] You are correct that there is some performance impact.
> However, this approach is consistent with the RFC 6960 section 4.2.2 - Basic Response: "The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature."
> In our experience, SSL certificates are used by clients other than browsers; and, unfortunately, some clients are not able to do proper path construction. For those cases, and we have had some, we provide those certificates.
I've read that argument before for some Java software, where the client sets issuerKeyHash with an empty value and only populates the issuerNameHash field.
Including the whole certificate chain isn't forbidden, of course. But I'd be tempted to say that those RP should die. This minority forces a penalty to be paid by the majority (browsers, good players). In order to lower that penalty, you could maybe consider to not include the root in the response. What value could have a root certificate transmitted that way, since trust in a TA MUST come out-of-band?
[IdenTrust Answer]
Including the whole certificate chain isn't forbidden, of course. But I'd be tempted to say that those RP should die. This minority forces a penalty to be paid by the majority (browsers, good players). In order to lower that penalty, you could maybe consider to not include the root in the response. What value could have a root certificate transmitted that way, since trust in a TA MUST come out-of-band?
Eventually, those RP will change their behavior. In the meantime, we need to maintain the behavior as it is. As I responded to Brian Smith, we are actively considering separation of our offerings to minimize the impact to our SSL customers as it has been suggested here.
> Comment 4:
> The OCSP responders answer "unknown" when asked to verify the 2 given intermediate certificates. Not a blocker, but probably not expected.
> [IdenTrust] Our configuration was incorrect in the OCSP. We have corrected it and you should be able to receive the appropriate responses.
That seems to be done for the "Commercial" root, but not for the "Public" root. Trying to validate certificate for intermediate CA "IdenTrust ACES CA 2" still gives an unknown answer.
[IdenTrust Answer]
We have made changes to the certificates linking back to the Public root, and they only include one OID consistent with the RFC. Going forward, we will have two approaches that are considered valid in the RFC. In other words, we will not include the CAB Forum OID in the end entity certificate unless it is in the subordinate CA explicitly or through the AnyPolicy value.
The IdenTrust ACES CA 2 should provide the correct response now.
Kathleen Wilson
Dec 16, 2014, 2:29:50 PM12/16/14
to mozilla-dev-s...@lists.mozilla.org
On 10/30/14 11:16 AM, Kathleen Wilson wrote:
> IdenTrust has applied to include the “IdenTrust Commercial Root CA 1”
> and “IdenTrust Public Sector Root CA 1” root certificates, and turn on
> the Websites and Email trust bits for both. The “IdenTrust Commercial
> Root CA 1” root will eventually replace the “DST Root X3” certificate,
> and the “IdenTrust Public Sector Root CA 1” root will eventually replace
> the “DST ACES X6” certificate. Both of the currently-included root
> certificates were included via Bugzilla Bug #394733.
>
Thanks to all of you who have reviewed and commented on this request. I
> IdenTrust has applied to include the “IdenTrust Commercial Root CA 1”
> and “IdenTrust Public Sector Root CA 1” root certificates, and turn on
> the Websites and Email trust bits for both. The “IdenTrust Commercial
> Root CA 1” root will eventually replace the “DST Root X3” certificate,
> and the “IdenTrust Public Sector Root CA 1” root will eventually replace
> the “DST ACES X6” certificate. Both of the currently-included root
> certificates were included via Bugzilla Bug #394733.
>
believe that all of the questions and comments about this request have
been resolved, so I am planning to recommend approval in the bug.
Thanks,
Kathleen
Kathleen Wilson
Dec 17, 2014, 3:05:05 PM12/17/14
to mozilla-dev-s...@lists.mozilla.org
https://bugzilla.mozilla.org/show_bug.cgi?id=1037590
Any further follow-up on this request should be added directly to the bug.
Thanks,
Kathleen
0 new messages