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-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy