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.
Od: "Ryan Sleevi" <ryan-mozdevsecpol...@sleevi.com>
Do: "Kathleen Wilson" <kwil...@mozilla.com>,
DW: mozilla-dev-security-pol...@lists.mozilla.org
Data: 2015-02-10 01:20
Temat: Re: Second Discussion of KIR S.A. Root Inclusion Request
Wysłane przez: "dev-security-policy"
<dev-security-policy-bounces+certificates=kir.com...@lists.mozilla.org>
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.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@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.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
