ODP: Re: Second Discussion of KIR S.A. Root Inclusion Request

[Certificates]

Hello,

Thank you for your detailed second review.

Please, find our answers below.

--- PEDANTRY

Section 2.4 of the CP still states "TLS" as "TSL protocol"

Section 1.1 of the CPS alternates between identifying the CPS as "CPS" and
"CSP"

Section 1.3 perhaps mistranslates "Relying Party" as "Trusted Party", even
though the description properly describes RPs

Section 3.2.2 calls ICANN "ICCAN" in the description of the use of the PSL

KIR's answer:

We’ve corrected typos. New versions of the documents will be available on
our website staring with the Tuesday. They' ll be available also here:

http://elektronicznypodpis.pl/files/doc/certification_policy.pdf

http://elektronicznypodpis.pl/files/doc/certification_practice_statement.pdf


--- NAMING

In looking at Section 3.1 again, I'm not sure if there's a mistranslation,
but I'm trying to understand the construction used by KIR S.A for the
distinguished name (e.g. as it relates to Section 9.2 of the BRGs).

For example, what X.509 Attribute Type and Value corresponds to the
"domain name" field listed in the table? This is presumably not the
subjectAltName (which is detailed in Section 7.1), and the Subject section
of the profile just back-references to Section 3.1

Is this some construction of the domainComponent (RFC 1274, RFC 4519), OID
0.9.2342.19200300.100.1.25? Is this a conceptual field (e.g. detailing
that domain names will not appear within, for example, the common name)?
Something else?

KIR's answer:

We build DN based on the information given by subscriber in a registration
form . The names in the table in section 3.1 CPS are user friendly and
easy to recognize for our customers. DN in SSL certificate complies with
9.2.4 BR and consists of:
countryName [2.5.4.6]
stateOrProvinceName [2.5.4.8]
localityName [2.5.4.7]
organizationName [2.5.4.10]
commonName [2.5.4.3]

„domain name” is placed in subjectAltName [2.5.29.17].

We don’t place domainComponent in our certificates. You can check our test
certificates. Other information from the table in section 3.1 CPS given by
subscriber in register form are placed in DN (name and given name) and in
extensions (email address). CPS concerns not only SSL certificates.


Because Section 7 references back to Section 3, and it would appear that
Section 3 was translated from native language in the original CPS, it
might be helpful to resolve the ambiguity by detailing the OIDs of the
distinguished name components (e.g. country name is OID 2.5.4.6)

Alternatively, using the names as described in Section 9.2 of the BRs may
help, but rather than 'yet another reference' (which might be translated
poorly in subsequent revisions), adopting a structure similar to Sections
9.1 / 9.2 can provide clarity as to the policies KIR S.A. uses in the
construction of the distinguished names.

As a further example, consider Section 3.1.3, which notes that the
distinguished name may contain a unique serial number. Is this the
id-at-serialNumber from RFC 5280 (aka 2.5.4.5)? A dnQualifier (2.5.4.46),
which matches the purpose described of ensuring uniqueness? Something
else?
KIR's answer:

Section 3.1.3 CPS doesn’t mean, that we put serial number into
distinguished name. Each certificate issued by KIR has unique serial
number (SN mentioned in 9.6 BR)and unique DN. This both values make that
the certificate is unique.


From reading this policy alone, it's difficult to evaluate compliance with
9.2.2, 9.2.3, and 9.2.4 of the BRs.

For what it's worth, I'm extremely appreciative that KIR S.A. has taken
the time to explicitly spell out their policy and name forms. I certainly
have seen CPSes that simply say "Names conform to RFC 5280 or X.500" or
something equally vague. As an example of how you can do this, I'll point
to the most recent root inclusion, TurkTrust. Their CPS
http://dl.turktrust.com.tr/pdf/TURKTRUST-CPS-v09-SSL.pdf details the exact
set of fields contained in the distinguished name in Section 3.1.5.1
(albeit including "SAN" in the DN field, which is... weird), including
noting that the "Common Name" field for SSL certs contains the (validated)
domain name.

Mostly related to the above, I'm not sure which field in the distinguished
name that 3.2.4 (1) refers to. What OID is this?
KIR's answer:

This isn’t in DN. This is title [OID 2.5.4.12] placed in
SubjectDirectoryAttributes [OID 2.5.29.9].

As it relates to 3.2.4 (3), this seems to conflict with the requirements
of Baseline Requirements, section 9.2.4 (f). That is, 3 indicates KIR S.A.
does not validate the information, but 9.2.4 (f) requires that CAs MUST
validate the information. Of course, this only applies IF KIR S.A.
includes this information in the certificate - 3.2.4 (3) is worded
ambiguously, and may mean that they simply ignore such requests for
additional distinguished name fields. Could you clarify?
KIR's answer:

CPS concerns not only SSL certificates. All information which can be put
in SSL certificate are mentioned in 3.1 and 7.1. All of the we verify
before we issue certificate as it is describe in earlier section and as BR
requires. 3.2.4 is more about users certificates.


--- REVOCATION

Section 3.4. notes that there are multiple parties that can request
revocation. I'm not sure on the translation of things, but it would seem
to indicate anyone in the public can request revocation ("or another
person, provided it is so...")

However, it doesn't seem to provide the instructions related to Section
13.1.2 of the Baseline Requirements ("Certificate Problem Reporting").
Incidentally, I'm having trouble finding an example section within
TurkTrust's CPS that I could point to. In an RFC 3447 framework, this is
Section 4.9.3. In KIR S.A.'s case, neither 4.9.3 nor 4.9.2 provide a means
for Relying Parties to request/report potential violations (e.g. a
certificate being involved in fraud)

Basically, somewhere in the CPS needs to be a description of how KIR S.A.
handles problem reports, per Section 13.1.2 of the BR Guidelines; that
most likely belongs in 4.9.3 of your CPS, but that's just my
understanding.
KIR's answer:

Section 4.9 CPS says: If there occur circumstances indicative of a
necessity to suspend or revoke the certificate, KIR shall revoke/ suspend
it. SSL certs can be only revoked. Circimstances are listed in 4.9.1.
Certificate revocation may occur under e.g. the following circumstances:
· Certificate has been issued on the basis of untrue data or has
been issued without due verification of the application for certificate
issuance and without consent of the recipient of services for its
issuance;
· KIR has received evidence that the certificate has been used
contrary to its purpose;
· KIR has received information confirming that the domain name
entered in the certificate has ceased to be owned by the recipient of
certification services (e.g. a domain registering entity has been revoked
rights to register domains or an agreement for domain registration
concluded between the domain owner and the domain registering entity has
expired or the domain registering entity has not extended registration of
a specific domain);
· KIR has received information that a wildcard certificate for the
domain has been used for authorisation of an inappropriate sub-domain;
As it is said in section 13.1.2 we placed information what to do with
information about problems with trust on our website
http://eng.elektronicznypodpis.pl/en/information/suspend-or-revoke
(english version),
http://www.elektronicznypodpis.pl/informacje/jak-zawiesic-lub-uniewaznic-certyfikat/
(polish version). Both the revocation requests and the information about
problems are maintained continuously 24x7.
So, if we get information about problem with certificate issued by KIR we
verify it and if this is trustworthy information we revoke certificate and
notify the subscriber, a person whose data is included in the certificate,
and, possibly, another person about certificate revocation as it is
described in 4.9 in CSP. The maximum time for revocation is 24 hour as it
is mentioned in 4.9.5.



--- SERIAL NUMBERS

Perhaps I missed it, but I didn't see anything in the policy regarding how
serial numbers are generated (e.g. Section 7.1). This is not strictly
required to be disclosed, but as a reminder, the Baseline Requirements
require at least 20 bits of entropy (Section 9.6), while specific root
programs may require more (e.g. Microsoft requires 64 bits). It wouldn't
hurt to document how serial numbers are generated, or simply their minimum
entropy, to make it easier to review via CPS.

KIR's answer:

We generate serial number as it is said in BR. We notice that TurkTrust's
CPS says about SN more or less the same as our CPS.---

--- OCSP NONCE

I note that in Section 7.3.4, KIR S.A. supports OCSP nonces. This may
represent a denial of service opportunity for your OCSP responder, if a
malicious client sends multiple requests with varying nonces. Because OCSP
responses are signed, this can represent a significant work magnifier, and
prevent the OCSP responder from addressing other requests.

I don't know how KIR S.A.'s infrastructure is setup; perhaps nonce-less
OCSP responses are pre-signed in batch and distributed appropriately, and
only nonce-ful responses require online signing.

Because of this, I'd strongly recommend for the security/stability of your
OCSP responder that you consider disabling support for OCSP nonces,
despite their replay prevention value.

KIR's answer:

The nonce cryptographically binds a request and a response to prevent
replay attacks. That’s why we decided to support this extension. Our IT
infrastructure is prepared to deal with high performance volumes. We use
also another mechanisms against DOS attack.


--- THINGS I DON'T UNDERSTAND BECAUSE I'M NOT SMART

I'm not entirely sure I understand the country validation logic of Section
3.2.2, as it relates to validating an IP is within a range within a given
country. That said, it doesn't _seem_ to affect how the C field is
validated within the DN, thus would not be a violation of 9.2.4(f); it
just seems to describe additional controls on who KIR S.A will issue to.
Is this correct?

KIR's answer:

Yes exactly. This is additional check as it is required in 11.2.5 BR.



Od: "Ryan Sleevi" <ryan-mozde...@sleevi.com>
Do: "Kathleen Wilson" <kwi...@mozilla.com>,
DW: mozilla-dev-s...@lists.mozilla.org
Data: 2015-03-19 12:01
Temat: Re: Second Discussion of KIR S.A. Root Inclusion Request
Wysłane przez: "dev-security-policy"
<dev-security-policy-bounces+certificates=kir.c...@lists.mozilla.org>



On Tue, March 3, 2015 12:32 pm, Kathleen Wilson wrote:
> All,
> I have confirmed that KIR has made the changes listed below to their
CPS
> and CP.
> CPS:
>
http://www.elektronicznypodpis.pl/files/doc/certification_practice_statement.pdf

CP: http://elektronicznypodpis.pl/files/doc/certification_policy.pdf
Are there any further questions or comments about the request from KIR
to include the "SZAFIR ROOT CA" root certificate and enable all three
trust bits?
> Thanks,
> Kathleen

Apologies that it has taken me this long to do a detailed second review.

Of the issues I list below, I think only one represents a significant
issue (REVOCATION). I identify some trouble I had validating conformance
(NAMING), a potential security/reliability issue (OCSP NONCES), and a few
bits of PEDANTRY (including the SERIAL NUMBERS and THINGS I DON'T
UNDERSTAND)

I hope KIR S.A. can respond quickly to address REVOCATION and clarify
NAMING, and then I think we're good to go (e.g. I would not block approval
on the remaining items)


--- PEDANTRY

Section 2.4 of the CP still states "TLS" as "TSL protocol"

Section 1.1 of the CPS alternates between identifying the CPS as "CPS" and
"CSP"

Section 1.3 perhaps mistranslates "Relying Party" as "Trusted Party", even
though the description properly describes RPs

Section 3.2.2 calls ICANN "ICCAN" in the description of the use of the PSL


--- NAMING

In looking at Section 3.1 again, I'm not sure if there's a mistranslation,
but I'm trying to understand the construction used by KIR S.A for the
distinguished name (e.g. as it relates to Section 9.2 of the BRGs).

For example, what X.509 Attribute Type and Value corresponds to the
"domain name" field listed in the table? This is presumably not the
subjectAltName (which is detailed in Section 7.1), and the Subject section
of the profile just back-references to Section 3.1

Is this some construction of the domainComponent (RFC 1274, RFC 4519), OID
0.9.2342.19200300.100.1.25? Is this a conceptual field (e.g. detailing
that domain names will not appear within, for example, the common name)?
Something else?

Because Section 7 references back to Section 3, and it would appear that
Section 3 was translated from native language in the original CPS, it
might be helpful to resolve the ambiguity by detailing the OIDs of the
distinguished name components (e.g. country name is OID 2.5.4.6)

Alternatively, using the names as described in Section 9.2 of the BRs may
help, but rather than 'yet another reference' (which might be translated
poorly in subsequent revisions), adopting a structure similar to Sections
9.1 / 9.2 can provide clarity as to the policies KIR S.A. uses in the
construction of the distinguished names.

As a further example, consider Section 3.1.3, which notes that the
distinguished name may contain a unique serial number. Is this the
id-at-serialNumber from RFC 5280 (aka 2.5.4.5)? A dnQualifier (2.5.4.46),
which matches the purpose described of ensuring uniqueness? Something
else?

From reading this policy alone, it's difficult to evaluate compliance with
9.2.2, 9.2.3, and 9.2.4 of the BRs.

For what it's worth, I'm extremely appreciative that KIR S.A. has taken
the time to explicitly spell out their policy and name forms. I certainly
have seen CPSes that simply say "Names conform to RFC 5280 or X.500" or
something equally vague. As an example of how you can do this, I'll point
to the most recent root inclusion, TurkTrust. Their CPS
http://dl.turktrust.com.tr/pdf/TURKTRUST-CPS-v09-SSL.pdf details the exact
set of fields contained in the distinguished name in Section 3.1.5.1
(albeit including "SAN" in the DN field, which is... weird), including
noting that the "Common Name" field for SSL certs contains the (validated)
domain name.

Mostly related to the above, I'm not sure which field in the distinguished
name that 3.2.4 (1) refers to. What OID is this?

As it relates to 3.2.4 (3), this seems to conflict with the requirements
of Baseline Requirements, section 9.2.4 (f). That is, 3 indicates KIR S.A.
does not validate the information, but 9.2.4 (f) requires that CAs MUST
validate the information. Of course, this only applies IF KIR S.A.
includes this information in the certificate - 3.2.4 (3) is worded
ambiguously, and may mean that they simply ignore such requests for
additional distinguished name fields. Could you clarify?


--- REVOCATION

Section 3.4. notes that there are multiple parties that can request
revocation. I'm not sure on the translation of things, but it would seem
to indicate anyone in the public can request revocation ("or another
person, provided it is so...")

However, it doesn't seem to provide the instructions related to Section
13.1.2 of the Baseline Requirements ("Certificate Problem Reporting").
Incidentally, I'm having trouble finding an example section within
TurkTrust's CPS that I could point to. In an RFC 3447 framework, this is
Section 4.9.3. In KIR S.A.'s case, neither 4.9.3 nor 4.9.2 provide a means
for Relying Parties to request/report potential violations (e.g. a
certificate being involved in fraud)

Basically, somewhere in the CPS needs to be a description of how KIR S.A.
handles problem reports, per Section 13.1.2 of the BR Guidelines; that
most likely belongs in 4.9.3 of your CPS, but that's just my
understanding.


--- SERIAL NUMBERS

Perhaps I missed it, but I didn't see anything in the policy regarding how
serial numbers are generated (e.g. Section 7.1). This is not strictly
required to be disclosed, but as a reminder, the Baseline Requirements
require at least 20 bits of entropy (Section 9.6), while specific root
programs may require more (e.g. Microsoft requires 64 bits). It wouldn't
hurt to document how serial numbers are generated, or simply their minimum
entropy, to make it easier to review via CPS.


--- OCSP NONCE

I note that in Section 7.3.4, KIR S.A. supports OCSP nonces. This may
represent a denial of service opportunity for your OCSP responder, if a
malicious client sends multiple requests with varying nonces. Because OCSP
responses are signed, this can represent a significant work magnifier, and
prevent the OCSP responder from addressing other requests.

I don't know how KIR S.A.'s infrastructure is setup; perhaps nonce-less
OCSP responses are pre-signed in batch and distributed appropriately, and
only nonce-ful responses require online signing.

Because of this, I'd strongly recommend for the security/stability of your
OCSP responder that you consider disabling support for OCSP nonces,
despite their replay prevention value.


--- THINGS I DON'T UNDERSTAND BECAUSE I'M NOT SMART

I'm not entirely sure I understand the country validation logic of Section
3.2.2, as it relates to validating an IP is within a range within a given
country. That said, it doesn't _seem_ to affect how the C field is
validated within the DN, thus would not be a violation of 9.2.4(f); it
just seems to describe additional controls on who KIR S.A will issue to.
Is this correct?




_______________________________________________
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.

[Ryan Sleevi]

On Fri, March 20, 2015 8:10 am, Certificates wrote:
> Hello,
>
> Thank you for your detailed second review.
>
> Please, find our answers below.

Kathleen pointed out my original message was unclear, but I think it's
fine to progress on this inclusion.

While nothing prohibits OCSP nonces, I do hope KIR S.A. reconsiders -
that's opening up an additional attack vector for your services that
aren't at all used by major clients, and requires an online OCSP signing
key, which can affect performance and security. However, the BRs certainly
does not prohibit this, so it's at KIR's discretion whether to use this,
as long as they understand that if their services go offline or are
compromised, they're ultimately responsible.

It seems the majority of the issues I reported are translation issues.
Ultimately, KIR S.A. will be held responsible for following the CPS, so
it's good to ensure that there is not ambiguity or mistatements in the
translation, since those may be perceived as a CPS violation.