Hello Peter and thank you for reviewing this request. I hope you have
reviewed the DRAFT CP/CPS available
<https://bugzilla.mozilla.org/attachment.cgi?id=8698099>from the bug
1201423 <https://bugzilla.mozilla.org/show_bug.cgi?id=1201423> since we
have done some changes after the original bug report.
On 25/1/2016 6:16 μμ, Peter Kurrasch wrote:
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.
We will try to make these terms clearer in a future revision. For this
review, please consider the following which might make things more clear:
"HARICA" is the "organization" that runs, administers, manages,
oversees the "HARICA PKI". HARICA Root and all subCAs are centrally
managed. We searched for the term "HARI PKI" in our CP/CPS but did not
get a hit. HARICA members are Greek Academic and Research Institutions
signing a certain MoU <http://www.harica.gr/documents/MoU-EN.pdf>, which
is available at http://www.harica.gr/procedures. You may consider this
as an "affiliation", as defined in section 1.6.1. HARICA members (as
Institutions) have physical persons (students, faculty, staff,
researchers and so on) under their "supervision".
We did not find the term "the main" referring to a CA. We do have a
"Central RA" that verifies identity, email ownership and control over
domains.
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?
Each member's Sub CA is technically constrained to limit the scope of
issued certificates to the member-organization, according to the rules
set by Mozilla and CA/B Forum (please see ballot 105), and after proper
verification of control over these domains. All CA keys are centrally
managed. This means that members are not in control of the private keys
associated with their subCAs. All CA keys are physically stored in FIPS
140-2 Level 3 devices. We consider this a very safe approach with
minimum risk.
We also have plans to issue certificates for non-members, including the
public administration, government agencies, businesses etc. These
subscribers will be validated and verified by the Central RA according
to section 3.2.
* 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.
We do issue code signing certificates. They are issued under very strict
procedures and code signing certificates may be bound to personal
certificates. Subscribers that obtain a code-signing certificate are
also obligated to sign a special Terms of Use Agreement. Code Signing
certificates are manually approved with all due diligence. However,
since Mozilla has removed the code-signing trust bit, this request does
not relate to code-signing certificates as far as the Mozilla Root
Program is concerned.
* 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).
Subscribers must agree that information included in the certificates is
publicly available. There are some restrictions in place to protect the
repository from enumeration. User certificates need to be publicly
available if for example one researcher wants to either encrypt a
document and e-mail it to a fellow researcher or if he needs to validate
a signed document and wants to lookup for the signing certificate.
Furthermore, disclosure of the issued certificates allows for better
transparency.
If you already have a certificate, you use that certificate and private
key to access the PKI system (no username/password). If you don't have a
certificate, you are not listed in the repository (therefore your
username/email is unavailable for the public) but you may enter the PKI
system via username/password to request a certificate. That certificate
will be issued after proper validation.
* In section 3.1, will all certs issued under this root have C=GR?
Although currently all issued certificates have C=GR, we do not wish to
limit this.
* 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?
These controls are used to assess domain ownership. There are several
domains used for example in research and other projects that need to be
validated for ownership. We mainly use options 1-5 but option 6 is also
available. Option 7 is taken from the CA/B Forum BR for any future
method that has the same level of assurance as options 1-6.
* Section 3.2.3.1, the first sentence in paragraph 2 makes no sense.
Reading the entire paragraph seems to reach a safer conclusion.
Institutions have procedures that verify/validate the identity of
subscribers. The CP/CPS basically compels these Institutions to certify
the identity of their users by means of an official document that bears
the photograph of the beneficiary (e.g police identity card, passport,
driving license). We can make changes to this section to make it clearer.
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".
Yes, indeed. It will be corrected.
* 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?
If a CA allows the creation of private keys on behalf of subscribers
(which is not the general case), there is a special procedure as
described in the rest of the section.
This process is intended for Institutions that have internal
registration services and wish to issue certificates for a large number
of users. For example, a University Department has a registration system
that includes pre-validated information about their students. Consider
this a Reliable Data Source as defined in section 1.6.1. This Department
would send this pre-validated information to the Registration Authority
to be included in the subject of the certificates. Then the CA would use
this information to create CSRs with associated keys and then safely
deliver these keys (with sealed PINs/PUKs/passphrases) to the
corresponding users. In case of soft keys, a secure delete procedure
would be in place so that the private key would only be in the
possession of the user. The key delivery would be performed via means of
photo id verification for each subscriber.
Although this procedure has not been used until now, HARICA members that
plan to use this procedure will describe a detailed process according to
the CP/CPS which must be approved by the PMC.
* 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?
We did not distinctly describe this process in the CP/CPS. It is covered
by the 4th paragraph of section 6.1.1 and section 6.1.6 as part of
several quality checks performed by the CA. Duplicate keys for user
certificates are detected by the CA by examining the modulus and
exponent of the public key. We could update paragraph 6.1.6 to make this
more clear.
* 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.
The EKU list of Section 7.1.2 leaves these options open for future
extension. Current certificate profiles are described in Annex B.
This request is limited for the serverAuth, clientAuth and
emailProtection EKUs as far as the Mozilla Root Program is concerned.
* Section 7.1.5 is an outright mess. The stuff that's a copy/paste of
the Mozilla requirements should be removed.
Since we have implemented nameConstraints according to the Mozilla and
CA/B Forum Baseline Requirements, we think it should be included in the
CP/CPS.
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?).
We plan to create a ".com" and a global (excluding ".com") subCA
according to the CP/CPS later this year. These CAs will be generated and
managed with "RootCA" type of controls. Perhaps the "created upon first
request" is misleading. We will correct this section to describe the
process more clearly.
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.
We will try to make this section more clear, by providing some examples.
In regular operations, certificates will be issued by HARICA members'
subCAs which are constrained to the domains they control.
There might be cases where a researcher needs to obtain an SSL
certificate for a project (eg. myproject.example.*com*). Then, this
applicant would contact the Central RA of HARICA and request this
"myproject.example.*com*" certificate. After proper validation (as
described in section 3.2), this request would be signed by the "global
subCA which is restricted to the domain com" which includes a
nameConstraints extension with permittedSubtrees dNSName="com". We have
deliberately isolated certificates for "com" because of the high risk
associated.
For other cases, (eg. myproject.example.*org*), following a similar
procedure and after proper validation (as described in section 3.2),
this request would be signed by the "global subCA which excludes the
domain com" via nameConstraints extension (excludedSubtrees have
dNSName="com"). This resembles the current situation with most
commercial CAs which have "global subCAs" for DV, OV, etc.
Issuing a certificate with SAN "myproject.example.org" AND
"myproject.example.com" in the same certificate is incompatible for
HARICA, according to this procedure.
We basically try to minimize the security risk associated with these
"global" CAs. We hope these examples better illustrate what we try to
accomplish.
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.
We 'd like to thank you for your time and consideration to review this
request. We do consider our CP/CPS a real CPS document, following the
guidelines of RFC3647, the CA/B Forum Baseline Requirements and the
Mozilla Root Program requirements. The document is not written by
native-English speakers and there might be unclear sections that we will
try to improve in upcoming versions. We hope we have addressed your
questions and concerns at least on the technical and operational issues.
Sincerely,
Dimitris Zacharopoulos.
*From: *Kathleen Wilson
*Sent: *Wednesday, January 20, 2016 7:03 PM
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
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
