HARICA Root Renewal Request

[Kathleen Wilson]

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

Noteworthy points:

* The primary documents are the CPS; provided in Greek and English

Document Repository: http://www.harica.gr/procedures
CPS: http://www.harica.gr/documents/CPS-EN.pdf

* CA Hierarchy:
** The new roots will be cross-signed by “Hellenic Academic and Research
Institutions RootCA 2011” to assist the rollover.
** “Hellenic Academic and Research Institutions RootCA 2011” currently
has 20 internally operated and technically-constrained subCAs.
There is currently one externally-operated subordinate CA:
- Aristotle University of Thessaloniki
- http://www.auth.gr, http://it.auth.gr
- http://www.pki.auth.gr/certs/AuthCentralCAR3.pem, (to be
decommissioned by Sep 2015)
- http://www.pki.auth.gr/certs/AuthCentralCAR4.pem
- http://www.pki.auth.gr/certs/AuthCentralCAR5.pem
- AuthCentralCAR4 and AuthCentralCAR5 issue sub-CAs and end user/server
certificates
- http://www.pki.auth.gr/documents/CPS-EN.pdf
- Sections in CP/CPS demonstrating the measures to verify:
-- Ownership of domain name: 3.2.2, 3.2.3.2 and 3.2.5
-- Ownership of e-mail: 3.2.2, 3.2.3.1 and 3.2.5
- For all certificates chaining up to these Sub-CA, both the
organization and the ownership/control of the domain are verified.
- This CA is currently operated by the same administration team as the
HARICA Root CA.
- OCSP: http://ocsp.pki.auth.gr
- Audit: http://pki.auth.gr/documents/AUTH-ETSI_CERTIFICATE_AUTH_W_ANNEX

** “Hellenic Academic and Research Institutions ECC RootCA 2015”
currently has the following internally-operated subCAs:
- Hellenic Academic and Research Institutions ECC AdminCA R1
We plan to issue the following internally operated subCAs for specific
usages:
- ECC Client Authentication and SecureEmail
- ECC Code Signing
- ECC SSL (DV/OV) Server Certificates
There are currently no externally operated subCAs issued from this root.
According to our CP/CPS, in case of externally operated CAs, they will
either be technically constrained or publicly disclosed and audited.

* This request is to enable the Websites and Email trust bits for both
root certs. HARICA is not requesting EV treatment.

** CPS section 3.2.3.1: HARICA central RA uses three methods for e-mail
ownership and control verification:
- The first method uses simple e-mail verification. The user enters the
e-mail address at the initial certificate request form and a
verification e-mail is sent to the user with a link to a unique web
page. After following this link, an e-mail is sent to the institution's
network operation center mail administrator that requires an approval
based on the full name entered by the user and the user's email. This
approval requires the identification of the user with his/her physical
presence and an acceptable official document.
- The second method uses an LDAP server. The user enters the personal
e-mail address at the initial certificate request form and the
corresponding password. This information is verified against the
institution's LDAP server. If the verification is successful, the RA
queries the real name of the user and creates the certificate request.
In order for a user to be listed in the Institutional Directory server,
the institution must have verified the user with his/her physical
presence and an acceptable official photo-id document.
- The third method uses a Single Sign On (SSO) architecture based on the
SAML specification. The user enters the personal e-mail address at the
initial request form and is then redirected to the appropriate web page
of the Identity Provider. The Identity Provider verifies the user and
returns the real name and the email address of the user as attributes to
the Registration Authority. In order for a user to be verified by the
Identity Provider of an institution, the institution must have verified
the user with his/her physical presence and an acceptable official
photo-id document.

** CPS section 3.2.3.2: For each Fully-Qualified Domain Name listed in a
Certificate, the CA SHALL confirm that, as of the date the Certifiate
was issued, the Applicant either is the Domain Name Registrant or has
control over the FQDN by:
- Confirming the Applicant as the Domain Name Registrant directly with
the Domain Name Registrar,
- Communicating directly with the Domain Name Registrant using an
address, email, or telephone number provided by the Domain Name Registrar;
- Communicating directly with the Domain Name Registrant using the
contact information listed in the WHOIS record's "registrant",
"technical", or "administrative" field;
- Communicating with the Domain’s administrator using an email address
created by pre-pending ‘admin’, ‘administrator’, ‘webmaster’,
‘hostmaster’, or ‘postmaster’ in the local part, followed by the at-sign
(“@”), followed by the Domain Name, which may be formed by pruning zero
or more components from the requested FQDN;
- Relying upon a Domain Authorization Document;
- Having the Applicant demonstrate practical control over the FQDN by
making an agreed-upon change to information found on an online Web page
identified by a uniform resource identifier containing the FQDN; or
- Using any other method of confirmation, provided that the CA maintains
documented evidence that the method of confirmation establishes that the
Applicant is the Domain Name Registrant or has control over the FQDN to
at least the same level of assurance as those methods previously described.

*Root Certificate Download URLs:
http://www.harica.gr/certs/HaricaRootCA2015.der
http://www.harica.gr/certs/HaricaECCRootCA2015.der

* EV Policy OID: Not requesting EV treatment

* Test Websites:
https://www2.harica.gr/
https://www3.harica.gr/

*CRL URLs:
http://crlv1.harica.gr/HaricaRootCA2015/crlv1.der.crl
http://crlv1.harica.gr/HaricaAdministrationCAR5/crlv1.der.crl
CPS section 4.9.7: For end-user/device certificates ... the CRL will be
in effect for a maximum time of ten days.

* OCSP URL: http://ocsp.harica.gr
For Subscriber Certificates: OCSP responses have a maximum expiration
time of two days.

* Audit: Annual audits are performed by QMSCERT, according to the ETSI
TS 102 042 criteria.
http://www.qmscert.com/share/HARICA-ETSI_CERTIFICATE_AUTH_W_ANNEX.pdf
http://www.qmscert.com/share/HARICA-ETSI_CERTIFICATE_AUTH_W_ANNEX.pdf

This begins the discussion of the request from HARICA 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.

At the conclusion of this discussion I will provide a summary of issues
noted and action items. If there are outstanding issues, then an
additional discussion may be needed as follow-up. If there are no
outstanding issues, then I will recommend approval of this request in
the bug.

Kathleen

[Dimitris Zacharopoulos]

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

Hello everyone,

We would also like to add that HARICA is currently a Qualified
Certification Service Provider according to the EU Signature Directive
(Directive 1999/93/EC).

We are drafting a new CP/CPS which is subject to further changes and
will be posted to the bug on Monday Dec 14th. This CP/CPS will
eventually replace the one listed at
http://www.harica.gr/documents/CPS-EN.pdf so please consider the DRAFT
CP/CPS version for your review once we upload it. We would like to go
through the typical CP/CPS change procedure only once (if possible),
after we get all feedback from the public discussion.


Best regards,
Dimitris Zacharopoulos.



--
/HARICA Public Key Infrastructure

*Dimitris Zacharopoulos*
PKI Manager
t : +30 2310 998483
f : +30 2310 999100
www.harica.gr /

[Dimitris Zacharopoulos]

The Draft CP/CPS has been uploaded to the bug
<https://bugzilla.mozilla.org/show_bug.cgi?id=1201423> and is available
for download at the following URL:

* https://bugzilla.mozilla.org/attachment.cgi?id=8698099

[Kathleen Wilson]

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
>

Does anyone need more time to review this request from HARICA 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?

The draft of their updated CP/CPS is attached to the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1201423#c13

If no one needs more time to review this request, and no one has any
questions/concerns about this request, then I will close this discussion
and recommend approval in the bug.

Thanks,
Kathleen

[Peter Kurrasch]

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, ho‎w 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.

‎

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‎

[Dimitris Zacharopoulos]

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, ho‎w
> 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‎

[Peter Kurrasch]

Thank you, Dimitris, for your helpful response! I appreciate the clarifications you provided. I do like that there are fairly tight controls in place as I think it will serve everyone (both HARICA CA subscribers and the wider Internet population) well.

I did review version 3.3 (which is much better than the previous version!) and the clarifications you mention below all sound‎ reasonable to me. I have no further comments on them if you will be updating the CPS accordingly. For some of the more technical points, I will provide some commentary but in a separate email. I'll try to get my comments to you soon since as I'm sure you want to move forward in this process without too much delay. 

Thanks again.

From: Dimitris Zacharopoulos Sent: Tuesday, January 26, 2016 5:58 AM‎

Hello Peter and thank you for reviewing this request. I hope you have reviewed the DRAFT CP/CPS available from the bug 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, ho‎w 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, 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.

...snip...‎

[Dimitris Zacharopoulos]

On 1/2/2016 9:59 μμ, Peter Kurrasch wrote:
> Thank you, Dimitris, for your helpful response! I appreciate the
> clarifications you provided. I do like that there are fairly tight
> controls in place as I think it will serve everyone (both HARICA CA
> subscribers and the wider Internet population) well.
>
> I did review version 3.3 (which is much better than the previous
> version!) and the clarifications you mention below all sound‎
> reasonable to me. I have no further comments on them if you will be
> updating the CPS accordingly. For some of the more technical points, I
> will provide some commentary but in a separate email. I'll try to get
> my comments to you soon since as I'm sure you want to move forward in
> this process without too much delay.
>
> Thanks again.
>
>

Thank you Peter,

We do plan to update these language issues and relevant parts of our
CP/CPS during our scheduled annual audit in May - June 2016.

Thank you again for the review.


Sincerely,
Dimitris Zacharopoulos.



> *From: *Dimitris Zacharopoulos
> *Sent: *Tuesday, January 26, 2016 5:58 AM‎

>
>
>
> 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

> signing a certain MoU <http://www.harica.gr/documents/MoU-EN.pdf>,

[Kathleen Wilson]

On 2/2/16 1:31 PM, Dimitris Zacharopoulos wrote:
> On 1/2/2016 9:59 μμ, Peter Kurrasch wrote:
>> Thank you, Dimitris, for your helpful response! I appreciate the
>> clarifications you provided. I do like that there are fairly tight
>> controls in place as I think it will serve everyone (both HARICA CA
>> subscribers and the wider Internet population) well.
>>
>> I did review version 3.3 (which is much better than the previous
>> version!) and the clarifications you mention below all sound‎
>> reasonable to me. I have no further comments on them if you will be
>> updating the CPS accordingly. For some of the more technical points, I
>> will provide some commentary but in a separate email. I'll try to get
>> my comments to you soon since as I'm sure you want to move forward in
>> this process without too much delay.
>>
>

> Thank you Peter,
>
> We do plan to update these language issues and relevant parts of our
> CP/CPS during our scheduled annual audit in May - June 2016.

All,

Many thanks to those of you who reviewed and commented on this request

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.

I did not find any show stoppers in this discussion, so I think it is
fine to proceed with the inclusion process and track the update to
HARICA's CP/CPS separately. Does anyone disagree?

Are there any further concerns, questions, or comments for HARICA CA
before I close this discussion and recommend approval of their request
in the bug?

Thanks,
Kathleen

[Dimitris Zacharopoulos]

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 (pub...@cabforum.org). 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.

[Peter Kurrasch]

Hi Dimitris, 

‎You certainly echo the sentiment of others in this forum by directing me to the CABF but my concerns are particular to HARICA at this point. Simply put, the CABF BR has security gaps in section 3.2.2.4 which can result in certificate mis-issuance. There is no reason HARICA must tolerate such gaps in its own policies.

So the question I guess comes down to this: Is HARICA able to tighten its own controls regarding section 3.2.2.4 and go beyond what the BR has outlined?

Thanks.

From: Dimitris Zacharopoulos Sent: Monday, February 22, 2016 2:23 AM‎

>> 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 (pub...@cabforum.org). 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.‎

[Dimitris Zacharopoulos]

On 22/2/2016 6:52 μμ, Peter Kurrasch wrote:
> Hi Dimitris,
>
> ‎You certainly echo the sentiment of others in this forum by directing
> me to the CABF but my concerns are particular to HARICA at this point.
> Simply put, the CABF BR has security gaps in section 3.2.2.4 which can
> result in certificate mis-issuance. There is no reason HARICA must
> tolerate such gaps in its own policies.
>
> So the question I guess comes down to this: Is HARICA able to tighten
> its own controls regarding section 3.2.2.4 and go beyond what the BR
> has outlined?
>
> Thanks.

Dear Peter,

The CA/B Forum has been working on updating that section of the BRs
regarding domain name validation rules. The latest proposal (not
officially approved yet) removes the ability for CAs to use validation
procedures other than the options that will be listed. HARICA will
update the CP/CPS when the BRs are updated. In any case, options 1-3 are
rarely used, mainly because the gr domain does not support whois
queries. Option 6 is also rarely being used. Nevertheless, we would like
to have all available approved options at our disposal.


Sincerely,
Dimitris

>
> *From: *Dimitris Zacharopoulos
> *Sent: *Monday, February 22, 2016 2:23 AM‎

[Kathleen Wilson]

On 2/2/16 2:46 PM, Kathleen Wilson wrote:
> All,
>
> Many thanks to those of you who reviewed and commented on this request
> 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.
>
> I did not find any show stoppers in this discussion, so I think it is
> fine to proceed with the inclusion process and track the update to
> HARICA's CP/CPS separately. Does anyone disagree?
>
> Are there any further concerns, questions, or comments for HARICA CA
> before I close this discussion and recommend approval of their request
> in the bug?
>

To summarize this discussion:

1) HARICA plans to update their CP/CPS in May-June of this year, and
incorporate the updates that they indicated in this discussion. I plan
to track that action item in parallel of the inclusion process.

2) Dimitris provided further information about how HARICA performs
domain validation, but I do not expect them to modify the validation
rules in their CP/CPS until after the BRs are updated in this regards.

3) There was a separate discussion regarding the output of the certlint
tests that found that these new root certificates have serial number 00.
That sparked discussion in the CAB Forum, which I think will address
this moving forward. I believe this is not a show stopper for this
particular root inclusion request.

Therefore, it is my intention to close this discussion and recommend
approval in the bug.

Please let me know if I missed anything that needs to be address before
moving forward with approval of this request.

Thanks,
Kathleen

[kwi...@mozilla.com]

On Wednesday, March 2, 2016 at 5:11:43 PM UTC-8, Kathleen Wilson wrote:
>
> To summarize this discussion:
>
> 1) HARICA plans to update their CP/CPS in May-June of this year, and
> incorporate the updates that they indicated in this discussion. I plan
> to track that action item in parallel of the inclusion process.
>
> 2) Dimitris provided further information about how HARICA performs
> domain validation, but I do not expect them to modify the validation
> rules in their CP/CPS until after the BRs are updated in this regards.
>
> 3) There was a separate discussion regarding the output of the certlint
> tests that found that these new root certificates have serial number 00.
> That sparked discussion in the CAB Forum, which I think will address
> this moving forward. I believe this is not a show stopper for this
> particular root inclusion request.
>
> Therefore, it is my intention to close this discussion and recommend
> approval in the bug.
>
> Please let me know if I missed anything that needs to be address before
> moving forward with approval of this request.
>
> Thanks,
> Kathleen

I sent the following earlier today, but it hasn't shown up yet, so trying again...

Thanks to all of you who reviewed and commented on this request from HARICA 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.

I am not aware of any issues that would prevent us from moving forward with this request. Therefore, I will recommend approval in the bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=1201423

The action item to update the CP/CPS will be tracked in the bug, in parallel with the rest of the inclusion process.

Any further follow-up on this request should be added directly to the bug.

Thanks,
Kathleen

[Kathleen Wilson]

On Monday, March 7, 2016 at 12:51:14 PM UTC-8, Kathleen Wilson wrote:
>
> The action item to update the CP/CPS will be tracked in the bug, in parallel with the rest of the inclusion process.
>

The updated CP/CPS (version 3.3) has been posted on HARICA's website:
http://www.harica.gr/documents/CPS-EN.pdf

Kathleen