| I've reviewed the CPS/CP and in general I like it but I do have some concerns. My frame of reference is two-fold: First, how large is the attack surface through which I as a bad guy might obtain a cert to use for nefarious purposes? I would rate that as "moderate". Second, how much damage can I cause with a fraudulently obtained cert and private key? I rate this as "significant" based on my understanding and interpretation of this doc. As my understanding improves I'll probably change my mind, though. One general problem I had was trying to figure out the right context, roles, and such for some of the policies stated in the doc. For example, the terms HARICA, HARICA PKI, HARI PKI, HARICA member of organization, HARICA root, subCAs and such appeared in ways that seemed confusing but maybe I am the one who's confused. In particular it wasn't always clear to me which roles would be performed by a "member organization" vs "the main" CA--and under which circumstances and how many there are likely to be. Knowing this helps me better judge the attack surface and damage potential. Some specific comments: * Will any cert issuer chaining to the HARICA root be issuing a cert to any entity outside of the HARICA organization? Frequently, universities will partner with other universities, government agencies, businesses, etc. Would a situation arise where any such org might receive a HARICA cert? * Section 1.4.1 mentions code signing by these certs and this is actually my biggest concern in terms of "how much damage can I cause?". I assume that code signing is intended for use on the Microsoft platforms? Is any subscriber able to obtain a user cert with code signing enabled? There should be limits imposed by the subCAs. * The repo mentioned in section 2.2 introduces some perhaps unintentional risk into the system because it essentially makes every name and email address public knowledge. Granted there are many other ways to obtain that info (for example, a researcher publishes a paper) so this isn't a situation unique to the repo. But the issue comes when user passwords become compromised. If I have a password and a name or partial name, I'm guaranteed access into the PKI system (as I understand this doc). * In section 3.1, will all certs issued under this root have C=GR? * Section 3.2.2.4 seems to contradict the whole of this CPS. I hope that most of these options will not be used to assess domain ownership because this document seems to illustrate what option 7 had in mind? * Section 3.2.3.1, the first sentence in paragraph 2 makes no sense. Also, in paragraph 3, use of email is sufficient...unless the account has been compromised. I'm not saying a change is needed here but rather pointing out a fallacy in the logic being used. * For section 3.3.2, I think you mean "initial cert". * Section 6.1.2 uses the phrase "confirm the validity of the identity of the user" which made me wonder if anything more than an email address + password is required. Can this be clarified? How will the confirmation be implemented uniformly across the HARICA PKI organization? * Reading section 6.1.2 (and others) made me wonder if there is any checking within the HARICA system to see if any 2 certs have the same public key. Such a check should be done prior to issuance I would think. I didn't find any prohibitions on key sharing, so is key sharing acceptable and, if not, how is that enforced? * The EKU list in section 7.1.2 caught me by surprise. Some of them (e.g. file system, time stamping, IPSEC) I would have expected to be mentioned earlier in the doc. The size of this list has a direct impact on the "how much harm can I do" question so I was hoping this would be a very short list to limit the potential harm. * Section 7.1.5 is an outright mess. The stuff that's a copy/paste of the Mozilla requirements should be removed. I'd like to see name constraints to be included in the HARICA root, and it seems .gr and .com are doable. I'd like to see tighter controls on what justifications are needed to create the .com sub-root (for example, can any student request a cert with .com and suddenly the .com sub-root will appear?). Also, I wasn't sure if a full sub-CA is to be created or a just the intermediate cert. I think there is good potential here but need more info before I could really say for sure. As a final comment, let me say that I have nothing against HARICA and my intention is not for them to be treated unfairly. Rather, I'd been thinking about many of the ideas mentioned here and wanted to compare those ideas against a real CPS document. HARICA just happened to be the next one to come along.
On 12/10/15 3:29 PM, Kathleen Wilson wrote:
> This request is to include the “Hellenic Academic and Research > Institutions RootCA 2015” and “Hellenic Academic and Research > Institutions ECC RootCA 2015” root certificates, and enable the Websites > and Email trust bits for both roots. > > Hellenic Academic and Research Institutions Certification Authority > (HARICA) is a non-profit organization serving the Greek Academic and > Research Community; operated by the Greek Universities Network > (www.gunet.gr). > > The request is documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1201423 > > And in the pending certificates list: > https://wiki.mozilla.org/CA:PendingCAs > > Summary of Information Gathered and Verified: > https://bugzilla.mozilla.org/attachment.cgi?id=8697399 | ||
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
