Hello Peter,
Please find our answers below the "PK" paragraphs.
On 19/2/2016 4:00 μμ, Peter Kurrasch wrote:
Hi Dimitris,
My apologies for taking so long to get back to you with some of the
more technical comments I have regarding the HARICA CPS. I've
extracted a few of the issues and include them below. My comments now
are preceded by a "PK" in red.
Thank you for the discussion!
----------
* 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.
>> PK >> I think using the cert to access the system might have
certain advantages in an environment such as HARICA's--namely a large,
managed, constrained user base. However, such uses have their own
weaknesses when it comes to malware since malware is designed to grab
private keys and certificates for use later on. For example, if I
infect a student's PC I can grab the cert and key and sell it in some
underground market. A buyer of this info might then try to use it to
obtain a code signing cert. Such an effort might not succeed, but
there is a risk.
We do not provide code signing certificates without manual verification
so it is not possible to obtain a code signing certificate by
impersonating a user. I suppose all CAs are aware of the risks you
mention regarding key compromises which are not limited only to
codesigning certificates (which is out of scope for this discussion) but
to personal and ssl/tls certificates as well.
>> PK >> I think it's fine to use this approach but I would suggest that the
CPS be updated to specifically mention (in the appropriate sections)
malware as a reason to get a new private key and certificate. If a
subscriber finds malware on his or her device, the safest thing to do
is treat the private key as being compromised and act accordingly.
This part (possible compromise of the Private Key of the subscriber) is
already covered in section 4.9.1.1 of our CP/CPS.
* 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.
>> PK >> When I read the CPS I was thinking you wouldn't need options
1-4 and 6 in part because of their inherent security holes but also
because of the resources HARICA has available that provide better
security anyway. I would thus expect only options 5 and 7 would be
pertinent. This in spite of the fact that the BR says they are OK to use.
>> PK >> Regarding the security gaps, options 1-3 should not be used
because there is no way to assure the trustworthiness of a domain name
registrar and, therefore, the accuracy of the registrant information.
This is especially true when you have a registration proxy or
anonymizer. Option 4 should not be used because it is provably
insecure and has already been used to induce a CA to mis-issue a cert.
Option 6 should not be used because demonstrating control over a web
host proves nothing in terms of control over the domain name.
>> PK >> The one change I would ask for, before inclusion of the
HARICA root in the Mozilla trust store, is that the CPS be updated in
regards to the use of these options. Where possible, I would just say
that an option will not be used. If not possible, I would like to see
details on how the vulnerabilities in each case will be mitigated.
All these methods are approved and published in the CA/B Forum Baseline
Requirements. Perhaps it would be best to raise these concerns in the
CA/B Forum's public mailing list ([email protected]). In any case, if
the CA/B Forum changes these methods, all CAs (including HARICA) will
have to adjust their practices (and practice documents) to remove the
verification methods you mentioned.
* 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.
>> PK >> I would imagine that the modulus and exponent is checked
against all certs issued under the HARICA root--including even the
expired and revoked certs. Will that check be performed or just
against the user certs?
This check is performed for new certificate requests (not renewals) for
all end-entity certificates.
* 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.
>> PK >> After re-reading the section I now understand what you are
saying here and have no objection. One comment, though, is that the
last sentence in the section seems to suggest that the root cert is
technically constrained to those TLD's listed, which I didn't think
was the case. I assume this is more a policy list and not something
put into the root itself?
The last paragraph of that section refers to the HARICA Root CA 2011.
Thank you once again for your comments regarding this application.
Sincerely,
Dimitris Zacharopoulos.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
