Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Swisscom Request to include Renewed Roots
328 views
Skip to first unread message
Kathleen Wilson
Dec 17, 2012, 5:17:20 PM12/17/12
to mozilla-dev-s...@lists.mozilla.org
Swisscom has applied to add the “Swisscom Root CA 2” root certificate,
which will eventually replace the “Swisscom Root CA 1” root certificate
that was included in NSS as per bug #342470. This request is to turn on
all three trust bits for this new root cert. Swisscom has also requested
to add the “Swisscom Root EV CA 2” root certificate, turn on the
websites and code signing trust bits, and enable EV.
Swisscom is a commercial CSP that provides certification services for
individual and corporate customers. Swisscom operates a certificate
authority and registration authority. Customers may choose to use the
registration services of Swisscom and purchase single certificates.
Customers may also choose to operate their own registration authority
(managed PKI).
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=759732
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Swisscom
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=679809
Noteworthy points:
* The primary documents are the CPS, which has been translated into
English, and the CP documents which are in German and some sections have
been translated into English.
Document Repository:
http://www.swissdigicert.ch/sdcs/portal/page?node=download_docs
CPS (English):
http://www.swissdigicert.ch/sdcs/portal/download_file?file=english%2F002_CPS_Swisscom_Digital_Certificate_Services_2_16_756_83_2_1_V2_2_en.pdf
Emerald CP (German):
http://www.swissdigicert.ch/sdcs/portal/download_file?file=deutsch%2F007_CP_Smaragd_SDCS_2_16_756_1_83_3_V2_2b_de.pdf
EV CPS (German):
http://www.swissdigicert.ch/sdcs/portal/download_file?file=deutsch%2F102_CPS_SDCS_EV_2_16_756_1_83_2_2_V2_1_de.pdf
EV CP (German, English Translations of certain sections provided in
Appendix):
http://www.swissdigicert.ch/sdcs/portal/download_file?file=deutsch%2F008_CP_Quartz_EV_SDCS_2_16_756_1_83_4_V2_3_de_en.pdf
Sapphire CP (German):
http://www.swissdigicert.ch/sdcs/portal/download_file?file=deutsch%2F006_CP_Saphir_SDCS_2_16_756_1_83_3_V2_0_de.pdf
Ruby CP (German):
http://www.swissdigicert.ch/sdcs/portal/open_pdf?file=deutsch%2F009_CP_Rubin_SDCS_2_16_756_1_83_4_V2_0_de.pdf
Both the “Swisscom Root CA 2” and “Swisscom Root EV CA 2” root
certificates sign internally-operated intermediate certificates that
sign entity certificates.
This request is to turn on all three trust bits for the “Swisscom Root
CA 2” certificate, and turn on the websites and code signing trust bits
for the “Swisscom Root EV CA 2” certificate.
* The Emerald CA, "Swisscom Smaragd CA 2", is the only subCA of
"Swisscom Root CA 2" that can issue SSL certs.
* Emerald CP section 3.2.3: Identity verification of a natural person or
of a legal person, for which the applicant performs a role, to apply for
advanced certificates are performed following these steps:
1. The applicant of a certificate sends one or more documents to the RA
confirming his identity.
2. An RA employee performs the identity check based on the document
provided by the applicant and documents this process.
3. For all attributes to be placed into the certificate are verified.
In case the applicant has a valid certificate, additional certificates
for that person can be requested by sending a signed and encrypted
application unless the identification of the person is still valid.
* Emerald CP section 3.2.4: Swisscom Digital Certificate Services checks
the domain name of the applicant based on a Whois query. Applicants
applying for a certificate have to submit a letter of confirmation that
is signed by the technical contact stated in the Whois extract or by
representatives of the company authorized to sign according to the
certificate of registration. A letter of confirmation is valid for two
years at most.
* CPS section 3.2.3: The E-Mail address must be verified during the
registration process. The requester must prove that he has access to the
mailbox and that he can use it to receive mail.
An organization may contractually define that all certificates using the
name of the organization in the O-field may only contain e-mail
addresses in the email-field that are in the domain of the organization.
Should such a contract exist, the organization takes full responsibility
for the proper management of e-mail accounts. Therefore, the requirement
to verify individual e-mail addresses during the registration process is
optional.
* Code Signing certificates are handled and issued under Sapphire CA –
which are smartcard based and based on the strong identification
processes of class sapphire CA.
* Sapphire CP section 3.2.2: A certificate application for a legal
entity must be submitted by a natural person, who must prove its
identity to the RA in accordance with 3.2.3.
The entitlement to apply for a certificate on behalf of an organisation
entered in the commercial register is confirmed by means of a certified
certificate of registration. In this respect, the certified certificate
of registration may not be more then three months old and the applicant
must be specified therein as being authorised to represent the
organisation, or must be in possession of a power of attorney that has
been signed by the authorised representative of the organisation. This
is especially the case if the company named in the certificate of
registration may only be represented jointly.
In the case of companies entered in the commercial register, this check
takes place on the basis of a certificate of registration that proves
that the organisation actually exists and indicates which persons are
authorised to sign on behalf of the organisation. The document submitted
must be certified and may not be more than three months old.
In the case of sole proprietorship, the check takes place on the basis
of the certificate of registration of the Swiss tax administration (as
the taxpaying one-man company is registered with the Swiss tax
authorities) or a registered VAT identification number.
In the case of simple partnerships, the check takes place on the basis
of the deed of partnership as well as the certificate of registration of
the Swiss tax administration (as the taxpaying simple partnership is
registered with the Swiss tax authorities) or a registered VAT
identification number. If the partners are legal entities, the check
takes place on the basis of the corresponding certificates of registration.
Entitlement to apply for a certificate on behalf of a simple partnership
is confirmed on the basis of the contract of partnership. The applicant
must be named as a partner in the contract of partnership or be
authorised by said partner.
The request is to also enable EV for the “Swisscom Root EV CA 2”
certificate.
* EV CP section 3.2.3: Companies listed in the commercial register are
checked based on the excerpt from the commercial register that the
organization actually exists and which persons are authorized to sign
for that organization. The document submitted must be certified and must
not be older than one year.
To obtain an EV certificate a company has to be in one of the following
countries in the Commercial Register:
Switzerland
Companies not registered in Switzerland must submit documentations that
allow comparable identification of the company.
EV CP section 3.2.8: Swisscom Digital Certificate Services checks the
domain name of the applicant via a Whois query. The applicant must
submit for an EV certificate request a written confirmation signed by
the technical contact of the Whois statement.
In case the domain name of the applicant is not listed, but looks
similar to the name of a known domain then the name lists of potential
phishing attack targets maintained by the Anti-Phishing Workgroup are
tested.
* EV Policy OID: 2.16.756.1.83.21.0
* Root Cert URLs
http://aia.swissdigicert.ch/sdcs-root2.crt
http://www.swissdigicert.ch/download/sdcs-root2-ev.crt
* Test Websites
https://test-emerald-ca-2.pre.swissdigicert.ch
https://test-quarz-ev-ca-2.pre.swissdigicert.ch
* CRL
http://crl.swissdigicert.ch/sdcs-root2.crl
http://crl.swissdigicert.ch/sdcs-saphir2.crl
http://crl.swissdigicert.ch/sdcs-smaragd2.crl
http://crl.swissdigicert.ch/sdcs-root2-ev.crl
http://crl.swissdigicert.ch/sdcs-quarz2-ev.crl
CPS section 4.9: CRLs published at least once a day.
* OCSP:
http://ocsp.swissdigicert.ch/sdcs-saphir2
http://ocsp.swissdigicert.ch/sdcs-smaragd2
http://ocsp.swissdigicert.ch/root2-ev
http://ocsp.swissdigicert.ch/quartz2
* Audit: Swisscom is audited by KPMG according to the ETSI 101 456 and
WebTrust EV criteria. The WebTrust EV audit statement was attached to
the bug: https://bugzilla.mozilla.org/attachment.cgi?id=667939
I confirmed the audit statements by exchanging email with a
representative of KPMG.
Swisscom is also listed on the SECO website:
http://www.seco.admin.ch/sas/00229/00251/index.html?lang=en
ZertES is granted by the Swiss Accreditation Service (SAS) and the Swiss
Federal Office of Communications (BAKOM) based on an audit by KPMG. It
is based on Swiss law and on ETSI standards for Qualified Certification
Service Providers (CSP) and Time Stamping Authorities. It requires an
annual audit.
* Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices)
** Delegation of Domain / Email validation to third parties
As stated in the CPS Enterprise RAs might be able to issue up to any
kind of certificates. If they want to issue qualified certificates the
Enterprise RA has to pass the KPMG audit prior to this. For all other
kind of certificate classes the Enterprise RA has beforehand to pass the
Swisscom audit. All referred processes are audited by KPMG.
*** CPS (English) section 1.3.2 Registration Authorities (RAs):
The Swisscom (Schweiz) AG business model is based on a registration
authorities (hereinafter RA) contractual partner model. Contractual
partners of Swisscom (Schweiz) AG assume the role of RA.
The RA partner is free to choose whether to issue certificates within
its organisation only or to also act as a “public” RA.
RA partners are obliged by the terms of a Service Level Agreement (SLA)
to comply with the processes defined by Swisscom for the registration,
issuance and revocation of certificates. If the RA partner also wishes
to issue qualified certificates it is incorporated in the authorisation
process by a certification authority accredited by the Swiss
Accreditation Service (SAS). If the RA partner only issues advanced
certificates, it is audited by Swisscom at least one a year.
The Swisscom (Schweiz) AG business model differentiates the following
types of RA:
- Swisscom RA: For issuing certificates for own use and downstream RAs
(E-RA)
- E-RA: (Enterprise Registration Authority) is an RA partner authorised
to create and issue SSCDs and certificates directly.
- TPS: (Trusted Point of Sale) is an RA partner which, as a registration
authority, receives and checks the details of certificate applications.
SSCDs for the “Diamond” and “Sapphire” certificate classes are
personalised and distributed by an E-RA or a central distribution point.
Note: Swisscom’s business model is focused on B2B, so they currently
don't have any public registration authorities.
This begins the discussion of the request from Swisscom to add the
“Swisscom Root CA 2” and “Swisscom Root EV CA 2” root certificates, turn
on all three trust bits for the “Swisscom Root CA 2” certificate, turn
on the websites and code signing trust bits for the “Swisscom Root EV CA
2” certificate, and enable EV for the “Swisscom Root EV CA 2” certificate.
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
which will eventually replace the “Swisscom Root CA 1” root certificate
that was included in NSS as per bug #342470. This request is to turn on
all three trust bits for this new root cert. Swisscom has also requested
to add the “Swisscom Root EV CA 2” root certificate, turn on the
websites and code signing trust bits, and enable EV.
Swisscom is a commercial CSP that provides certification services for
individual and corporate customers. Swisscom operates a certificate
authority and registration authority. Customers may choose to use the
registration services of Swisscom and purchase single certificates.
Customers may also choose to operate their own registration authority
(managed PKI).
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=759732
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Swisscom
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=679809
Noteworthy points:
* The primary documents are the CPS, which has been translated into
English, and the CP documents which are in German and some sections have
been translated into English.
Document Repository:
http://www.swissdigicert.ch/sdcs/portal/page?node=download_docs
CPS (English):
http://www.swissdigicert.ch/sdcs/portal/download_file?file=english%2F002_CPS_Swisscom_Digital_Certificate_Services_2_16_756_83_2_1_V2_2_en.pdf
Emerald CP (German):
http://www.swissdigicert.ch/sdcs/portal/download_file?file=deutsch%2F007_CP_Smaragd_SDCS_2_16_756_1_83_3_V2_2b_de.pdf
EV CPS (German):
http://www.swissdigicert.ch/sdcs/portal/download_file?file=deutsch%2F102_CPS_SDCS_EV_2_16_756_1_83_2_2_V2_1_de.pdf
EV CP (German, English Translations of certain sections provided in
Appendix):
http://www.swissdigicert.ch/sdcs/portal/download_file?file=deutsch%2F008_CP_Quartz_EV_SDCS_2_16_756_1_83_4_V2_3_de_en.pdf
Sapphire CP (German):
http://www.swissdigicert.ch/sdcs/portal/download_file?file=deutsch%2F006_CP_Saphir_SDCS_2_16_756_1_83_3_V2_0_de.pdf
Ruby CP (German):
http://www.swissdigicert.ch/sdcs/portal/open_pdf?file=deutsch%2F009_CP_Rubin_SDCS_2_16_756_1_83_4_V2_0_de.pdf
Both the “Swisscom Root CA 2” and “Swisscom Root EV CA 2” root
certificates sign internally-operated intermediate certificates that
sign entity certificates.
This request is to turn on all three trust bits for the “Swisscom Root
CA 2” certificate, and turn on the websites and code signing trust bits
for the “Swisscom Root EV CA 2” certificate.
* The Emerald CA, "Swisscom Smaragd CA 2", is the only subCA of
"Swisscom Root CA 2" that can issue SSL certs.
* Emerald CP section 3.2.3: Identity verification of a natural person or
of a legal person, for which the applicant performs a role, to apply for
advanced certificates are performed following these steps:
1. The applicant of a certificate sends one or more documents to the RA
confirming his identity.
2. An RA employee performs the identity check based on the document
provided by the applicant and documents this process.
3. For all attributes to be placed into the certificate are verified.
In case the applicant has a valid certificate, additional certificates
for that person can be requested by sending a signed and encrypted
application unless the identification of the person is still valid.
* Emerald CP section 3.2.4: Swisscom Digital Certificate Services checks
the domain name of the applicant based on a Whois query. Applicants
applying for a certificate have to submit a letter of confirmation that
is signed by the technical contact stated in the Whois extract or by
representatives of the company authorized to sign according to the
certificate of registration. A letter of confirmation is valid for two
years at most.
* CPS section 3.2.3: The E-Mail address must be verified during the
registration process. The requester must prove that he has access to the
mailbox and that he can use it to receive mail.
An organization may contractually define that all certificates using the
name of the organization in the O-field may only contain e-mail
addresses in the email-field that are in the domain of the organization.
Should such a contract exist, the organization takes full responsibility
for the proper management of e-mail accounts. Therefore, the requirement
to verify individual e-mail addresses during the registration process is
optional.
* Code Signing certificates are handled and issued under Sapphire CA –
which are smartcard based and based on the strong identification
processes of class sapphire CA.
* Sapphire CP section 3.2.2: A certificate application for a legal
entity must be submitted by a natural person, who must prove its
identity to the RA in accordance with 3.2.3.
The entitlement to apply for a certificate on behalf of an organisation
entered in the commercial register is confirmed by means of a certified
certificate of registration. In this respect, the certified certificate
of registration may not be more then three months old and the applicant
must be specified therein as being authorised to represent the
organisation, or must be in possession of a power of attorney that has
been signed by the authorised representative of the organisation. This
is especially the case if the company named in the certificate of
registration may only be represented jointly.
In the case of companies entered in the commercial register, this check
takes place on the basis of a certificate of registration that proves
that the organisation actually exists and indicates which persons are
authorised to sign on behalf of the organisation. The document submitted
must be certified and may not be more than three months old.
In the case of sole proprietorship, the check takes place on the basis
of the certificate of registration of the Swiss tax administration (as
the taxpaying one-man company is registered with the Swiss tax
authorities) or a registered VAT identification number.
In the case of simple partnerships, the check takes place on the basis
of the deed of partnership as well as the certificate of registration of
the Swiss tax administration (as the taxpaying simple partnership is
registered with the Swiss tax authorities) or a registered VAT
identification number. If the partners are legal entities, the check
takes place on the basis of the corresponding certificates of registration.
Entitlement to apply for a certificate on behalf of a simple partnership
is confirmed on the basis of the contract of partnership. The applicant
must be named as a partner in the contract of partnership or be
authorised by said partner.
The request is to also enable EV for the “Swisscom Root EV CA 2”
certificate.
* EV CP section 3.2.3: Companies listed in the commercial register are
checked based on the excerpt from the commercial register that the
organization actually exists and which persons are authorized to sign
for that organization. The document submitted must be certified and must
not be older than one year.
To obtain an EV certificate a company has to be in one of the following
countries in the Commercial Register:
Switzerland
Companies not registered in Switzerland must submit documentations that
allow comparable identification of the company.
EV CP section 3.2.8: Swisscom Digital Certificate Services checks the
domain name of the applicant via a Whois query. The applicant must
submit for an EV certificate request a written confirmation signed by
the technical contact of the Whois statement.
In case the domain name of the applicant is not listed, but looks
similar to the name of a known domain then the name lists of potential
phishing attack targets maintained by the Anti-Phishing Workgroup are
tested.
* EV Policy OID: 2.16.756.1.83.21.0
* Root Cert URLs
http://aia.swissdigicert.ch/sdcs-root2.crt
http://www.swissdigicert.ch/download/sdcs-root2-ev.crt
* Test Websites
https://test-emerald-ca-2.pre.swissdigicert.ch
https://test-quarz-ev-ca-2.pre.swissdigicert.ch
* CRL
http://crl.swissdigicert.ch/sdcs-root2.crl
http://crl.swissdigicert.ch/sdcs-saphir2.crl
http://crl.swissdigicert.ch/sdcs-smaragd2.crl
http://crl.swissdigicert.ch/sdcs-root2-ev.crl
http://crl.swissdigicert.ch/sdcs-quarz2-ev.crl
CPS section 4.9: CRLs published at least once a day.
* OCSP:
http://ocsp.swissdigicert.ch/sdcs-saphir2
http://ocsp.swissdigicert.ch/sdcs-smaragd2
http://ocsp.swissdigicert.ch/root2-ev
http://ocsp.swissdigicert.ch/quartz2
* Audit: Swisscom is audited by KPMG according to the ETSI 101 456 and
WebTrust EV criteria. The WebTrust EV audit statement was attached to
the bug: https://bugzilla.mozilla.org/attachment.cgi?id=667939
I confirmed the audit statements by exchanging email with a
representative of KPMG.
Swisscom is also listed on the SECO website:
http://www.seco.admin.ch/sas/00229/00251/index.html?lang=en
ZertES is granted by the Swiss Accreditation Service (SAS) and the Swiss
Federal Office of Communications (BAKOM) based on an audit by KPMG. It
is based on Swiss law and on ETSI standards for Qualified Certification
Service Providers (CSP) and Time Stamping Authorities. It requires an
annual audit.
* Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices)
** Delegation of Domain / Email validation to third parties
As stated in the CPS Enterprise RAs might be able to issue up to any
kind of certificates. If they want to issue qualified certificates the
Enterprise RA has to pass the KPMG audit prior to this. For all other
kind of certificate classes the Enterprise RA has beforehand to pass the
Swisscom audit. All referred processes are audited by KPMG.
*** CPS (English) section 1.3.2 Registration Authorities (RAs):
The Swisscom (Schweiz) AG business model is based on a registration
authorities (hereinafter RA) contractual partner model. Contractual
partners of Swisscom (Schweiz) AG assume the role of RA.
The RA partner is free to choose whether to issue certificates within
its organisation only or to also act as a “public” RA.
RA partners are obliged by the terms of a Service Level Agreement (SLA)
to comply with the processes defined by Swisscom for the registration,
issuance and revocation of certificates. If the RA partner also wishes
to issue qualified certificates it is incorporated in the authorisation
process by a certification authority accredited by the Swiss
Accreditation Service (SAS). If the RA partner only issues advanced
certificates, it is audited by Swisscom at least one a year.
The Swisscom (Schweiz) AG business model differentiates the following
types of RA:
- Swisscom RA: For issuing certificates for own use and downstream RAs
(E-RA)
- E-RA: (Enterprise Registration Authority) is an RA partner authorised
to create and issue SSCDs and certificates directly.
- TPS: (Trusted Point of Sale) is an RA partner which, as a registration
authority, receives and checks the details of certificate applications.
SSCDs for the “Diamond” and “Sapphire” certificate classes are
personalised and distributed by an E-RA or a central distribution point.
Note: Swisscom’s business model is focused on B2B, so they currently
don't have any public registration authorities.
This begins the discussion of the request from Swisscom to add the
“Swisscom Root CA 2” and “Swisscom Root EV CA 2” root certificates, turn
on all three trust bits for the “Swisscom Root CA 2” certificate, turn
on the websites and code signing trust bits for the “Swisscom Root EV CA
2” certificate, and enable EV for the “Swisscom Root EV CA 2” certificate.
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
Feb 27, 2013, 7:53:26 PM2/27/13
to mozilla-dev-s...@lists.mozilla.org
Please review and comment on this request from Swisscom to add their
next generation root certificate and an EV root certificate.
If no concerns are raised, then early next week I plan to close this
discussion and recommend approval in the bug.
Thanks,
Kathleen
Erwann Abalea
Mar 1, 2013, 10:06:27 AM3/1/13
to
Le lundi 17 décembre 2012 23:17:20 UTC+1, Kathleen Wilson a écrit :
[...]
The first one maps issuing domain policy 2.16.756.1.83.2.1 with issued domain policy 2.16.756.1.83.2.1 (issuing domain and issued domain are the same here because it's a self-signed certificate, and the policies are identical).
The second one does the same with policy 2.16.756.1.83.2.2.
This extension is of no use in a trust anchor, and those particular mappings mean nothing.
Other than that, they're harmless.
The issuer certificates referenced (http://aia.swissdigicert.ch/sdcs-smaragd2.crt and http://aia.swissdigicert.ch/sdcs-root2.crt) are sent in PEM format instead of DER format, contrary to what is stated in CPS (section 6.1.4), and to normative documents (RFC5280 4.2.2.1).
> https://test-quarz-ev-ca-2.pre.swissdigicert.ch
Same remark about the other URLs found in AuthorityInfoAccess extensions.
In the english CPS, the certificate profile presented in 7.1.2 doesn't match the root certificate (a CertificatePolicies extension is described, and a PolicyMappings is found in the certificate).
[...]
> * EV Policy OID: 2.16.756.1.83.21.0
>
> * Root Cert URLs
> http://aia.swissdigicert.ch/sdcs-root2.crt
> http://www.swissdigicert.ch/download/sdcs-root2-ev.crt
Why are there policyMappings extensions in these root certificates, with a useless mapping?
>
> * Root Cert URLs
> http://aia.swissdigicert.ch/sdcs-root2.crt
> http://www.swissdigicert.ch/download/sdcs-root2-ev.crt
The first one maps issuing domain policy 2.16.756.1.83.2.1 with issued domain policy 2.16.756.1.83.2.1 (issuing domain and issued domain are the same here because it's a self-signed certificate, and the policies are identical).
The second one does the same with policy 2.16.756.1.83.2.2.
This extension is of no use in a trust anchor, and those particular mappings mean nothing.
Other than that, they're harmless.
The issuer certificates referenced (http://aia.swissdigicert.ch/sdcs-smaragd2.crt and http://aia.swissdigicert.ch/sdcs-root2.crt) are sent in PEM format instead of DER format, contrary to what is stated in CPS (section 6.1.4), and to normative documents (RFC5280 4.2.2.1).
> https://test-quarz-ev-ca-2.pre.swissdigicert.ch
Same remark about the other URLs found in AuthorityInfoAccess extensions.
In the english CPS, the certificate profile presented in 7.1.2 doesn't match the root certificate (a CertificatePolicies extension is described, and a PolicyMappings is found in the certificate).
patrick....@gmail.com
Mar 8, 2013, 7:40:32 AM3/8/13
to
patrick....@gmail.com
Mar 15, 2013, 10:44:07 AM3/15/13
to
On Friday, March 1, 2013 4:06:27 PM UTC+1, Erwann Abalea wrote:
> Le lundi 17 décembre 2012 23:17:20 UTC+1, Kathleen Wilson a écrit :
>
> [...]
>
> > * EV Policy OID: 2.16.756.1.83.21.0
>
> >
>
> > * Root Cert URLs
>
> > http://aia.swissdigicert.ch/sdcs-root2.crt
>
> > http://www.swissdigicert.ch/download/sdcs-root2-ev.crt
>
>
>
> Why are there policyMappings extensions in these root certificates, with a useless mapping?
>
> The first one maps issuing domain policy 2.16.756.1.83.2.1 with issued domain policy 2.16.756.1.83.2.1 (issuing domain and issued domain are the same here because it's a self-signed certificate, and the policies are identical).
>
> The second one does the same with policy 2.16.756.1.83.2.2.
>
> This extension is of no use in a trust anchor, and those particular mappings mean nothing.
>
> Other than that, they're harmless.
>
As you mention the root certificates are self signed certificates and therefore the issuerDomainPolicy and the issuerDomainPolicy are the same (RFC 5280 4.2.1.5).
>
> [...]
>
> > * EV Policy OID: 2.16.756.1.83.21.0
>
> >
>
> > * Root Cert URLs
>
> > http://aia.swissdigicert.ch/sdcs-root2.crt
>
> > http://www.swissdigicert.ch/download/sdcs-root2-ev.crt
>
>
>
> Why are there policyMappings extensions in these root certificates, with a useless mapping?
>
> The first one maps issuing domain policy 2.16.756.1.83.2.1 with issued domain policy 2.16.756.1.83.2.1 (issuing domain and issued domain are the same here because it's a self-signed certificate, and the policies are identical).
>
> The second one does the same with policy 2.16.756.1.83.2.2.
>
> This extension is of no use in a trust anchor, and those particular mappings mean nothing.
>
> Other than that, they're harmless.
>
>
>
> > * Test Websites
>
> > https://test-emerald-ca-2.pre.swissdigicert.ch
>
>
>
> The issuer certificates referenced (http://aia.swissdigicert.ch/sdcs-smaragd2.crt and http://aia.swissdigicert.ch/sdcs-root2.crt) are sent in PEM format instead of DER format, contrary to what is stated in CPS (section 6.1.4), and to normative documents (RFC5280 4.2.2.1).
>
>
>
> > https://test-quarz-ev-ca-2.pre.swissdigicert.ch
>
>
>
> Same remark about the other URLs found in AuthorityInfoAccess extensions.
>
>
>
> In the english CPS, the certificate profile presented in 7.1.2 doesn't match the root certificate (a CertificatePolicies extension is described, and a PolicyMappings is found in the certificate).
Kathleen Wilson
Mar 15, 2013, 7:52:59 PM3/15/13
to mozilla-dev-s...@lists.mozilla.org
> Swisscom has applied to add the “Swisscom Root CA 2” root certificate,
> which will eventually replace the “Swisscom Root CA 1” root certificate
> that was included in NSS as per bug #342470. This request is to turn on
> all three trust bits for this new root cert. Swisscom has also requested
> to add the “Swisscom Root EV CA 2” root certificate, turn on the
> websites and code signing trust bits, and enable EV.
Thank you, Erwann, for reviewing and commenting on this request. I
> which will eventually replace the “Swisscom Root CA 1” root certificate
> that was included in NSS as per bug #342470. This request is to turn on
> all three trust bits for this new root cert. Swisscom has also requested
> to add the “Swisscom Root EV CA 2” root certificate, turn on the
> websites and code signing trust bits, and enable EV.
believe that Patrick's response addresses the items that you noted.
Please reply if you disagree.
If there are no other questions or comments about this request from
SwissCom, then I will close this discussion and recommend approval in
the bug.
Thanks,
Kathleen
Kathleen Wilson
Mar 20, 2013, 1:24:55 PM3/20/13
to mozilla-dev-s...@lists.mozilla.org
On 3/15/13 4:52 PM, Kathleen Wilson wrote:
>> Swisscom has applied to add the �Swisscom Root CA 2� root certificate,
>> which will eventually replace the �Swisscom Root CA 1� root certificate
discussion about the request from Swisscom to add the �Swisscom Root CA
2� and �Swisscom Root EV CA 2� root certificates, turn on all three
trust bits for the �Swisscom Root CA 2� certificate, turn on the
websites and code signing trust bits for the �Swisscom Root EV CA 2�
certificate, and enable EV for the �Swisscom Root EV CA 2� certificate.
I am closing this discussion, and I will recommend approval in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=759732
Any further follow-up on this request should be added directly to the bug.
Thanks,
Kathleen
>> Swisscom has applied to add the �Swisscom Root CA 2� root certificate,
>> which will eventually replace the �Swisscom Root CA 1� root certificate
>> that was included in NSS as per bug #342470. This request is to turn on
>> all three trust bits for this new root cert. Swisscom has also requested
>> to add the �Swisscom Root EV CA 2� root certificate, turn on the
>> all three trust bits for this new root cert. Swisscom has also requested
>> websites and code signing trust bits, and enable EV.
>
>
> Thank you, Erwann, for reviewing and commenting on this request. I
> believe that Patrick's response addresses the items that you noted.
> Please reply if you disagree.
>
> If there are no other questions or comments about this request from
> SwissCom, then I will close this discussion and recommend approval in
> the bug.
>
> Thanks,
> Kathleen
>
Thank you to those of you who reviewed and contributed to this
>
>
> Thank you, Erwann, for reviewing and commenting on this request. I
> believe that Patrick's response addresses the items that you noted.
> Please reply if you disagree.
>
> If there are no other questions or comments about this request from
> SwissCom, then I will close this discussion and recommend approval in
> the bug.
>
> Thanks,
> Kathleen
>
discussion about the request from Swisscom to add the �Swisscom Root CA
2� and �Swisscom Root EV CA 2� root certificates, turn on all three
trust bits for the �Swisscom Root CA 2� certificate, turn on the
websites and code signing trust bits for the �Swisscom Root EV CA 2�
certificate, and enable EV for the �Swisscom Root EV CA 2� certificate.
I am closing this discussion, and I will recommend approval in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=759732
Any further follow-up on this request should be added directly to the bug.
Thanks,
Kathleen
0 new messages