Second Discussion of KIR S.A. Root Inclusion Request

[Kathleen Wilson]

Krajowa Izba Rozliczeniowa (KIR) S.A. has applied to include the "SZAFIR
ROOT CA" root certificate and enable all three trust bits.

The first discussion is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/aNbK4zw_Zb8/ekmVXYXvfQ4J

The action items resulting from the first discussion are listed here:
https://bugzilla.mozilla.org/show_bug.cgi?id=817994#c37

I have confirmed completion of the action items.

For your convenience, I will re-summarize the request below.

KIR S.A. is a private corporation in Poland which currently mainly
issues qualified certificates for general public and plans to issue
non-qualified certificates. KIR S.A. is an automated clearing house in
Poland and its core business is clearings, and has built numerous
business relationships within banking sector. Therefore, KIR S.A is
aiming to expand its sales in services such as SSL and VPN certificates.
KIR S.A has another line of products called PayByNet, and has created a
vast network of relationships within online stores that KIR S.A can
leverage to create customer base for trusted non-qualified certificates.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=817994

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=8559351

Noteworthy points:

* The primary documents, the CP and CPS, are provided in both English
and Polish.

Document Repository:
http://eng.elektronicznypodpis.pl/en/information/documents-and-agreements
CPS:
http://www.elektronicznypodpis.pl/files/doc/certification_practice_statement.pdf
CP: http://elektronicznypodpis.pl/files/doc/certification_policy.pdf

* CA Hierarchy: There is currently one internally-operated
subordinate-CA which issues 6 types of end-user certificates:
- Standard certificate - For protection of information sent
electronically, using mainly e-mail, for authorizing access to systems,
customer authentication in SSL connections. It allows signing and
encrypting data in an electronic form and authenticating subscribers.
- Code signing certificate
- VPN certificate
- SSL certificate
- Test certificate - For testing co-operation of the certificate with
solutions used or developed by a recipient of certification services or
a subscriber.
- ELIXIR certificate - This kind of certificates are issued only for
Participants of ELIXIR and EuroELIXIR systems. Will start to issue all
Elixir certs including the EKU extension with value id-kp-clientAuth
from the 15th of February. Will update CPS to reflect this.

* The request is to enable all three trust bits.

** CPS section 3.2, Initial Identity Validation: Depending on the type
of certificate the procedure of certificate issuance may be different
and is relative to a specific certification policy.
To receive a certificate it is necessary for the subscriber who is a
natural person or an authorised representative of the recipient of
certification services to present:
1) an identification card (or its photocopy depending on the type of
certificate);
2) documents confirming rights to the domain (optionally, relative to
the certificate type);
3) a file with the certificate request (if the pair of keys is generated
individually by the subscriber).
KIR S.A. may expect presentation of other documents, in case entering
data other than the subscriber's first name and surname and the PESEL or
NIP number into the certificate is requested.

** CPS section 3.2.2: If a certificate is to provide for security of
electronic mail, verification of the electronic mail address shall be
done. Verification shall consist in checking if an electronic mail
address indicated in the order belongs to the subscriber. Checking may
be done by confirming that the subscriber has collected authentication
data sent to an electronic mail address given in the order. Checking is
to determine that the e-mail address is legally used by the subscriber.

** CPS section 3.2.2: If an SSL certificate and a test certificate is to
contain a domain name, checking shall include if a recipient of
certification services has the right to use the domain name and if the
domain remains under its control. Verification performed by KIR S.A.
shall comprise:
- checking in publicly available WHOIS services or directly with
entities registering domains, if a recipient of certification services
is registered as a domain owner or has the right to use the domain name;
- checking, if a response has been sent to an e-mail sent by KIR to the
domain administrator to an e-mail address of the administrator domain
containing webmaster, admin, administrator, hostmaster, postmster before
@domena or an e-mail address indicated as the address for contacts for a
specific domain in the WHOIS service or the register of domains;
- checking, if verification data indicated by KIR S.A. has been placed
on a server or in a record such as TXT in DNS;
- in case of Wildcard Certificates checking if in the "public suffix
list" (PSL) register http://publicsuffix.org/ (PSL), the sign "*" is not
put in the first place on the left-hand side of the suffix of gTLD
domains delegated by ICANN. KIR S.A. may issue a Wildcard Certificate
for gTLD domains, if the subscriber properly proves its right to manage
the entire space of names under the gTLD domain.
To minimise the risk of using inappropriate data KIR S.A. shall use data
presented in the WHOIS service in combination with IANA data and the
WHOIS data supplied by ICCAN approved entities that register domains.
If the identifier of the subscriber's certificate containing the domain
name is to include a name of the country, too, then prior to issuing the
certificate KIR S.A. shall verify if the indicated name of the country
is connected to the subscriber. Verification shall be performed in
accordance with one of the methods described below and consists in checking:
- if a domain IP address indicated in DNS is within the range of IP
addresses assigned for a country for entering of which into the
subscriber's identifier the recipient of certification services has applied;
- if the name of the country included in the information provided by an
authority registering the domain whose name is to be placed in the
certificate is compliant with the name of the country for entering of
which into the subscriber's identifier the recipient of certification
services has applied.
While verifying the name of the country KIR S.A shall check, if the
recipient of certification services does not use a proxy server to
substitute an IP address from another country in which it is actually
located.

** CP section 2.1, Standard certificate: These certificates may be used
for securing electronic mail and for logging into the systems or
services, authorising the subscriber during establishment of secure
connections.
In the process of issuing this type of certificates the operator KIR
S.A. shall verify the subscriber's identity and the right to obtain such
certificate. The certificate is delivered to the subscriber most often
with a pair of keys generated on a carrier defined by the subscriber.
Data included in the certificate allows identifying the subscriber that
uses the certificate.

** CP section 2.2: Certificates for signing codes are used for
confirming authenticity and origins of binary codes. Based on the data
included in the certificate it is possible for define the author or an
entity that provides the code for a program or application.
In the process of issuing this type of certificates the operator KIR
S.A. shall verify the subscriber's identity and the right to obtain such
certificate and shall confirm reliability of the data entered into the
certificate.

** CP section 2.4: An SSL certificate allows confirming authenticity of
www servers and setting up secure connections using SSL and TSL
protocols. A certificate may contain data of a single www server or
associated servers within a single domain.
In the process of issuing this type of certificates the operator KIR
S.A. shall verify the subscriber's identity and its right to obtain a
certificate. The process includes verification, whether the server or
domain are held by the recipient of certification services.

** CP section 2.5: Test certificate -- These certificates are used for
checking co-operation with the system or the subscriber's IT solution.
In the process of issuing this type of certificates the operator KIR
S.A. shall verify the subscriber's right to obtain such certificate. In
case, when test certificate is to serve to examine the possibility of
setting up secure connections, then process includes also verification,
if www server or domain are at the disposal of recipient of
certification services.

* EV Policy OID: Not requesting EV treatment

* Root Cert: http://www.elektronicznypodpis.pl/certyfikaty/root_ca.crt

* Test Website: https://ssl.elektronicznypodpis.pl

* OCSP: http://ocsp.elektronicznypodpis.pl

* Audit: Annual audits are performed by Ernst&Young (EY) according to
the WebTrust CA and BR criteria. The WebTrust seal file contains two
audit statements: WebTrust CA and WebTrust BR.
https://cert.webtrust.org/SealFile?seal=1681&file=pdf

* Potentially Problematic Practices – None Noted
(http://wiki.mozilla.org/CA:Problematic_Practices)

This begins the second discussion of the request from KIR S.A. to
include the "SZAFIR ROOT CA" root certificate and enable all three trust
bits. 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

[Ryan Sleevi]

On Mon, February 9, 2015 1:08 pm, Kathleen Wilson wrote:
> Krajowa Izba Rozliczeniowa (KIR) S.A. has applied to include the "SZAFIR
> ROOT CA" root certificate and enable all three trust bits.
>
> The first discussion is here:
> https://groups.google.com/d/msg/mozilla.dev.security.policy/aNbK4zw_Zb8/ekmVXYXvfQ4J
>
> The action items resulting from the first discussion are listed here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=817994#c37
>
> I have confirmed completion of the action items.
>

Questions:

>From reading the CP and CPS, I fail to see the distinction between type 3
(VPN) and type 4 (SSL) certificates (numbers from 1.4.1 of the CPS), with
respect to extendedKeyUsage and subjectAltName. That is, a VPN certificate
MAY be usable as an SSL certificate by a subscriber, without any detection
from (existing) programatic relying parties, save for the CPS. This
appears to be re-inforced by Section 3.2.2 of the CPS, which indicates
that domain validation is only followed "If an SSL certificate and a test
certificate is to contain a domain name" (i.e. explicitly not listing VPN)

Section 3.1.1 of the CPS suggests that only the DN is used to meaningfully
differentiate, but it suggests this be accomplished by including an FQDN.
For certificates that include multiple FQDNs (e.g. via SAN), the procedure
described in 3.1.1 of the CPS would either fail to apply or not detect
such situations.

Section 3.2.2 of the CPS appears to have a typo ("postmaster before @domena"

Section 3.2.2 describes a means for validating domain ownership that is
not described within Section 11.1.1 of the BR 1.2.3. In particular, it
uses the WHOIS information (described in 11.1.1 p3) in conjunction with
email (described in 11.1.1 p4) to send to a non-whitelisted address. It
may be that this is seen as an acceptable equivalent (per 11.1.1 p7), or
it may be seen that email satisfies the "Communicating directly"
requirement of 11.1.1 p3, but it was enough to be worth calling out.

Section 3.2.2 includes a further typo ("ICCAN")

Section 7.1 of the CPS details the profiles of the certificate types, but
it has all types as a single profile, with distinctions called out
proasically in "content". In particular, for the extendedKeyUsage field,
the criticality is unspecified, and it's unclear whether the VPN
certificate (which presumably uses the EKUs ipsecEndSystem, ipsecTunnel,
and ipsecUser) can also contain the clientAuth/serverAuth EKUs. It's only
listed that SSL certs can only have clientAuth/serverAuth.

Section 7.1 has a typo "SPIEC" should be "IPSEC"

The actual values of the EKUs are not enumerated, leading to possible
confusion over their symbolic names.

Section 7.1 leaves ambiguity regarding the presence of SAN for the types
of certificates issued.

Section 2 of the CP suggests that the OIDs that appear are within the
distinguished name, but this does not appear correct. The OIDs enumerated
would appear within the Certificate Policies section (if Section 7.1 is
meant to be believed)

Recommendations:
I believe a modification to the CP & CPS is needed to remedy these issues,
along with clarifications about the SSL policy being distinct from other
profiles.

In particular, the CP/CPS should make clear that the "serverAuth" EKU MUST
NOT be included in any certificate that does not conform to the "SSL"
profile.

[Peter Bowen]

On Mon, Feb 9, 2015 at 4:19 PM, Ryan Sleevi
<ryan-mozde...@sleevi.com> wrote:
> Section 3.2.2 describes a means for validating domain ownership that is
> not described within Section 11.1.1 of the BR 1.2.3. In particular, it
> uses the WHOIS information (described in 11.1.1 p3) in conjunction with
> email (described in 11.1.1 p4) to send to a non-whitelisted address. It
> may be that this is seen as an acceptable equivalent (per 11.1.1 p7), or
> it may be seen that email satisfies the "Communicating directly"
> requirement of 11.1.1 p3, but it was enough to be worth calling out.

BR 11.1.1 seems to say this is fine, as I read it:
11.1.1 p2 seems to say that "Communicating directly" can be met with an email.
11.1.1 p3 says you can use contact info in one of three types of
contacts from WHOIS

Are you suggesting that 11.1.1 p3 does not include email as a method
of Communicating directly?

Thanks,
Peter

[Certificates]

Question 1:From reading the CP and CPS, I fail to see the distinction
between type 3(VPN) and type 4 (SSL) certificates (numbers from 1.4.1 of
the CPS), withrespect to extendedKeyUsage and subjectAltName. That is, a
VPN certificateMAY be usable as an SSL certificate by a subscriber,
without any detectionfrom (existing) programatic relying parties, save for
the CPS. Thisappears to be re-inforced by Section 3.2.2 of the CPS, which
indicatesthat domain validation is only followed "If an SSL certificate
and a testcertificate is to contain a domain name" (i.e. explicitly not
listing VPN)

Answer: Domain name can be placed only in SSL certificate. So VPN cert
can not contain domain name and can’t be used as an SSL certificate. To
make it more clear we will add an explanation to table in section 3.1. „
domain name
Name of the internet domain interested in the internet DNS system for
which the certificate has been issued. * - only in case of SSL
certificates and test certificate used to test SSL connections.

--------------------
Question 2: Section 3.1.1 of the CPS suggests that only the DN is used to
meaningfullydifferentiate, but it suggests this be accomplished by
including an FQDN.For certificates that include multiple FQDNs (e.g. via
SAN), the proceduredescribed in 3.1.1 of the CPS would either fail to

apply or not detectsuch situations.

Answer:. Section 3.1.1. says:
„3.1.1. Necessity to Use Meaningful Names
The subscriber or recipient of certification services should indicate in
the certificate order data for the subscriber's distinguished name
allowing unambiguous identification of the certificate user. In
particular, the subscriber's distinguished name for an SSL certificate
should contain a Fully Qualified Domain Name (FQDN).
In the process of generating certificates, KIR S.A. shall examine whether
for the subscriber's distinguished name indicated in the order a
certificate has not been generated for another subscriber. In case
distinguished names have been repeated, with the exception of issuing
another certificate for the same subscriber, KIR S.A. may refuse issuance
of a certificate and propose a change in the subscriber's distinguished
name.”
If certificate include multiple FQDNs (SAN) we check all of them, as they
are part of subscriber's distinguished name indicated.
-------------------------
Question 3: Section 3.2.2 of the CPS appears to have a typo ("postmaster
before @domena"
Answer: Yes it is a typo in translation. Should be „@domain”. We will
correct it.

-------------------------
Question 4: Section 3.2.2 describes a means for validating domain
ownership that isnot described within Section 11.1.1 of the BR 1.2.3. In
particular, ituses the WHOIS information (described in 11.1.1 p3) in
conjunction withemail (described in 11.1.1 p4) to send to a
non-whitelisted address. Itmay be that this is seen as an acceptable
equivalent (per 11.1.1 p7), orit may be seen that email satisfies the

"Communicating directly"requirement of 11.1.1 p3, but it was enough to be
worth calling out.

Peter Bowen wrote:
BR 11.1.1 seems to say this is fine, as I read it:11.1.1 p2 seems to say

that "Communicating directly" can be met with an email.11.1.1 p3 says you
can use contact info in one of three types ofcontacts from WHOISAre you

suggesting that 11.1.1 p3 does not include email as a methodof
Communicating directly?

Odp. Nie wiem co na to odpowiedzieć.
We agree with Peter Bowen. It also our understanding of BR 11.1.1.
---------------------------------------
Question 5: Section 3.2.2 includes a further typo ("ICCAN")
Odp. Yes it’s a mistake/ typo. We will correct it.

-----------------------------------------------------
Question 6: Section 7.1 of the CPS details the profiles of the certificate
types, butit has all types as a single profile, with distinctions called
outproasically in "content". In particular, for the extendedKeyUsage
field,the criticality is unspecified, and it's unclear whether the
VPNcertificate (which presumably uses the EKUs ipsecEndSystem,
ipsecTunnel,and ipsecUser) can also contain the clientAuth/serverAuth
EKUs. It's onlylisted that SSL certs can only have clientAuth/serverAuth.

Section 7.1 has a typo "SPIEC" should be "IPSEC"
The actual values of the EKUs are not enumerated, leading to

possibleconfusion over their symbolic names.Section 7.1 leaves ambiguity

regarding the presence of SAN for the typesof certificates issued.

Answer: Yes it’s a mistake/ typo „"SPIEC"”/. We will correct it.
We will clarify it in CPS as follow:
EKU: non - critical
Standard certificates: EKU: clientAuth, emailProtecion, no domain name in
distuingishedName and subjectAltName.
Code Signing certificates: EKU: codeSigning, no domain name in
distuingishedName and subjectAltName
VPN certificates: EKU: ipsecEndSystem, ipsecTunnel,
and ipsecUser, no domain name in distuingishedName and subjectAltName.
SSL certificates: EKU: clientAuth/serverAuth, domain name reqiured in
subjectAltName.
Test certificates: EKU: clientAuth/serverAuth, domain name reqiured in
subjectAltName.
Ellixir certificates: EKU: clientAuth, no domain name in distuingishedName
and subjectAltName
Server certificates: EKU: serverAuth, no domain name in distuingishedName
and subjectAltName
-------------------------------------------
Question 7: Section 2 of the CP suggests that the OIDs that appear are
within thedistinguished name, but this does not appear correct. The OIDs
enumeratedwould appear within the Certificate Policies section (if Section

7.1 ismeant to be believed)

Answer: OIDs enumerated are not placed in certificates distinguished name,
there is certificatePolicies section in certificate profile to handle them
(as described in Section 7.1). The policy identifier (Polish:
identyfikator polityki) was translated as The Policy’s distinguished name.
We will correct it.
----------------------------

Recommendations: I believe a modification to the CP & CPS is needed to

remedy these issues,along with clarifications about the SSL policy being
distinct from otherprofiles. In particular, the CP/CPS should make clear
that the "serverAuth" EKU MUSTNOT be included in any certificate that does

not conform to the "SSL"profile.

Answer: Please, let us know if these explanations are enough. Then we will
send the draft of CPS within a week.

Section 3.2.2 describes a means for validating domain ownership that is
not described within Section 11.1.1 of the BR 1.2.3. In particular, it
uses the WHOIS information (described in 11.1.1 p3) in conjunction with
email (described in 11.1.1 p4) to send to a non-whitelisted address. It
may be that this is seen as an acceptable equivalent (per 11.1.1 p7), or
it may be seen that email satisfies the "Communicating directly"
requirement of 11.1.1 p3, but it was enough to be worth calling out.

Section 3.2.2 includes a further typo ("ICCAN")

Section 7.1 of the CPS details the profiles of the certificate types, but
it has all types as a single profile, with distinctions called out
proasically in "content". In particular, for the extendedKeyUsage field,
the criticality is unspecified, and it's unclear whether the VPN
certificate (which presumably uses the EKUs ipsecEndSystem, ipsecTunnel,
and ipsecUser) can also contain the clientAuth/serverAuth EKUs. It's only
listed that SSL certs can only have clientAuth/serverAuth.

Section 7.1 has a typo "SPIEC" should be "IPSEC"

The actual values of the EKUs are not enumerated, leading to possible
confusion over their symbolic names.

Section 7.1 leaves ambiguity regarding the presence of SAN for the types
of certificates issued.

Section 2 of the CP suggests that the OIDs that appear are within the
distinguished name, but this does not appear correct. The OIDs enumerated
would appear within the Certificate Policies section (if Section 7.1 is
meant to be believed)

Recommendations:
I believe a modification to the CP & CPS is needed to remedy these issues,
along with clarifications about the SSL policy being distinct from other
profiles.

In particular, the CP/CPS should make clear that the "serverAuth" EKU MUST
NOT be included in any certificate that does not conform to the "SSL"
profile.

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Krajowa Izba Rozliczeniowa S.A., zarejestrowana w Sądzie Rejonowym dla m. st. Warszawy,
XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 0000113064,
NIP 526-030-05-17, REGON 012105474, kapitał zakładowy i wpłacony 5.445.000 zł Informacja zawarta w tej korespondencji jest przeznaczona tylko dla osoby lub jednostki, do której jest adresowana. Może ona zawierać zastrzeżone i poufne informacje i jeżeli to nie Państwo są wskazanym odbiorcą, nie można kopiować, rozpowszechniać lub podejmować żadnych czynności w oparciu o nią. W przypadku otrzymania tej korespondencji przez pomyłkę, proszę powiadomić nadawcę za pomocą emaila zwrotnego i usunąć tę korespondencję (wraz z załącznikami) z Państwa systemu.

The information contained in this transmission is intended only for the individual or entity to whom it is addressed. It may contain privileged and confidential information and if you are not an indicated recipient, you must not copy, distribute or take any action in reliance on it. If received in error, please notify the sender by return email and delete his transmission (and any attachments) from your system.

[Kathleen Wilson]

Thanks to all of you who have contributed to this discussion.

Note that their 2015 audit statement has been provided:
https://cert.webtrust.org/SealFile?seal=1845&file=pdf

I believe that all of the questions and concerns that were raised
regarding this root inclusion request have been resolved. Please reply
if you think I've missed anything.

Otherwise, I will move forward with closing this discussion and
recommending approval in the bug.

Thanks,
Kathleen

[Kathleen Wilson]

Thanks again to everyone who participated in this discussion.

I am now closing this discussion and will recommend approval in the bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=817994

Any further follow-up on this request should be added directly to the bug.

Thanks,
Kathleen

[Kathleen Wilson]

Inclusion of the "SZAFIR ROOT CA" root certificate was approved.
https://bugzilla.mozilla.org/show_bug.cgi?id=817994#c62

However, when we were testing the changes to include this root
certificate, we noticed that the serial number was too long, so we
requested that the CA regenerate a new root certificate with a serial
number that is less than 20 bytes.
Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=1157375#c7

The new root certificate and test websites are here:
https://bugzilla.mozilla.org/show_bug.cgi?id=817994#c64

Do any of you foresee any problems with proceeding with inclusion of the
"SZAFIR Trusted CA2" root certificate instead of the originally approved
"SZAFIR ROOT CA" certificate?

Kathleen

[Jakob Bohm]

Just an aside:

That 20 byte limit sounds like something in NSS hasn't been updated
past SHA-1 yet! (I do know that certificate serial numbers are not
really hash values in any verifiable way, but that is the historic
design reason for setting the default minimum supported length for
various PKIX elements to 20 bytes).

Since NSS already supports arbitrary length (or at least a lot longer)
values for cryptographic values (such as RSA moduli), it would make
sense for the NSS team to raise any such arbitrary limits to whatever
(non-)limit is implemented for large numbers used in cryptographic
values.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Kathleen Wilson]

On 12/1/15 3:53 PM, Jakob Bohm wrote:
>
>
> Just an aside:
>
> That 20 byte limit sounds like something in NSS hasn't been updated
> past SHA-1 yet! (I do know that certificate serial numbers are not
> really hash values in any verifiable way, but that is the historic
> design reason for setting the default minimum supported length for
> various PKIX elements to 20 bytes).
>
> Since NSS already supports arbitrary length (or at least a lot longer)
> values for cryptographic values (such as RSA moduli), it would make
> sense for the NSS team to raise any such arbitrary limits to whatever
> (non-)limit is implemented for large numbers used in cryptographic
> values.
>

https://bugzilla.mozilla.org/show_bug.cgi?id=1139205
~~
PK11_FindCertByIssuerAndSN and PK11_FindCertByIssuerAndSNOnToken enforce
that the given serial numbers be no more than
CERT_MAX_SERIAL_NUMBER_BYTES octets, which is currently 20. RFC 5280
says that implementations must be able to handle values up to 20 octets,
so while it is compliant to not handle larger values, there are root
certificates in use that are currently rejected by this restriction (see
attached - try to import it as an authority, view it, and then export
it). Also note that if these APIs are avoided, the rest of NSS appears
to handle these certificates with no trouble.
~~

It was closed as Won't fix.

Jakob, I copied your comment into the bug, to see if we can re-open it.

Thanks,
Kathleen

[Kathleen Wilson]

On 12/1/15 10:26 AM, Kathleen Wilson wrote:
>
>
> Inclusion of the "SZAFIR ROOT CA" root certificate was approved.
> https://bugzilla.mozilla.org/show_bug.cgi?id=817994#c62
>
> However, when we were testing the changes to include this root
> certificate, we noticed that the serial number was too long, so we
> requested that the CA regenerate a new root certificate with a serial
> number that is less than 20 bytes.
> Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=1157375#c7
>
> The new root certificate and test websites are here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=817994#c64
>
> Do any of you foresee any problems with proceeding with inclusion of the
> "SZAFIR Trusted CA2" root certificate instead of the originally approved
> "SZAFIR ROOT CA" certificate?
>

No one has raised concern about the replacement root certificate, so I
will assume it is OK to proceed with this request, and to include the

"SZAFIR Trusted CA2" root certificate instead of the originally approved

"SZAFIR ROOT CA" certificate.

Thanks,
Kathleen