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

[Ryan Sleevi]

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?