HARICA Root Inclusion Request

[Kathleen Wilson]

HARICA has applied to add the “Hellenic Academic and Research
Institutions RootCA 2011” root certificate, and enable all three trust bits.

The main goal of HARICA (Hellenic Academic and Research Institutions
Certification Authority / Greek Universities Network) is the deployment
of an infrastructure for secure communication between the collaborating
members of the Greek Academic and Research Institutions. All HARICA
certificates have a clear mark indicating that the certificate is
subject to Greek laws and their CPS.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=581901

And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#HARICA

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=569483

Noteworthy points:

* The primary document is the CPS, which is provided in English.

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

* HARICA’s original request was to include the “Hellenic Academic and
Research Institutions RootCA 2006” root certificate, but its signature
algorithm is MD5. Then HARICA created a new root certificate, “Hellenic
Academic and Research Institutions RootCA 2010”, with the SHA-1
signature algorithm. While waiting in the queue for public discussion,
HARICA decided to replace the “Hellenic Academic and Research
Institutions RootCA 2010” root certificate with a new certificate in
order to fix an issue they noticed with the AuthorityKeyIdentifier
extension and the certificate policy OID.

* Root Cert URL: http://www.harica.gr/certs/HaricaRootCA2011.der

* This new root will eventually have the same intermediate CAs as
HARICA’s MD5 root; the CA hierarchy diagram is here:
https://bugzilla.mozilla.org/attachment.cgi?id=460450

* The hierarchy that will be transitioned to this root consists of
several internally-operated subordinate CAs and one externally-operated
subordinate CA. Each subordinate CA is used for a different academic or
research institution.
** HARICA has implemented technical restrictions (at the RA and CA
level) allowing only specific domains affiliated with their constituency
to be included in certificates.

* HARICA has confirmed that they have in place multi-factor
authentication for server certificates, and multi-factor authentication
to access the RA and CA engines.

* The request is to enable all three trust bits.

* CPS section 1.3.2: Registration Authorities (RA) are entities
responsible for identity validation of all applicants before the
issuance of the certificate. They transfer the requests to the
particular Certification Authority in a secure manner. GUnet is the
central Registration Authority of HARICA and apply strict procedures for
users’ authentication.

* CPS section 3.2.2: The Registration Authority must confirm that the
subscriber belongs to the Institution, the name of which is included in
the certificate. The subscriber must:
a) be registered in the official directory service of her/his
Institution and her/his Institution must appear in this record, or
b) Possess an electronic mail address in the official mail service of
the Institution and the administration of her/his Institution confirms
its relationship with the subscriber.

* CPS section 3.2.3.1: The certificates of individuals that are issued
by the HARICA PKI must be checked for identification. There are two
classes of user certificates. Class A includes certificates whose
private key is generated and resides in a secure cryptographic device
(eToken or smartcard) and are issued under the presence of authorized
personnel of the RA. Class B includes certificates whose private key has
been generated using some software (software certificate store). Note
that there is a secure identification of the recipient with her/his
physical presence and an acceptable official document proving his
identity in both classes of certificates.
The Registration Authority relies on the control of identity performed
by the institutions the subscriber belongs to and uses authentication
ways of user identities that are available in the institutions in order
to check the identity. The collaborating institutions are compelled to
have certified the identity of a user by means of an official document
that bears the photograph of the beneficiary (eg police identity,
passport, driving license, student identity card) and which is
considered reliable by the familiar institution. Alternatively, the RA
of HARICA can execute the above process of applicant identification.
In case the familiar institution of the user, according to its policy,
has already performed a procedure of physical identity verification in
the past (e.g. for the provision of a user account or e-mail address)
there is no need to repeat the procedure but a typical confirmation
through the officially certified e-mail address of the user is sufficient.

* CPS section 3.2.3.1: HARICA central RA uses two 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. If this procedure took
place before (e.g. for the creation of an e-mail account) then there is
no reason to be repeated.
** 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.
Certificates of Class A are recommended to include an extra
organizational unit (OU) in the subject field with the value ‘Class A –
Private Key created and stored in hardware CSP’. Certificates of Class B
are recommended to include an extra organizational unit (OU) in the
subject field with the value ‘Class B – Private Key created and stored
in software CSP’.

CPS section 3.2.3.2: The individual who is in charge of the operation of
the device and its conformity to the Certification Policy should possess
a certificate which was issued by a CA that conforms to the “HARICA
Certification Practice Statement/ Certification Policy”.
The subscriber submits the application for a device certificate on a web
interface where she/he must be authenticated presenting her/his personal
certificate. The issuance of a certificate for a device owned by an
institution other than the institution of its administrator, is not allowed.
HARICA central RA uses the following methods for device ownership
verification. First of all, issuance of an SSL/TLS certificate is only
allowed for domains belonging to each institution. Secondly, in order
for a user to apply for an SSL/TLS device certificate he must own a user
certificate which proves his identity. Then a verification e-mail is
sent to an institution's network operations center designated
administrator who verifies the validity of the FQDN of the certificate
request. He also checks that the person who applied for the certificate
is the rightful owner of the FQDN according to the institution's
database of users / servers.

CPS section 3.2.4: The certificates that are issued do not include
non-verified subscriber information.

* CPS section 9.16.2: Each subordinate Certification Authority approved
by HARICA PKI is committed to:
** Grant certificates with validity period within the limits of the
active employment (or other) relationship between the applicant and the
institution, according to the applicant’s affiliation (i.e student,
employee, faculty).
** Inform the parent Certification Authority immediately in case of
private key exposure.
** Protect the private keys, used for certificate signing, at least in
the security level that is described in the present document.
** Develop (optionally) its own policies and procedures of certification
which must be at least as strict and binding as the ones described in
the present document.
** In case an institution -within the HARICA constituency- wants to run
its own CA, it must provide an official audit certificate according to
the ETSI TS 101 456 (or equivalent) requirements

* There is currently one externally-operated subordinate CA:
** Company Name: Aristotle University of Thessaloniki Network Operations
Center
** Corporate URL: http://noc.auth.gr
** Certificate download URL:
http://www.pki.auth.gr/certs/AuthCentralCAR2.pem
** General CA hierarchy: AuthCentralCAR2 only issues sub-CAs, and had
the following three subordinate CAs: AuthNocCAR3 (issues user and server
certificates for the Network Operations Center of the University),
AuthUsersCAR3 (issues user certificates for the rest of the University),
AuthServersCAR3 (issues server certificates for the rest of the University).
** CP/CPS Link: http://www.pki.auth.gr/documents/CPS-EN.pdf
*** Section 3.2.2: The Registration Authority must confirm that the
subscriber belongs to the Aristotle University of Thessaloniki. The name
of AUTH is included in the certificate. The subscriber must: a) be
registered in the official directory service of the University, or b)
Possess an e-mail address in the official mail service of AUTH and the
administration services of AUTH must confirm the relationship with the
subscriber.
*** Ownership of domain name: sections 3.2.3.2 and 3.2.5
*** Ownership of e-mail: sections 3.2.3.1 and 3.2.5
*** Section 4.9.7: The CRL will be issued at least every five (5) days.
The CRL will be in effect for five (5) days. In case of subscribers
private key exposure or any other important security compromise an
updated CRL will be issued immediately.
** https://ocsp.pki.auth.gr.
** Audit:
http://www.trust-it.gr/userfiles/AUTH.2011.03.18.Rev1.7.English.pdf

* EV Policy OID: Not requesting EV treatment.

* Root Cert: http://www.harica.gr/certs/HaricaRootCA2011.der
** This new root cert was recently created to correct an issue with the
AuthorityKeyIdentifier extension; for more info see
https://bugzilla.mozilla.org/show_bug.cgi?id=581901#c20

* Test Website: https://www2.harica.gr

* CRL:
** http://crlv1.harica.gr/HaricaRootCA2011/crlv1.der.crl
** http://crlv1.harica.gr/HaricaAdministrationCAR1/crlv1.der.crl
** CPS 4.9.7: The CRL must be updated and published at least every five
(5) days.

* OCSP: http://ocsp.harica.gr
** CPS section 7.3: The use of OCSP is mandatory for all subordinate
Certification Authorities. The OCSP responders must conform to RFC2560.

* Audit: Annual audits are performed according to the ETSI TS 101 456
criteria. The most recent audit was performed by Deventum
(http://deventum.com), and posted on the Trust-IT website:
http://www.trust-it.gr/userfiles/Harica.2011.03.18.Rev1.2.ENG.pdf
** Note that this new root was created after the last audit, and will
need to be included in the next audit.
** A network security audit was performed at the same time as the ETSI
audit.

Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices):

* External RAs are allowed. CPS section 9.16.3: Each Registration
Authority manages the applications for subscriber registration.
** Each Registration Authority is responsible to receive certificate
applications from subscribers. It validates the identity of the
subscriber, confirms that the public key that is submitted belongs to
the subscriber and securely transmits the application to the CA.
** According to the certificate type, applications can be submitted via
face-to-face meeting with the interested party, via e-mail, via a secure
web form, or via any mechanism that securely identifies the user. The
application includes all information identifying the subscriber, and the
corresponding public key.
** Mass applications submission from a specific administrative
department is possible on behalf of the persons that belong to that
department or organization
** Each Registration Authority must verify if each person requesting a
personal certificate is the rightful owner of the certified e-mail address.
** Each Registration Authority must verify that the person requesting a
device certificate is the rightful owner and administrator of the
device’s FQDN.
** In case an institution -within the HARICA constituency- wants to run
its own RA, it must provide an official audit certificate according to
the ETSI TS 101 456 (or equivalent) requirements

This begins the discussion of the request from HARICA to add the
“Hellenic Academic and Research Institutions RootCA 2011” root
certificate, and enable all three trust bits. At the conclusion of this
discussion, I will provide a summary of issues noted and action items.
If there are no outstanding issues, then this request can be approved.
If there are outstanding issues or action items, then an additional
discussion may be needed as follow-up.

Kathleen

[Stephen Schultze]

Does HARICA offer some service to the general internet public, or is
this merely for use between members of HARICA?

I

[Dimitris Zacharopoulos]

On 26/10/2011 5:07 πμ, Stephen Schultze wrote:
> Does HARICA offer some service to the general internet public, or is
> this merely for use between members of HARICA?
>

HARICA issues certificates only for academic institutions who are
members of HARICA. However, people from academic institutions
communicate with the general internet public. Also, the general internet
public may use e-services from university servers.

So HARICA certificates are visible to the general internet public.

Best regards,
Dimitris Zacharopoulos.

> On 10/25/11 4:51 PM, Kathleen Wilson wrote:

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


--
Zacharopoulos Dimitris

Aristotle University of Thessaloniki
Network Operations Center

NOC-AUTH, Thessaloniki, Macedonia, Greece
Tel. N.O.C.: +30-2310998483
Fax. N.O.C.: +30-2310998492
E-Mail : ji...@ccf.auth.gr
Web : http://noc.auth.gr

[Stephen Schultze]

I think it's questionable whether we should be consider approving
entities that operate primarily as internal trust authorities. It seems
like our energies could be far better spent reviewing entities that
actually intend to offer some service to the general internet
population, and to encourage internal trust authorities to get their
users to deploy their trust anchor. This gets to Brian's earlier point
about prioritizing our list.

[Jürgen Brauckmann]

Stephen Schultze schrieb:

> I think it's questionable whether we should be consider approving
> entities that operate primarily as internal trust authorities.

HARICA is a CA for a national research and education network, just like
Internet2 in the USA. Many countries have such networks, and their user
base is typically rather large: Many different organisations
participating, with many users (up to several millions).

This is very different than a CA for a large company with
homogeneous structures.

Research network CAs often have a broad visibility to the public, more
like small country-level CAs.

Regards,
Juergen

[Dimitris Zacharopoulos]

On 26/10/2011 10:55 μμ, Stephen Schultze wrote:
> I think it's questionable whether we should be consider approving

> entities that operate primarily as internal trust authorities. It
> seems like our energies could be far better spent reviewing entities
> that actually intend to offer some service to the general internet
> population, and to encourage internal trust authorities to get their
> users to deploy their trust anchor. This gets to Brian's earlier
> point about prioritizing our list.
>

Dear Stephen,

Please consider the following arguments about how HARICA can be a
benefit to the general Internet public.

1) HARICA is a national research and academic organization. While the
certificates are issued only to member organizations, the general public
are relying parties. Candidate students (grads, phd), faculty, Academic
and Research Institutions all over the world can use HARICA's
e-services. Some examples about how relying parties can benefit from
HARICA are:

* digitally signed e-mail, documents, degrees, certificates that other
Academic Institutions validate in order to accept graduate students
* e-procurement services for research and academic institutions open
to the public companies that want to participate in a tender
* digitally signed software developed at research and academic
institutions for the general public
* e-courses open to the general public

Inclusion of this root certificate would positively impact not only the
general public in Greece but in other countries as well.

2) HARICA is managed by GUnet which is consisted of all Higher education
and Academic Institutions of Greece. It is operated by an experienced
team (full-time permanent staff with more than 15 years of experience)
that take security issues very seriously, constantly monitoring security
incidents in order to keep HARICA systems protected. In the past two
years, we have been monitoring this particular list and gained much
experience about bad practices from other CAs. I trust we have acted
proactively by improving our policy, the security network and
operational procedures. We have also implemented technical means to
restrict the domains that sub-CAs can issue certs for (see Comment #22
<https://bugzilla.mozilla.org/show_bug.cgi?id=581901#c22> in the bug
report). This technical team and HARICA infrastructure along with GUnet
management consist a stable environment.

3) HARICA has already issued thousands of certificates, used in many
e-services and has proved the necessity of PKI to the Academic and
Research community of Greece. The next step is to expand its services to
the general population and the inclusion of this root certificate is the
best vehicle to accomplish this goal.


Best regards,
Dimitris Zacharopoulos.

> On 10/26/11 12:59 PM, Dimitris Zacharopoulos wrote:

>>>> A --

>>>> Private Key created and stored in hardware CSP’. Certificates of
>>>> Class B
>>>> are recommended to include an extra organizational unit (OU) in the

>>>> subject field with the value ‘Class B -- Private Key created and

>>>> The CRL will be in effect for five (5) days. In case of subscriber?s

[Eddy Nigg]

On 10/31/2011 12:31 PM, From Dimitris Zacharopoulos:

> 1) HARICA is a national research and academic organization. While the
> certificates are issued only to member organizations, the general
> public are relying parties.

But doesn't this apply to any private CA that uses the certificates on
the Internet? I guess the benefit for Mozilla would be rather small
(considering the risk of another root) - maybe having a parents CA that
is already included with Mozilla sign this root might be more beneficial.

CAs that don't issue certificates to the general public have probably
limited use for the typical user of Mozilla software (or any software
for that matter).

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

[ianG]

On 31/10/11 21:31 PM, Dimitris Zacharopoulos wrote:

> On 26/10/2011 10:55 ??, Stephen Schultze wrote:
>> I think it's questionable whether we should be consider approving
>> entities that operate primarily as internal trust authorities. It
>> seems like our energies could be far better spent reviewing entities
>> that actually intend to offer some service to the general internet
>> population, and to encourage internal trust authorities to get their
>> users to deploy their trust anchor. This gets to Brian's earlier
>> point about prioritizing our list.
>>
>
> Dear Stephen,
>
> Please consider the following arguments about how HARICA can be a
> benefit to the general Internet public.

This is in error, and unnecessary. Mozilla does not serve "the general
Internet public." It serves those who download its software products.
Firefox and the like.

"1. We will determine which CA certificates are included in software
products distributed by Mozilla, based on the benefits and risks of such
inclusion *to typical users of those products*."

Whether it is an open or closed net makes no difference, IMHO. If the
people in the network use Firefox, then they are likely typical users.

iang

[Kathleen Wilson]

On 10/31/11 1:22 PM, Eddy Nigg wrote:
> On 10/31/2011 12:31 PM, From Dimitris Zacharopoulos:
>> 1) HARICA is a national research and academic organization. While the
>> certificates are issued only to member organizations, the general
>> public are relying parties.
>
> But doesn't this apply to any private CA that uses the certificates on
> the Internet? I guess the benefit for Mozilla would be rather small
> (considering the risk of another root) - maybe having a parents CA that
> is already included with Mozilla sign this root might be more beneficial.
>
> CAs that don't issue certificates to the general public have probably
> limited use for the typical user of Mozilla software (or any software
> for that matter).
>

There are government CAs in our program who only issue certs internally,
but the general public are relying parties. Aren't research/academic
organizations at the national level similar?

As long as there is reasonable assurance that the CA operates at the
level of security and operations that we expect of our CAs, I don't see
why we wouldn't want government and national research organizations in
our program.

Kathleen

[Eddy Nigg]

On 10/31/2011 11:32 PM, From Kathleen Wilson:

> There are government CAs in our program who only issue certs
> internally, but the general public are relying parties. Aren't
> research/academic organizations at the national level similar?
>

Perhaps we have set priorities right or different - not sure. First of
all this isn't a government CA as we know it from elsewhere. It is an
educational institution, maybe an important one for Greece, but still,
nothing more than that.

But now consider that every university that exists in the US would apply
for their own CA root. Would you think that's reasonable? Or just about
any university or educational institution anywhere? Wouldn't be those
considered private or enterprise CAs?

Now if a commercial company would apply for their root to be included,
probably with many, many more relying parties and potential users of
Mozilla software, would this be accepted as well? Maybe it would, I
don't know.

But this request is probably an opportunity to set a balance and set
certain priorities about which type of CAs it wants to support and which
not.

We've discussed in the past about possible limitations, such as
including a root only for a certain language or country. Or limiting for
certain TLDs. But those capabilities don't exist so far, I'm afraid the
decision will have to either this or that.

[Dimitris Zacharopoulos]

On 1/11/2011 1:03 πμ, Eddy Nigg wrote:
> On 10/31/2011 11:32 PM, From Kathleen Wilson:

>> There are government CAs in our program who only issue certs
>> internally, but the general public are relying parties. Aren't
>> research/academic organizations at the national level similar?
>>
>

> Perhaps we have set priorities right or different - not sure. First of
> all this isn't a government CA as we know it from elsewhere. It is an
> educational institution, maybe an important one for Greece, but still,
> nothing more than that.
>
> But now consider that every university that exists in the US would
> apply for their own CA root. Would you think that's reasonable? Or
> just about any university or educational institution anywhere?
> Wouldn't be those considered private or enterprise CAs?
>
> Now if a commercial company would apply for their root to be included,
> probably with many, many more relying parties and potential users of
> Mozilla software, would this be accepted as well? Maybe it would, I
> don't know.
>
> But this request is probably an opportunity to set a balance and set
> certain priorities about which type of CAs it wants to support and
> which not.
>
> We've discussed in the past about possible limitations, such as
> including a root only for a certain language or country. Or limiting
> for certain TLDs. But those capabilities don't exist so far, I'm
> afraid the decision will have to either this or that.
>

Dear Eddy,

Please let me clarify that HARICA is consisted of ALL Universities,
Higher Education Institutions (different than Universities) and Research
Institutions of the Hellenic Republic. HARICA is just operated by
Aristotle University of Thessaloniki on behalf of this community.


Best regards,
Dimitris Zacharopoulos.

--
HARICA Public Key Infrastructure
http://www.harica.gr

Zacharopoulos Dimitris
AUTH Central Communication Facilities, Network Operations Center

[ianG]

On 1/11/11 10:03 AM, Eddy Nigg wrote:
> On 10/31/2011 11:32 PM, From Kathleen Wilson:

>> There are government CAs in our program who only issue certs
>> internally, but the general public are relying parties. Aren't
>> research/academic organizations at the national level similar?
>>
>

> Perhaps we have set priorities right or different - not sure. First of
> all this isn't a government CA as we know it from elsewhere. It is an
> educational institution, maybe an important one for Greece, but still,
> nothing more than that.
>
> But now consider that every university that exists in the US would
> apply for their own CA root. Would you think that's reasonable? Or
> just about any university or educational institution anywhere?

What is generally considered to be reasonable in the NGO world is that
NGOs such as Mozilla support the work of other non-commercial
enterprises, including but not limited to universities and educational
institutions.

What is generally considered not reasonable is that NGOs provide facade
or cover for the commercial exploitation of markets, unless they clearly
identify themselves as industry bodies or associations.

As Mozilla Foundation has not as yet identified itself as an industry
body, and as engaged in a commercial enterprise or supporting the
enterprise of other commercial bodies, the onus will be on Mozilla to
explain why it is supporting commercial CAs and why it is discriminating
against universities, educational institutions and other non-commercial
entities.

> Wouldn't be those considered private or enterprise CAs?

It would indeed be convenient if we could regularise the commercial
franchise of Mozilla Foundation's root list such that a few commercial
CAs handle the business, and they could be relied upon to sell private
and enterprise subroots to others, including non-profits, universities,
foundations, etc. This would scale nicely.

But, to do so requires a change in the policy. Point 1 is very clear --
users and software is the nexus:

"1. We will determine which CA certificates are included **in
software products distributed by Mozilla**, based on the benefits and
risks of such inclusion **to typical users of those products**."

All Harica needs to establish is that they have substantial use of
Mozilla products, and their users are typical users of those products.

(Also the Manifesto would have to change. Indeed, the Manifesto
probably should be changed, but that's another foodfight for another day.)

iang

[Eddy Nigg]

On 11/01/2011 01:03 PM, From ianG:

> What is generally considered not reasonable is that NGOs provide
> facade or cover for the commercial exploitation of markets, unless
> they clearly identify themselves as industry bodies or associations.

As to my knowledge Mozilla doesn't earn anything from CAs in general,
except the ability to rely on their work etc...

Interestingly Mozilla needs the (other) commercial companies to provide
it with fuel to operate. Probably it's not clear cut, besides that
Mozilla the non-profit foundation and Mozilla Inc. are probably two
different animals as well.

>
> As Mozilla Foundation has not as yet identified itself as an industry
> body, and as engaged in a commercial enterprise or supporting the
> enterprise of other commercial bodies, the onus will be on Mozilla to
> explain why it is supporting commercial CAs and why it is
> discriminating against universities, educational institutions and
> other non-commercial entities.
>

I don't think that's case at all, I don't see discrimination. But there
is a discussion where people voice their opinions about which type of
CAs Mozilla should support. Legitimate in my opinion to ask those
questions from time to time.

[Stephen Schultze]

Dimitris, can you expand on what Kathleen described below and point to
your documentation on the matter? I see your answer here:

https://bugzilla.mozilla.org/show_bug.cgi?id=581901#c22

"HARICA has implemented technical restrictions (at the RA and CA level)

allowing only specific domains affiliated with our constituency to be
included in certificates."

....but I'd like to know more about what that means. For example, is
this different for each SubCA? How in particular is the check
implemented? Etc.

Regards,
Steve

On 10/25/11 4:51 PM, Kathleen Wilson wrote:

[Dimitris Zacharopoulos]

On 2/11/2011 7:59 μμ, Stephen Schultze wrote:
> Dimitris, can you expand on what Kathleen described below and point to
> your documentation on the matter? I see your answer here:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=581901#c22
>

> "HARICA has implemented technical restrictions (at the RA and CA

> level) allowing only specific domains affiliated with our constituency

> to be included in certificates."
>

> ....but I'd like to know more about what that means. For example, is
> this different for each SubCA? How in particular is the check
> implemented? Etc.
>
> Regards,
> Steve
>
> On 10/25/11 4:51 PM, Kathleen Wilson wrote:

>> ** HARICA has implemented technical restrictions (at the RA and CA
>> level) allowing only specific domains affiliated with their constituency
>> to be included in certificates.

Of course. Each member that belongs to an Institution can only issue
certificates (user or server) that belong to that institution's domain.
For example, a member of Aristotle University of Thessaloniki (domain
auth.gr) can only request a certificate with @auth.gr or *.auth.gr.
These limitations are implemented at the RA and the CA engine for all
subCAs. Each Institution has its own subCA (operated by HARICA at
HARICA's premises). Of course, wildcards are not allowed and only
verified e-mails and FQDNs are allowed to be requested as described in
our CP/CPS (check-out the information gathering document for specific
details).

HARICA's implementation is based on white lists (only specific domains
of our constituency are allowed to be issued).

The checks are coded inside the RA and CA system. In addition to that,
all server certificates are manually verified by a human that checks the
subject, altSubjectName and basically all fields of the request.

Please let me know if you request any further information about this.


Best regards,
Dimitris.

[Tom Lowenthal]

Quote:

> I don't see why we wouldn't want government and national research
> organizations in our program.

I think that we want as few entities as possible in our program. Unless
there is a really good reason why an entity's addition is required, that
request should be rejected.

HARICA seems to cater to a specific small group of people who join a
certain community. Members of that community should add HARICA's root to
their software. Nobody else should be exposed to the risk that this new
authority might be compromised.

On 10/31/2011 02:32 PM, Kathleen Wilson wrote:
> On 10/31/11 1:22 PM, Eddy Nigg wrote:

>> On 10/31/2011 12:31 PM, From Dimitris Zacharopoulos:
>>> 1) HARICA is a national research and academic organization. While the
>>> certificates are issued only to member organizations, the general
>>> public are relying parties.
>>
>> But doesn't this apply to any private CA that uses the certificates on
>> the Internet? I guess the benefit for Mozilla would be rather small
>> (considering the risk of another root) - maybe having a parents CA that
>> is already included with Mozilla sign this root might be more beneficial.
>>
>> CAs that don't issue certificates to the general public have probably
>> limited use for the typical user of Mozilla software (or any software
>> for that matter).
>>
>
>

> There are government CAs in our program who only issue certs internally,
> but the general public are relying parties. Aren't research/academic
> organizations at the national level similar?
>

> As long as there is reasonable assurance that the CA operates at the
> level of security and operations that we expect of our CAs, I don't see
> why we wouldn't want government and national research organizations in
> our program.
>
> Kathleen

[Dimitris Zacharopoulos]

On 4/11/2011 1:54 πμ, Tom Lowenthal wrote:
> I think that we want as few entities as possible in our program. Unless
> there is a really good reason why an entity's addition is required, that
> request should be rejected.
>
> HARICA seems to cater to a specific small group of people who join a
> certain community. Members of that community should add HARICA's root to
> their software. Nobody else should be exposed to the risk that this new
> authority might be compromised.

I understand the concerns raised by Tom Lowenthal, especially after the
Diginotar meltdown. However, I can assure you that we have taken every
necessary measure to prevent similar things from happening. I hope that
HARICA is not considered "small group of people" because the Academic
and Research community in Greece only, counts nearly a million users,
let alone servers and trusted third party Institutions and people around
the world. Installing a self-signed root certificate to more than a
million devices is definitely not practical.

Best regards,
Dimitris Zacharopoulos.

--
HARICA Public Key Infrastructure
http://www.harica.gr

Zacharopoulos Dimitris

AUTH Central Communication Facilities, Network Operations Center

[Stephen Schultze]

Can you give a comprehensive or representative list of the domain names
that certificates will be issued to under the HARICA root?

[Dimitris Zacharopoulos]

On 10/11/2011 4:27 μμ, Stephen Schultze wrote:
> Can you give a comprehensive or representative list of the domain
> names that certificates will be issued to under the HARICA root?

Dear Steve,

We have attached a representative list of eligible domain names of Greek
Academic and Research institutions under HARICA in comment 29
<https://bugzilla.mozilla.org/show_bug.cgi?id=581901#c29>. This list is
not comprehensive because each of these institutions may have other
affiliated sub-divisions under the same legal entity with different
domain names. Each domain name is verified according to HARICA
procedures as described in our CP/CPS.

[Stephen Schultze]

Dimitris,

Thanks for your responsiveness and clarity. It appears that all of the
domains in question are under the .gr TLD. I suggest that you constrain
your root CA cert to issue Sub CA certs only for .gr domains, using Name
Constraints as specified in RFC 5280 (and marked as critical), which is
now implemented by NSS/Mozilla/Firefox:

https://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/131420ae821960df/73074acbe64096fe#73074acbe64096fe

I suggest that you further constrain each Sub CA cert to the
second-level domains that it is known to be authorized to issue for.

This would go a long way toward assuaging the my concerns about the
appropriateness of your root for inclusion.

Do others have thoughts on this?

Steve

[Dimitris Zacharopoulos]

On 11/11/2011 5:10 μμ, Stephen Schultze wrote:
> Dimitris,
>

> Thanks for your responsiveness and clarity. It appears that all of
> the domains in question are under the .gr TLD. I suggest that you
> constrain your root CA cert to issue Sub CA certs only for .gr
> domains, using Name Constraints as specified in RFC 5280 (and marked
> as critical), which is now implemented by NSS/Mozilla/Firefox:
>
> https://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/131420ae821960df/73074acbe64096fe#73074acbe64096fe
>
>
> I suggest that you further constrain each Sub CA cert to the
> second-level domains that it is known to be authorized to issue for.
>
> This would go a long way toward assuaging the my concerns about the
> appropriateness of your root for inclusion.
>
> Do others have thoughts on this?
>
> Steve
>

Hi Steve,

We haven't really thought about this option but it would probably limit
some eligible affiliated organizations (international projects,
parterships, etc) that might be outside the .gr domain. The list we
provided are only for the domains of the Hellenic Academic and Research
Institutions and not their projects and research sites.

Of course, most of these affiliated organizations would probably not
include .com and other "commercial" domains but might very well include
.org, .eu and many more (Aristotle University used to have an auth.edu
domain from educause). Is there a way to "exclude" specific domains like
".com"?

I guess we will have to look into these issues and get back to you.

Thanks again,
Dimitris Zacharopoulos.

>
> On 11/11/11 9:25 AM, Dimitris Zacharopoulos wrote:

>> On 10/11/2011 4:27 μμ, Stephen Schultze wrote:
>>> Can you give a comprehensive or representative list of the domain
>>> names that certificates will be issued to under the HARICA root?
>>
>> Dear Steve,
>>
>> We have attached a representative list of eligible domain names of Greek
>> Academic and Research institutions under HARICA in comment 29
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=581901#c29>. This list is
>> not comprehensive because each of these institutions may have other
>> affiliated sub-divisions under the same legal entity with different
>> domain names. Each domain name is verified according to HARICA
>> procedures as described in our CP/CPS.
>>
>>
>> Best regards,
>> Dimitris Zacharopoulos.
>>
>>
>

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

--
Zacharopoulos Dimitris
Aristotle University of Thessaloniki

Network Operations Center
NOC-AUTH, Thessaloniki, Macedonia, Greece
Tel. N.O.C.: +30-2310998483
Fax. N.O.C.: +30-2310998492
E-Mail : ji...@ccf.auth.gr

Web : http://noc.auth.gr

[Eddy Nigg]

On 11/11/2011 05:10 PM, From Stephen Schultze:

> This would go a long way toward assuaging the my concerns about the
> appropriateness of your root for inclusion.
>
> Do others have thoughts on this?
>

This would be in line what we've discussed in similar situations
already. It might make perfect sense for this CA and also reduce the
risk associated (not only for Mozilla, but very much also for the CA).

[Eddy Nigg]

On 11/11/2011 05:33 PM, From Dimitris Zacharopoulos:

> Of course, most of these affiliated organizations would probably not
> include .com and other "commercial" domains but might very well
> include .org, .eu and many more (Aristotle University used to have an
> auth.edu domain from educause). Is there a way to "exclude" specific
> domains like ".com"?
>

You can have more than one TLD, for example .edu .eu and .gr would make
perfect sense in my opinion.

[Dimitris Zacharopoulos]

On 11/11/2011 5:33 μμ, Dimitris Zacharopoulos wrote:

> On 11/11/2011 5:10 μμ, Stephen Schultze wrote:
>> Dimitris,
>>

>> Thanks for your responsiveness and clarity. It appears that all of
>> the domains in question are under the .gr TLD. I suggest that you
>> constrain your root CA cert to issue Sub CA certs only for .gr
>> domains, using Name Constraints as specified in RFC 5280 (and marked
>> as critical), which is now implemented by NSS/Mozilla/Firefox:
>>
>> https://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/131420ae821960df/73074acbe64096fe#73074acbe64096fe
>>
>>
>> I suggest that you further constrain each Sub CA cert to the
>> second-level domains that it is known to be authorized to issue for.
>>

>> This would go a long way toward assuaging the my concerns about the
>> appropriateness of your root for inclusion.
>>
>> Do others have thoughts on this?
>>

>> Steve
>>
>
> Hi Steve,
>
> We haven't really thought about this option but it would probably
> limit some eligible affiliated organizations (international projects,
> parterships, etc) that might be outside the .gr domain. The list we
> provided are only for the domains of the Hellenic Academic and
> Research Institutions and not their projects and research sites.
>

> Of course, most of these affiliated organizations would probably not
> include .com and other "commercial" domains but might very well
> include .org, .eu and many more (Aristotle University used to have an
> auth.edu domain from educause). Is there a way to "exclude" specific
> domains like ".com"?
>

> I guess we will have to look into these issues and get back to you.
>
> Thanks again,
> Dimitris Zacharopoulos.

Dear all,

After thorough examination, HARICA has decided to constrain all CAs as
proposed. In addition to the current technical restrictions mentioned in
our previous e-mails, the "Name Constraints" extension will be used
according to RFC 5280 and will be marked as critical.

We propose HARICA ROOT CA to be limited to: .gr, .eu, .edu, .org. We
believe these domains will cover 99% of HARICA needs.
Each sub CA will be limited to each institution's domain.

Especially for the ".org" domain, in case an institution requires a
server certificate for a particular research project (no user
certificates will be allowed for this subCA), they will request it from
a single subCA, limited only to .org. This CA doesn't currently exist
but will be created upon first request of such a certificate.

If the above are satisfactory for the Mozilla CA inclusion program and
there is no further comment or concern, we will proceed with the proper
modifications to our CP/CPS.

Thank you all for your comments and suggestions.


Best regards,
Dimitris Zacharopoulos

[Stephen Schultze]

On 11/14/11 5:04 AM, Dimitris Zacharopoulos wrote:
> On 11/11/2011 5:33 οΏ½οΏ½, Dimitris Zacharopoulos wrote:

This is very encouraging, and I am grateful for your responsiveness.

I of course don't speak for Mozilla, but I expect that this will be
welcomed by them as well.

Steve

[Kathleen Wilson]

On 11/14/11 9:15 AM, Stephen Schultze wrote:
> On 11/14/11 5:04 AM, Dimitris Zacharopoulos wrote:

>> On 11/11/2011 5:33 μμ, Dimitris Zacharopoulos wrote:
>> Dear all,
>>
>> After thorough examination, HARICA has decided to constrain all CAs as
>> proposed. In addition to the current technical restrictions mentioned in
>> our previous e-mails, the "Name Constraints" extension will be used
>> according to RFC 5280 and will be marked as critical.
>>
>> We propose HARICA ROOT CA to be limited to: .gr, .eu, .edu, .org. We
>> believe these domains will cover 99% of HARICA needs.
>> Each sub CA will be limited to each institution's domain.
>>
>> Especially for the ".org" domain, in case an institution requires a
>> server certificate for a particular research project (no user
>> certificates will be allowed for this subCA), they will request it from
>> a single subCA, limited only to .org. This CA doesn't currently exist
>> but will be created upon first request of such a certificate.
>>
>> If the above are satisfactory for the Mozilla CA inclusion program and
>> there is no further comment or concern, we will proceed with the proper
>> modifications to our CP/CPS.
>>
>> Thank you all for your comments and suggestions.
>
> This is very encouraging, and I am grateful for your responsiveness.
>
> I of course don't speak for Mozilla, but I expect that this will be
> welcomed by them as well.
>
> Steve
>

I believe that this solution satisfies the concerns that have been
raised during this discussion.

If anyone else has comments/feedback on this certificate inclusion
request, please speak up now.

Thanks,
Kathleen

[Eddy Nigg]

On 11/14/2011 07:52 PM, From Kathleen Wilson:

> I believe that this solution satisfies the concerns that have been
> raised during this discussion.
>

Yes, that's excellent!

[ianG]

On 15/11/11 04:52 AM, Kathleen Wilson wrote:
> On 11/14/11 9:15 AM, Stephen Schultze wrote:

>> On 11/14/11 5:04 AM, Dimitris Zacharopoulos wrote:

>>> On 11/11/2011 5:33 μμ, Dimitris Zacharopoulos wrote:
>>> Dear all,
>>>
>>> After thorough examination, HARICA has decided to constrain all CAs as
>>> proposed. In addition to the current technical restrictions
>>> mentioned in
>>> our previous e-mails, the "Name Constraints" extension will be used
>>> according to RFC 5280 and will be marked as critical.
>>>
>>> We propose HARICA ROOT CA to be limited to: .gr, .eu, .edu, .org. We
>>> believe these domains will cover 99% of HARICA needs.
>>> Each sub CA will be limited to each institution's domain.
>>>
>>> Especially for the ".org" domain, in case an institution requires a
>>> server certificate for a particular research project (no user
>>> certificates will be allowed for this subCA), they will request it from
>>> a single subCA, limited only to .org. This CA doesn't currently exist
>>> but will be created upon first request of such a certificate.
>>>
>>> If the above are satisfactory for the Mozilla CA inclusion program and
>>> there is no further comment or concern, we will proceed with the proper
>>> modifications to our CP/CPS.
>>>
>>> Thank you all for your comments and suggestions.
>>
>> This is very encouraging, and I am grateful for your responsiveness.
>>
>> I of course don't speak for Mozilla, but I expect that this will be
>> welcomed by them as well.
>>
>> Steve
>>
>
>

> I believe that this solution satisfies the concerns that have been
> raised during this discussion.
>

> If anyone else has comments/feedback on this certificate inclusion
> request, please speak up now.

Yes, I would like to raise the yellow card to Mozilla Foundation.

I understand that HARICA had gone through this process and been accepted
regardless of its narrower userbase of educational/research/academic focus.

HARICA then voluntarily decided to put in some limits on its subroots,
after sustained pressure from the commercial CAs.

I would like to get a public understanding on these points: HARICA is
not required to constrain their subroots, and is not limited because of
their educational/research/academic focus. There is no precedent
established here on grounds raised here.

In the alternate, if the above points are not the case: can someone at
Mozilla Foundation look up the IRS filing for 501(c)(3) or whatever and
confirm to this group that Mozilla Foundation's tax status is not at
risk due to discrimination in this case?

iang

[Rob Stradling]

On Tuesday 15 Nov 2011 11:25:15 ianG wrote:
<snip>

> > If anyone else has comments/feedback on this certificate inclusion
> > request, please speak up now.
>
> Yes, I would like to raise the yellow card to Mozilla Foundation.
>
> I understand that HARICA had gone through this process and been accepted
> regardless of its narrower userbase of educational/research/academic focus.
>
> HARICA then voluntarily decided to put in some limits on its subroots,
> after sustained pressure from the commercial CAs.

Ian, what "sustained pressure from the commercial CAs" are you referring to?

I see comments in this thread from Eddy, but he only represents one CA
(StartCom).

Most of the "pressure" appears to have come from Steve Schultze, who AFAIK
does not represent any CA.

> I would like to get a public understanding on these points: HARICA is
> not required to constrain their subroots, and is not limited because of
> their educational/research/academic focus. There is no precedent
> established here on grounds raised here.
>
> In the alternate, if the above points are not the case: can someone at
> Mozilla Foundation look up the IRS filing for 501(c)(3) or whatever and
> confirm to this group that Mozilla Foundation's tax status is not at
> risk due to discrimination in this case?
>
> iang
>

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

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Eddy Nigg]

On 11/15/2011 01:43 PM, From Rob Stradling:

> I see comments in this thread from Eddy, but he only represents one CA
> (StartCom).

....who has been here for ages already and probably represents the least
commercial CA of the commercial CAs if at all :-)

In fact I mostly don't represent a CA here, but it's hard to get for
people like Ian that people can wear different hats.

[Dimitris Zacharopoulos]

On 14/11/2011 7:52 μμ, Kathleen Wilson wrote:
> On 11/14/11 9:15 AM, Stephen Schultze wrote:

>> On 11/14/11 5:04 AM, Dimitris Zacharopoulos wrote:

>>> On 11/11/2011 5:33 μμ, Dimitris Zacharopoulos wrote:
>>> Dear all,
>>>
>>> After thorough examination, HARICA has decided to constrain all CAs as
>>> proposed. In addition to the current technical restrictions
>>> mentioned in
>>> our previous e-mails, the "Name Constraints" extension will be used
>>> according to RFC 5280 and will be marked as critical.
>>>
>>> We propose HARICA ROOT CA to be limited to: .gr, .eu, .edu, .org. We
>>> believe these domains will cover 99% of HARICA needs.
>>> Each sub CA will be limited to each institution's domain.
>>>
>>> Especially for the ".org" domain, in case an institution requires a
>>> server certificate for a particular research project (no user
>>> certificates will be allowed for this subCA), they will request it from
>>> a single subCA, limited only to .org. This CA doesn't currently exist
>>> but will be created upon first request of such a certificate.
>>>
>>> If the above are satisfactory for the Mozilla CA inclusion program and
>>> there is no further comment or concern, we will proceed with the proper
>>> modifications to our CP/CPS.
>>>
>>> Thank you all for your comments and suggestions.
>>
>> This is very encouraging, and I am grateful for your responsiveness.
>>
>> I of course don't speak for Mozilla, but I expect that this will be
>> welcomed by them as well.
>>
>> Steve
>>
>
>

> I believe that this solution satisfies the concerns that have been
> raised during this discussion.
>

> If anyone else has comments/feedback on this certificate inclusion
> request, please speak up now.
>

> Thanks,
> Kathleen

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

Dear all,

Let me clarify that HARICA decided to voluntarily limit the subroots in
light of the rfc5280 extensions and their new implementations,
regardless of any "pressure". By limiting our CAs, we will also be a
"less attractive target" for potential groups that attack PKIs, thus
further minimizing relevant risks.


Best regards,
Dimitris Zacharopoulos.

[Eddy Nigg]

On 11/15/2011 02:29 PM, From Dimitris Zacharopoulos:

> Let me clarify that HARICA decided to voluntarily limit the subroots
> in light of the rfc5280 extensions and their new implementations,
> regardless of any "pressure". By limiting our CAs, we will also be a
> "less attractive target" for potential groups that attack PKIs, thus
> further minimizing relevant risks.

Exactly - this will reduce the attack surface. You guys really get it
and are serious - that's my impression I have from this thread here.

[Stephen Schultze]

On 11/15/11 6:25 AM, ianG wrote:
> I understand that HARICA had gone through this process and been accepted
> regardless of its narrower userbase of educational/research/academic focus.

HARICA has not yet been accepted, so this is not true.

In any case, the question was whether it offered a service to the
"typical Mozilla user" which is not specific to the type of work that
user does.

> HARICA then voluntarily decided to put in some limits on its subroots,
> after sustained pressure from the commercial CAs.

Not true for the same reasons. Also, I am not a commercial CA.

> I would like to get a public understanding on these points: HARICA is
> not required to constrain their subroots, and is not limited because of
> their educational/research/academic focus. There is no precedent
> established here on grounds raised here.

That has yet TBD. Certainly successful experience with limiting
subroots makes it a more viable requirement going forward.

> In the alternate, if the above points are not the case: can someone at
> Mozilla Foundation look up the IRS filing for 501(c)(3) or whatever and
> confirm to this group that Mozilla Foundation's tax status is not at
> risk due to discrimination in this case?

Ha! I've warned the Mozilla folks about this type of silly legal
hand-waving. I don't think they're worried. Feel free to lay out your
argument though... it would be fascinating to see.

[Dimitris Zacharopoulos]

On 14/11/2011 7:52 μμ, Kathleen Wilson wrote:
> On 11/14/11 9:15 AM, Stephen Schultze wrote:

>> On 11/14/11 5:04 AM, Dimitris Zacharopoulos wrote:

>>> On 11/11/2011 5:33 μμ, Dimitris Zacharopoulos wrote:
>>> Dear all,
>>>
>>> After thorough examination, HARICA has decided to constrain all CAs as
>>> proposed. In addition to the current technical restrictions
>>> mentioned in
>>> our previous e-mails, the "Name Constraints" extension will be used
>>> according to RFC 5280 and will be marked as critical.
>>>
>>> We propose HARICA ROOT CA to be limited to: .gr, .eu, .edu, .org. We
>>> believe these domains will cover 99% of HARICA needs.
>>> Each sub CA will be limited to each institution's domain.
>>>
>>> Especially for the ".org" domain, in case an institution requires a
>>> server certificate for a particular research project (no user
>>> certificates will be allowed for this subCA), they will request it from
>>> a single subCA, limited only to .org. This CA doesn't currently exist
>>> but will be created upon first request of such a certificate.
>>>
>>> If the above are satisfactory for the Mozilla CA inclusion program and
>>> there is no further comment or concern, we will proceed with the proper
>>> modifications to our CP/CPS.
>>>
>>> Thank you all for your comments and suggestions.
>>
>> This is very encouraging, and I am grateful for your responsiveness.
>>
>> I of course don't speak for Mozilla, but I expect that this will be
>> welcomed by them as well.
>>
>> Steve
>>
>
>

> I believe that this solution satisfies the concerns that have been
> raised during this discussion.
>
> If anyone else has comments/feedback on this certificate inclusion
> request, please speak up now.
>
> Thanks,
> Kathleen
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

Dear all,

HARICA has now implemented the name constraints extension as discussed
in this thread. The bug report has also been updated.

The next generation Root CA can be downloaded in the following versions:
http://www.harica.gr/certs/HaricaRootCA2011.pem
http://www.harica.gr/certs/HaricaRootCA2011.der
http://www.harica.gr/certs/HaricaRootCA2011.txt

Fingerprints:
SHA1 is 41:CB:5B:99:D6:EC:E6:8C:29:70:95:EB:5D:9C:89:EC:6C:80:93:32 and
MD5 is 14:99:76:B4:34:BC:58:D7:34:02:8F:B6:AD:2F:E6:5F.

The test certificate https://www2.harica.gr is also under the new hierarchy with the name constraints and is OCSP ready.

The updated CP/CPS is available at
https://www.harica.gr/documents/CPS-EN.pdf and the name constraints section is 7.1.5.


Thank you all for your valuable comments.

Best regards,
Dimitris Zacharopoulos.

[Eddy Nigg]

On 11/23/2011 09:29 PM, From Dimitris Zacharopoulos:

> The next generation Root CA can be downloaded in the following versions:
> http://www.harica.gr/certs/HaricaRootCA2011.pem

This looks excellent!

> Fingerprints:
> SHA1 is 41:CB:5B:99:D6:EC:E6:8C:29:70:95:EB:5D:9C:89:EC:6C:80:93:32 and
> MD5 is 14:99:76:B4:34:BC:58:D7:34:02:8F:B6:AD:2F:E6:5F.

Just for the record, is this the same public key and/or was the signing
ceremony witnessed by an auditor? Not critical at the moment, only
interesting to know.

[Dimitris Zacharopoulos]

On 23/11/2011 10:58 μμ, Eddy Nigg wrote:
> On 11/23/2011 09:29 PM, From Dimitris Zacharopoulos:

>> The next generation Root CA can be downloaded in the following versions:
>> http://www.harica.gr/certs/HaricaRootCA2011.pem
>

> This looks excellent!

>
>> Fingerprints:
>> SHA1 is 41:CB:5B:99:D6:EC:E6:8C:29:70:95:EB:5D:9C:89:EC:6C:80:93:32 and
>> MD5 is 14:99:76:B4:34:BC:58:D7:34:02:8F:B6:AD:2F:E6:5F.
>

> Just for the record, is this the same public key and/or was the
> signing ceremony witnessed by an auditor? Not critical at the moment,
> only interesting to know.
>

The new Root has a new public key. The signing ceremony was witnessed by
an authorized committee according to current practices.


Best regards,
Dimitris Zacharopoulos

[Erwann Abalea]

Sorry to be so late...

Le mercredi 23 novembre 2011 20:29:33 UTC+1, Dimitris Zacharopoulos a écrit :
> Dear all,
>
> HARICA has now implemented the name constraints extension as discussed
> in this thread. The bug report has also been updated.
>
> The next generation Root CA can be downloaded in the following versions:
> http://www.harica.gr/certs/HaricaRootCA2011.pem
> http://www.harica.gr/certs/HaricaRootCA2011.der
> http://www.harica.gr/certs/HaricaRootCA2011.txt

This won't work.

Follow the algorithm given in chapter 10.5 of X.509 recommendation, the validation starts with the certificate signed by the trust anchor (your root).
The trust anchor itself is not checked, and the content of the nameConstraints extension won't be taken into consideration (10.5.2).
Same goes for other extensions (certificatePolicies, basicConstraints, etc).

In fact, you can't place any *constraint* in a self-signed certificate.

Erwann.

[Erwann Abalea]

Sorry to be so late...

Le mercredi 23 novembre 2011 20:29:33 UTC+1, Dimitris Zacharopoulos a écrit :

> Dear all,
>
> HARICA has now implemented the name constraints extension as discussed
> in this thread. The bug report has also been updated.
>
> The next generation Root CA can be downloaded in the following versions:
> http://www.harica.gr/certs/HaricaRootCA2011.pem
> http://www.harica.gr/certs/HaricaRootCA2011.der
> http://www.harica.gr/certs/HaricaRootCA2011.txt

[Dimitris Zacharopoulos]

On 25/11/2011 4:18 μμ, Erwann Abalea wrote:
> Sorry to be so late...
>
> Le mercredi 23 novembre 2011 20:29:33 UTC+1, Dimitris Zacharopoulos a écrit :

>> Dear all,
>>
>> HARICA has now implemented the name constraints extension as discussed
>> in this thread. The bug report has also been updated.
>>
>> The next generation Root CA can be downloaded in the following versions:
>> http://www.harica.gr/certs/HaricaRootCA2011.pem
>> http://www.harica.gr/certs/HaricaRootCA2011.der
>> http://www.harica.gr/certs/HaricaRootCA2011.txt

> This won't work.
>
> Follow the algorithm given in chapter 10.5 of X.509 recommendation, the validation starts with the certificate signed by the trust anchor (your root).
> The trust anchor itself is not checked, and the content of the nameConstraints extension won't be taken into consideration (10.5.2).
> Same goes for other extensions (certificatePolicies, basicConstraints, etc).
>
> In fact, you can't place any *constraint* in a self-signed certificate.
>
> Erwann.

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

Dear Erwann,

The current implementations of the algorithm indeed do not check name
constraints in the self-signed root certificate. However,
HARICA considers to have fulfilled the name constraints requirement because:

a) the CP/CPS explicitly states that the "name constraints" extension must be
present in all CA certificates (including subCAs)
b) all end user/server certificates are produced by subordinate CAs
where the algorithm implementations do not ignore the name constraints extension. This
has been tested and verified by HARICA extensively. If you visit
https://www2.harica.gr you can see the first issued SubCA
(HaricaAdministrationCAR3), which has the nameConstraints extension
with the permittedSubtrees component containing the value "harica.gr".
We believe that this should satisfy all concerns.

The fact that HARICARootCA2011 includes a name constraints extension is not part of
the problematic practices listed at
https://wiki.mozilla.org/CA:Problematic_Practices.

Fotis Loukos from our technical team looked into the algorithm and current implementations
a little deeper and came up with the following recommendations:

1) Including the nameConstraints extension at a trust anchor
could be useful in the future. According to subclause 10.5 of the X.509
recommendation, if an intermediate certificate is processed and
contains the nameConstraints extension with a permittedSubtrees
component, the permitted-subtrees state variable is set to the
intersection of the previous value and the value of the certificate
extension. This variable, i.e. permitted-subtrees, is defined at
subclause 10.3 and it is a set of subtree specifications for the valid
subject names in subsequent certificates. At the initialization step,
its value is set to the initial-permitted-subtrees-set value (subclause
10.4), which in turn is one of the inputs to the algorithm (subclause
10.1). The value of this input variable is chosen by the
implementor. A special value, unbounded, allows any possible subtree. We
believe that, as a future improvement, the name constraints from the
trust anchor could be selected because even though the trust anchor
is not checked by the algorithm, it would be used to initialize it.

2) Currently, in the NSS 3.12.11 source code, in function
pkix_NameConstraintsChecker_Initialize@security/nss/lib/libpkix/pkix/checker/pkix_nameconstraintschecker.c
which is the implementation of the algorithm in clause 10 for checking
the name constraints, the "initial-permitted-subtrees-set" is passed as
the first argument. After checking the function
pkix_InitializeCheckers@security/nss/lib/libpkix/pkix/top/pkix_validate.c where
all checkers are initialized, the name constraints input is different
for every trust anchor, and it is loaded using
PKIX_TrustAnchor_GetNameConstraints@security/nss/lib/libpkix/pkix/params/pkix_trustanchor.c.
However, at
PKIX_TrustAnchor_CreateWithCert@security/nss/lib/libpkix/pkix/params/pkix_trustanchor.c
this value is always set to NULL, which corresponds to the unbounded special value
of the X.509 recommendation. Since there is support for different
initial-permitted-subtrees-set values for every trust anchor, it might
be more secure to set them into something specific for each
certificate, such as the nameConstraints extension value. We would also
like to note that the function responsible for creating a trust anchor
using an X.500 name and a Public Key pair, i.e.
PKIX_TrustAnchor_CreateWithNameKeyPair@security/nss/lib/libpkix/pkix/params/pkix_trustanchor.c,
already supports nameConstraints.

Please let us know if there are any further comments or concerns.

[Eddy Nigg]

On 11/28/2011 11:49 AM, From Dimitris Zacharopoulos:

> The current implementations of the algorithm indeed do not check name
> constraints in the self-signed root certificate. However, HARICA
> considers to have fulfilled the name constraints requirement because:

I think it's also important to consider that a CA root can be signed
again by other parties - for example a well-known software vendor
actually looks at the constraints of the CA root, assuming they
cross-sign it internally. Not that it's much relevant at the moment
here, but NSS will simply ignore the constraints of your root (but not
the intermediate CAs).

[Peter Gutmann]

Eddy Nigg <eddy...@startcom.org> writes:
>I think it's also important to consider that a CA root can be signed again by
>other parties - for example a well-known software vendor actually looks at
>the constraints of the CA root, assuming they cross-sign it internally. Not
>that it's much relevant at the moment here, but NSS will simply ignore the
>constraints of your root (but not the intermediate CAs).

Interesting point, and another argument against the totally stupid "ignore
these extensions in root certs" requirement, the semantics of a cert will
change completely if it's cross-signed or reparented, and verification
behaviour is nondeterministic depending on how far up the chain you go.

Peter.

[Brian Smith]

Dimitris Zacharopoulos wrote:
> We propose HARICA ROOT CA to be limited to: .gr, .eu, .edu, .org.

HARICA should be commended for working with us to get this far. Dimitris, as you are discovering, we have never actually tried to use name constraints before and are just now discovering how poorly they would work for what we intend them to do. Some of those things may be fixable, but it isn't clear how such constraints help with the decision to include or not include a particular CA.

To me, it doesn't make sense to say that this organization's security infrastructure and trustworthiness are good enough for it to issue certificates for *.org, including *.mozilla.org, but not *.com. That isn't to say that such the name constraints are a bad idea. But, name constraints like this are still overly-broad. Something like *.edu.gr would be more appropriate as far as scope is concerned, but even that very narrow constraint doesn't match the scope of this organization, AFAICT. And, I think it wouldn't suit HARICA's needs.

This root seems to not not meet Microsoft's minimum requirements for acceptance into their root program, because HARICA does not offer certificates to the public. So, this root would be in our program but not Microsoft's and probably not Apple's, AFAICT. That doesn't seem like a tenable situation for these websites. I think they are going to need another solution, and that other solution is likely to work for us to, even if we don't include HARICA in our root program.

Cheers,
Brian

[Eddy Nigg]

On 11/28/2011 07:28 PM, From Brian Smith:

> This root seems to not not meet Microsoft's minimum requirements for
> acceptance into their root program,

Membership with any other software vendor was never a criteria for
acceptance or rejection at Mozilla. You have to make your case without
that.

> because HARICA does not offer certificates to the public.

I believe this was the first observation from myself. But it might that
there is still an interest to the common user of Mozilla software as the
Mozilla CA Policy mandates. Or we might have to rephrase that policy
requirement that CAs must issue certificates to the general pubic. Would
be fine with me.

[Brian Smith]

Eddy Nigg wrote:
> On 11/28/2011 07:28 PM, From Brian Smith:
> > This root seems to not not meet Microsoft's minimum requirements for
> > acceptance into their root program,
>
> Membership with any other software vendor was never a criteria for
> acceptance or rejection at Mozilla. You have to make your case without
> that.

My point is that, even if we include them, these certs won't work in Internet Explorer, in Chrome (except on Linux), on the iPhone, or on the iPad, at least--and that will be true indefinitely. So, websites that would use certificates issued by HARICA would need to find a different solution--most likely, buying certificates from a commercial CA or having HARICA's CA certificate chain to an already-trusted root. But, if they do either of those things, then the sites will work fine in Mozilla products too, without adding HARICA as a trusted root.

I understand that this is somewhat similar to the situation your company was in, and that Mozilla added StartCom before Microsoft did. However, I think that your company at least had a clear path to getting added to Microsoft's program eventually. That isn't the case for HARICA, as far as I can tell.

- Brian

[Eddy Nigg]

On 11/29/2011 12:40 AM, From Brian Smith:

> My point is that, even if we include them, these certs won't work in
> Internet Explorer, in Chrome (except on Linux), on the iPhone, or on
> the iPad, at least--and that will be true indefinitely. So, websites
> that would use certificates issued by HARICA would need to find a
> different solution--most likely, buying certificates from a commercial
> CA or having HARICA's CA certificate chain to an already-trusted root.
> But, if they do either of those things, then the sites will work fine
> in Mozilla products too, without adding HARICA as a trusted root. I
> understand that this is somewhat similar to the situation your company
> was in, and that Mozilla added StartCom before Microsoft did. However,
> I think that your company at least had a clear path to getting added
> to Microsoft's program eventually. That isn't the case for HARICA, as
> far as I can tell. - Brian

All true - and really the order which software vendor starts to support
a CA root at which point isn't really relevant. I simply think we should
be careful making such an equation or consider membership elsewhere
(existing or non-existing, either way) problematic. Your other points
might be correct and probably HARICA should consider cross-signing with
a supported root.

[David E. Ross]

On 11/28/11 1:57 PM, Eddy Nigg wrote:
> On 11/28/2011 07:28 PM, From Brian Smith:
>> This root seems to not not meet Microsoft's minimum requirements for
>> acceptance into their root program,
>
> Membership with any other software vendor was never a criteria for
> acceptance or rejection at Mozilla. You have to make your case without
> that.
>
>> because HARICA does not offer certificates to the public.
>
> I believe this was the first observation from myself. But it might that
> there is still an interest to the common user of Mozilla software as the
> Mozilla CA Policy mandates. Or we might have to rephrase that policy
> requirement that CAs must issue certificates to the general pubic. Would
> be fine with me.
>

No. I think it should be the CA must issue certificates on which the
general public will rely.

An example would be a banking trade group acting as a CA and issuing Web
site certificates only to banks. The general public would rely on those
certificates for online banking. However, the trade group would not
issue site certificates to the general public. I think the root
certificate from such a CA would indeed be appropriate for inclusion by
Mozilla.

--

David E. Ross
<http://www.rossde.com/>.

Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
© 1997 by David E. Ross

[Brian Smith]

David E. Ross wrote:
> On 11/28/11 1:57 PM, Eddy Nigg wrote:
> > I believe this was the first observation from myself. But it might
> > that there is still an interest to the common user of Mozilla
> > software as the Mozilla CA Policy mandates. Or we might have to
> > rephrase that policy requirement that CAs must issue certificates
> > to the general pubic. Would be fine with me.
> >
>
> No. I think it should be the CA must issue certificates on which the
> general public will rely.
>
> An example would be a banking trade group acting as a CA and issuing
> Web site certificates only to banks. The general public would rely on
> those certificates for online banking. However, the trade group would
> not issue site certificates to the general public. I think the root
> certificate from such a CA would indeed be appropriate for inclusion
> by Mozilla.

Another example would be Brian Smith CA, which would only issue SSL certificates name constrained to *.briansmith.org, and would only issue them to the Brian Smith that owns and operates Brian Smith CA, authenticated via an headache-inducing amount of state-issued paperwork, photo IDs, and biometrics.

A more realistic example is Google Internet Authority, which issues certificates only to Google, Inc. for Google-owned properties (this is actually a real thing today, BTW). That will be followed by Facebook Internet Authority, Nike Internet Authority, 4chan Internet Authority, etc.

I be this set of CAs would get unwieldy fast. Perhaps we could outsource the authentication of these specialized CAs to some kind of "super CAs," and ask websites to include a complete cert chain that ends at one of these super CAs in the server part of the TLS handshake, so that we wouldn't have to include all of these un-super CAs' certificates in our root certificate database. In order to maximize the utility (to Mozilla) per super CA, we could require that these super CAs have a policy of issuing certificates to the public so that we don't accumulate so many super CAs as to cause us to need a new level of super-super-CAs to manage them.

With such a system, Brian Smith could get a *.briansmith.org certificate from one of the super CAs, and Google could get its Google Internet Authority CA certificate chained to one of the super CAs' certificates, etc.

Cheers,
Brian

[Dimitris Zacharopoulos]

On 29/11/2011 1:51 πμ, David E. Ross wrote:
> On 11/28/11 1:57 PM, Eddy Nigg wrote:

>> On 11/28/2011 07:28 PM, From Brian Smith:
>>> This root seems to not not meet Microsoft's minimum requirements for
>>> acceptance into their root program,
>> Membership with any other software vendor was never a criteria for
>> acceptance or rejection at Mozilla. You have to make your case without
>> that.
>>
>>> because HARICA does not offer certificates to the public.
>> I believe this was the first observation from myself. But it might that
>> there is still an interest to the common user of Mozilla software as the
>> Mozilla CA Policy mandates. Or we might have to rephrase that policy
>> requirement that CAs must issue certificates to the general pubic. Would
>> be fine with me.
>>

> No. I think it should be the CA must issue certificates on which the
> general public will rely.
>
> An example would be a banking trade group acting as a CA and issuing Web
> site certificates only to banks. The general public would rely on those
> certificates for online banking. However, the trade group would not
> issue site certificates to the general public. I think the root
> certificate from such a CA would indeed be appropriate for inclusion by
> Mozilla.
>

Dear all,

We understand that the public benefit from HARICA's inclusion had
already been discussed. HARICA complies with current Mozilla policies
and the consensus was to move forward with the name constraints
proposal, which we implemented. Please check out the discussion thread
between Oct 26 and Nov 2nd. This also includes the concerns about the
scope of our constituency.

HARICA has not applied for inclusion in Microsoft's nor Apple's program
yet. We decided to begin with Mozilla because we consider Firefox to be
the most popular browser for the user base. Applications to Microsoft
and Apple are already being prepared and will follow soon (Q1 2012). Our
preliminary check of requirements for the CA inclusion programs of
Microsoft and Apple, showed that HARICA meets all criteria for
inclusion, but this discussion will most probably take place with
Microsoft and Apple representatives.

[Gervase Markham]

On 28/11/11 22:40, Brian Smith wrote:
> I understand that this is somewhat similar to the situation your
> company was in, and that Mozilla added StartCom before Microsoft did.
> However, I think that your company at least had a clear path to
> getting added to Microsoft's program eventually. That isn't the case
> for HARICA, as far as I can tell.

I think that whether or not HARICA gets added to Microsoft and/or
Apple's root programmes is a problem for HARICA, not for us. Our root
program requirements are our own, they are not the superset of ours,
Microsoft's and Apple's.

Anyway, If HARICA want to be in Firefox only, and recommend Firefox to
all of their client institutions, I'm not objecting!

Gerv

[Peter Gutmann]

Brian Smith <bsm...@mozilla.com> writes:

>Dimitris, as you are discovering, we have never actually tried to use name
>constraints before and are just now discovering how poorly they would work
>for what we intend them to do. Some of those things may be fixable, but it
>isn't clear how such constraints help with the decision to include or not
>include a particular CA.

Name constraints, invented in a vaccuum by X.509 theorists, have never really
worked, for any general definition of "worked". The problem is that even if
implementations did actually pay attention to the namespace constraints and
managed to get the arcane rules for name handling correct (there's some
wonderful surprises hidden in the specs when you start trying to implement
them), their use would lead to enormous certificates since the real world
doesn't use the strictly hierarchical X.500 namespace that the X.509 designers
envisaged (you can get around this by using unworkably generic constraint
spaces like .com or .org, but that's barely better than not using constraints
at all).

In practice the namespace in which certificates are used is both large and
dynamic as new brands are created, new marketing campaigns take place, and so
on (as a Verizon Business product manager once commented in a discussion on
this topic, "taking a snapshot of a customer's brand reality is valid for
about a month"). Conversely, setups that are small enough for namespace
constraints to be practical are just going to go with a single CA that doesn't
require the use of any additional constraints for all of their certificates,
it's just "whatever this CA issued".

So in practice name constraints where the namespace is small enough to be
practical aren't needed, and where it's large enough to be needed they don't
work. Apart from that, they're fine.

Put another way, if you guys are running into problems with them then it's not
your fault, the problem is that X.509's name constraints just don't work in
practice.

Peter.

[Kathleen Wilson]

Brian and Peter,

Are you saying that HARICA may run into problems by using name
constraints?

Or are you just saying that Mozilla products may not yet fully enforce
name constraints? e.g. so if HARICA does use name constraints, then
there may not be benefit until Mozilla products are updated to more
fully enforce them.

Thanks,
Kathleen

[Erwann Abalea]

Bonsoir Dimitris,

Le lundi 28 novembre 2011 10:49:17 UTC+1, Dimitris Zacharopoulos a écrit :
> On 25/11/2011 4:18 μμ, Erwann Abalea wrote:
> > Sorry to be so late...
> >
> > Le mercredi 23 novembre 2011 20:29:33 UTC+1, Dimitris Zacharopoulos a écrit :
> >> Dear all,
> >>
> >> HARICA has now implemented the name constraints extension as discussed
> >> in this thread. The bug report has also been updated.
> >>
> >> The next generation Root CA can be downloaded in the following versions:
> >> http://www.harica.gr/certs/HaricaRootCA2011.pem
> >> http://www.harica.gr/certs/HaricaRootCA2011.der
> >> http://www.harica.gr/certs/HaricaRootCA2011.txt
> > This won't work.
> >
> > Follow the algorithm given in chapter 10.5 of X.509 recommendation, the validation starts with the certificate signed by the trust anchor (your root).
> > The trust anchor itself is not checked, and the content of the nameConstraints extension won't be taken into consideration (10.5.2).
> > Same goes for other extensions (certificatePolicies, basicConstraints, etc).
> >
> > In fact, you can't place any *constraint* in a self-signed certificate.
>

> Dear Erwann,
>
> The current implementations of the algorithm indeed do not check name
> constraints in the self-signed root certificate. However,
> HARICA considers to have fulfilled the name constraints requirement because:

My fault again, I haven't been clear enough.

It's not the "current implementations of the algorithm" who don't check name constraints, but the algorithm itself, as specified in X.509.
You've fulfilled the name constraints requirement, but this requirement was misplaced at first. Placing name constraints in sub-CA is correct, as you did on the "HaricaAdministrationCAR3" sub-CA. This constraint gets the job done.

> Fotis Loukos from our technical team looked into the algorithm and current implementations
> a little deeper and came up with the following recommendations:
>
> 1) Including the nameConstraints extension at a trust anchor
> could be useful in the future. According to subclause 10.5 of the X.509
> recommendation, if an intermediate certificate is processed and
> contains the nameConstraints extension with a permittedSubtrees
> component, the permitted-subtrees state variable is set to the
> intersection of the previous value and the value of the certificate
> extension. This variable, i.e. permitted-subtrees, is defined at
> subclause 10.3 and it is a set of subtree specifications for the valid
> subject names in subsequent certificates. At the initialization step,
> its value is set to the initial-permitted-subtrees-set value (subclause
> 10.4), which in turn is one of the inputs to the algorithm (subclause
> 10.1). The value of this input variable is chosen by the
> implementor. A special value, unbounded, allows any possible subtree. We
> believe that, as a future improvement, the name constraints from the
> trust anchor could be selected because even though the trust anchor
> is not checked by the algorithm, it would be used to initialize it.

The relying party is free to set the initial value for initial-permitted-subtrees-set to whatever suits its need, but the algorithm doesn't take into account trust anchors, and this part of the algorithm hasn't changed since 1997. I doubt it will in the future. So, placing name constraints on a trust anchor is useless. This shouldn't have any bad effect, only no effect at all.

The same logic is applied to certificatePolicies extension. A relying party can define its own list of accepted policyID, and the algorithm won't take into account the certificatePolicies extension set in the trust anchor.

> 2) Currently, in the NSS 3.12.11 source code, in function
> pkix_NameConstraintsChecker_Initialize@security/nss/lib/libpkix/pkix/checker/pkix_nameconstraintschecker.c
> which is the implementation of the algorithm in clause 10 for checking
> the name constraints, the "initial-permitted-subtrees-set" is passed as
> the first argument. After checking the function
> pkix_InitializeCheckers@security/nss/lib/libpkix/pkix/top/pkix_validate.c where

> all checkers are itialized, the name constraints input is different

> for every trust anchor, and it is loaded using
> PKIX_TrustAnchor_GetNameConstraints@security/nss/lib/libpkix/pkix/params/pkix_trustanchor.c.
> However, at
> PKIX_TrustAnchor_CreateWithCert@security/nss/lib/libpkix/pkix/params/pkix_trustanchor.c
> this value is always set to NULL, which corresponds to the unbounded special value
> of the X.509 recommendation. Since there is support for different
> initial-permitted-subtrees-set values for every trust anchor, it might
> be more secure to set them into something specific for each
> certificate, such as the nameConstraints extension value.

You're right, it can. But it doesn't need to. It could also be a value carried aside from the trust anchor, just as the trust bits.

My point was finally to say that a recertification wasn't necessary, as:
- initial value for permitted-subtrees-set is application dependant, just like the policyID for EV and the trust bits; reading the name constraints of the trust anchor and using them for this initial value requires some significant change
- the previous root could have been used to produce sub-CA with nameConstraints, which were perfectly valid

(I take responsibility of any misunderstanding, considering that I'm too busy to have some serious sleep.)

--
Erwann.

[Peter Gutmann]

Kathleen Wilson <kathle...@yahoo.com> writes:

>Are you saying that HARICA may run into problems by using name constraints?

Yes. It's certainly a nice gesture by the HARICA folks, like not playing loud
music after 11pm or putting your rubbish out on the street a week before the
collection is due, but it both won't have much practical effect because
implementation support ranges from nonexistent all the way through to hit-and-
miss, and will probably cause interop problems with implementations that get
it wrong. And that's only the implementation issues, the real problem is that
X.509 name constraints are broken as designed, they were designed for the
global X.500 directory, not the real world, and work by X.500 subtree
refinement and constrainment. The ability to use DNS names was kludged on
afterwards, but as I pointed out in my previous message it was at best a token
admission by the X.500 folks that the DNS namespace existed and not any real
attempt at providing useful functionality. How, for example, would you use
name constraints to avoid another Comodogate/Diginotargate/Whoeversnextgate?

So if you add the constraints and clear the critical bit you may be OK
(provided you don't run into any implementations that take it too seriously),
as long as you realise that it's just a social gesture and not anything with
any real practical impact.

Peter.

[Dimitris Zacharopoulos]

On 29/11/2011 10:33 μμ, Erwann Abalea wrote:
> The relying party is free to set the initial value for initial-permitted-subtrees-set to whatever suits its need, but the algorithm doesn't take into account trust anchors, and this part of the algorithm hasn't changed since 1997. I doubt it will in the future. So, placing name constraints on a trust anchor is useless. This shouldn't have any bad effect, only no effect at all.

Dear Erwann,

Even though this discussion seems more appropriate to take place at the
PKIX wg, the question would be why would it be useless and why not take
into account trust anchors. I am sure there will be arguments to support
both cases.

>
> The same logic is applied to certificatePolicies extension. A relying party can define its own list of accepted policyID, and the algorithm won't take into account the certificatePolicies extension set in the trust anchor.
>

>> > 2) Currently, in the NSS 3.12.11 source code, in function
>> > pkix_NameConstraintsChecker_Initialize@security/nss/lib/libpkix/pkix/checker/pkix_nameconstraintschecker.c
>> > which is the implementation of the algorithm in clause 10 for checking
>> > the name constraints, the "initial-permitted-subtrees-set" is passed as
>> > the first argument. After checking the function
>> > pkix_InitializeCheckers@security/nss/lib/libpkix/pkix/top/pkix_validate.c where

>> > all checkers are itialized, the name constraints input is different

>> > for every trust anchor, and it is loaded using
>> > PKIX_TrustAnchor_GetNameConstraints@security/nss/lib/libpkix/pkix/params/pkix_trustanchor.c.
>> > However, at
>> > PKIX_TrustAnchor_CreateWithCert@security/nss/lib/libpkix/pkix/params/pkix_trustanchor.c
>> > this value is always set to NULL, which corresponds to the unbounded special value
>> > of the X.509 recommendation. Since there is support for different
>> > initial-permitted-subtrees-set values for every trust anchor, it might
>> > be more secure to set them into something specific for each
>> > certificate, such as the nameConstraints extension value.

> You're right, it can. But it doesn't need to. It could also be a value carried aside from the trust anchor, just as the trust bits.

Exactly. Enabling trust bits is outside the X509 algorithm.
It is Mozilla's implementation that handles these trust bits. These
implementations could be modified to enable name constraints for
trust anchors as well. It is all part of the initialization
sequence of the certificate validation procedure.

Thank you very much for this in-depth analysis.

Best regards,
Dimitris Zacharopoulos.

--

Zacharopoulos Dimitris
Aristotle University of Thessaloniki

Network Operations Center
NOC-AUTH, Thessaloniki, Macedonia, Greece
Tel. N.O.C.: +30-2310998483
Fax. N.O.C.: +30-2310998492
E-Mail : ji...@ccf.auth.gr

Web : http://noc.auth.gr

[Dimitris Zacharopoulos]

On 30/11/2011 6:10 πμ, Peter Gutmann wrote:
> So if you add the constraints and clear the critical bit you may be OK
> (provided you don't run into any implementations that take it too seriously),
> as long as you realise that it's just a social gesture and not anything with
> any real practical impact.

Dear Peter and all,

The name constraints extension has been tested by HARICA and works as
expected with Mozilla Firefox, IE and openssl. IE and Firefox browsers
cover the largest percentage of the user base which minimizes the risk
to near zero. If there are other implementations that either ignore or
don't know how to handle these extensions, it is their implementors job
to make sure that their products comply with the corresponding RFC.

The name constraints are not a "social gesture" but something with a
practical impact for HARICA and relying parties. By using them, we
practically block any malware certificates outside the legitimate list
of domains. This will avoid any comodo/diginotar/ gate. Of course, if
some users use Netscape Communicator or some very old browsers where the
name constraints are not implemented, they will be affected,
theoretically. As far as HARICA is concerned, there are several security
controls already in place at the RA and CA level (as we
have already mentioned) that do not allow issuance of certificates for
domains outside a specific "white list". By adding the name constraints
extension in our CAs, we added what seems to be a very strong measure
which will protect the vast majority of Internet users and minimize the
risk to nearly zero, making HARICA not an "attractive" target.

Thank you all for your valuable input to this discussion making it so
interesting.

Best regards,
Dimitris Zacharopoulos.

--

HARICA Public Key Infrastructure
http://www.harica.gr

Zacharopoulos Dimitris

AUTH Central Communication Facilities, Network Operations Center

[Peter Gutmann]

Dimitris Zacharopoulos <ji...@ccf.auth.gr> writes:

>The name constraints extension has been tested by HARICA and works as
>expected with Mozilla Firefox, IE and openssl.

Uhh, how does that match Brian Smith's earlier comment that:

we have never actually tried to use name constraints before and are just now
discovering how poorly they would work for what we intend them to do.

When I looked at it (which admittedly was a while back) implementations either
ignored them or, when they didn't, it was pretty trivial to bypass them using
the same tricks that are used to get around URL filters (URL filters have had
years of evolutionary pressure applied to them while name constraints have had
none, not helped by the fact that the name-constraint-enforcement code is
often totally different to the URL-processing code, so that they have two
completely different views of the text string that they're seeing. Finding an
implementation that would, for example, execute Javascript that was in the
middle of a URL was quite a surprise. Well OK, not so much a surprise that
you could do that but certainly amusing).

The point I was really trying to make is that you shouldn't rely on them for
security. It doesn't hurt to set them in case things work out OK, but I
wouldn't rely on them exclusively for security.

Peter.

[Dimitris Zacharopoulos]

On 30/11/2011 2:59 μμ, Peter Gutmann wrote:
> Dimitris Zacharopoulos <ji...@ccf.auth.gr> writes:
>
>> The name constraints extension has been tested by HARICA and works as
>> expected with Mozilla Firefox, IE and openssl.
> Uhh, how does that match Brian Smith's earlier comment that:
>
> we have never actually tried to use name constraints before and are just now
> discovering how poorly they would work for what we intend them to do.

Brian said that "they have never actually tried to use name constraints
before". We can only verify what we (HARICA) have tested here in our
labs. Our tests included the following:

1) We created a rootCA with nameConstraints marked as critical with
permittedSubTrees having the value ".gr"
2) We created a subCA with nameConstraints permitted only to "harica.gr"
3) We issued a server certificate to testsite.harica.biz
4) We issued a server certificate to www2.harica.gr

When we loaded the "testsite.harica.biz" certificate in our web server,
both IE and Firefox denied access due to name constraints violation.

When we loaded the "www2.harica.gr" certificate, everything worked with
no errors. This was tested with Firefox and IE browsers.

It is our intension to limit the end certificates to the domain of the
corresponding institution subCA which is also applied with other
security measures as we already mentioned.

>
> When I looked at it (which admittedly was a while back) implementations either
> ignored them or, when they didn't, it was pretty trivial to bypass them using
> the same tricks that are used to get around URL filters (URL filters have had
> years of evolutionary pressure applied to them while name constraints have had
> none, not helped by the fact that the name-constraint-enforcement code is
> often totally different to the URL-processing code, so that they have two
> completely different views of the text string that they're seeing. Finding an
> implementation that would, for example, execute Javascript that was in the
> middle of a URL was quite a surprise. Well OK, not so much a surprise that
> you could do that but certainly amusing).

Your observation is pointing to the URL field and not the actual SSL
connection handshake. A client using SSL connects to a specific hostname
and receives the corresponding certificate along with the certificate
chain. This operation takes place at a lower layer. For example, instead
of HTTP over SSL you can use SMTP over SSL.

>
> The point I was really trying to make is that you shouldn't rely on them for
> security. It doesn't hurt to set them in case things work out OK, but I
> wouldn't rely on them exclusively for security.

HARICA does not depend on name constraints exclusively for security. We
consider the name constraints an extra layer of protection. Some relying
parties may consider this extra layer to be a very strong one.

Best regards,
Dimitris.


>
> Peter.

[Eddy Nigg]

On 11/30/2011 04:15 PM, From Dimitris Zacharopoulos:

> When we loaded the "testsite.harica.biz" certificate in our web
> server, both IE and Firefox denied access due to name constraints
> violation.

Other CAs have already made similar comments in the past and confirmed
it working. Not sure who it was though...

> HARICA does not depend on name constraints exclusively for security.
> We consider the name constraints an extra layer of protection. Some
> relying parties may consider this extra layer to be a very strong one.

Yes indeed, I completely agree with that.

[Peter Gutmann]

Dimitris Zacharopoulos <ji...@ccf.auth.gr> writes:

>1) We created a rootCA with nameConstraints marked as critical with
>permittedSubTrees having the value ".gr"
>2) We created a subCA with nameConstraints permitted only to "harica.gr"
>3) We issued a server certificate to testsite.harica.biz
>4) We issued a server certificate to www2.harica.gr
>

>When we loaded the "testsite.harica.biz" certificate in our web server, both
>IE and Firefox denied access due to name constraints violation.
>

>When we loaded the "www2.harica.gr" certificate, everything worked with no
>errors. This was tested with Firefox and IE browsers.

And it worked? Wow, they've finally got round to implementing this.

Having said that, that's only an existence proof :-). Did you try any evasive
maneouvres like putting one name in the CN and another in the altName, putting
a permitted name in the first altName entry and a non- permitted one in the
second, using "harica.gr .biz" (note the space), using testsite.harica%2Ebiz,
...? (I can't remember all the things I looked at, I'd read a paper on
disguised URLs at the time and decided to see what would happen with some of
them, that's when I found out that the implementation I was testing probably
used strcmp() for the name constraints but a full-blown URL parser to actually
process the URLs for use, so you could get all manner of stuff past it because
the two layers had a completely different view of what a URL string
represented. Unfortunately I never really thought about the implications of
strcmp() vs. memcmp() so Moxie got the '\0' trick first :-).

Oh, also, what happens when you don't have the name constraint in the subCA
but only in the root?

Peter.

[Peter Gutmann]

Brian Smith <bsm...@mozilla.com> writes:

>Perhaps we could outsource the authentication of these specialized CAs to
>some kind of "super CAs," and ask websites to include a complete cert chain
>that ends at one of these super CAs in the server part of the TLS handshake,

That was the exact suggestion I made a few months ago (on another list):

It has been suggested that we need a kind of meta-CA or CA for CAs (CACA).
Then the browser vendors could code CACA into the browsers, and we'd all be
trusting in CACA.

Or maybe we already are.

Peter.

[Dimitris Zacharopoulos]

Hi Peter and all,

It seems that the "critical" bit of the name constraints extension has
some side-effects on safari. It doesn't recognize the extension and
follows rfc5280 strictly.

rfc5280:

A
certificate-using system MUST reject the certificate if it encounters
a critical extension it does not recognize or a critical extension
that contains information that it cannot process. A non-critical
extension MAY be ignored if it is not recognized, but MUST be
processed if it is recognized.


IE and FF still work as expected (tested with alternate subject names as
well). We have tested the name constraints extension marked as "no
critical" and IE and FF still work as expected meaning that they
prohibit the usage of dns names outside the permitted list. _This also
works for safari_, but does not apply the name constraints extension,
even though it is recognized as an extension in the certificate details!

As long as the NSS users are extra protected by using the name
constraints extension, we believe it would be best for HARICA to change
the "critical" bit of the name constraints extension to "non critical".

We realize that this is not a firefox problem and it is something that
should be fixed by Apple, but it would be very helpful if we didn't have
to deal with this issue with every software vendor.

For those of you that want to test the configuration:

* You may download the testRoot at
http://www.harica.gr/certs/HaricaRootCA2011Test2.der
* Check out https://www3.harica.gr. This is with a subCA that allows
"harica.gr" domains. It should work ok with all browsers (including
safari)
* Check out https://www4.harica.gr. This is with a subCA that allows
only "harica.gov" domains. It should be blocked by firefox and IE
(attached screenshots)


Thank you in advance.

Dimitris Zacharopoulos.

[Dimitris Zacharopoulos]

The two attachments didn't make it to the list. Here are the URLs:

http://harica.gr/documents/FF-name-constraint-violation-non-critical.jpg
http://harica.gr/documents/IE-name-constraint-violation-non-critical.jpg

Best regards,
Dimitris.

[William Madell]

> * You may download the testRoot at
> http://www.harica.gr/certs/HaricaRootCA2011Test2.der
> * Check out https://www3.harica.gr. This is with a subCA that allows
> "harica.gr" domains. It should work ok with all browsers (including
> safari)
> * Check out https://www4.harica.gr. This is with a subCA that allows
> only "harica.gov" domains. It should be blocked by firefox and IE
> (attached screenshots)

Chrome is picking it up as well and reporting a cert error against
https://www4.harica.gr - nice work, Dimitris!

Cheers,
Bill

[Eddy Nigg]

On 12/01/2011 07:46 PM, From William Madell:

> Chrome is picking it up as well and reporting a cert error against
> https://www4.harica.gr - nice work, Dimitris!

+1

[Jean-Marc Desperrier]

On 01/12/2011 15:16, Dimitris Zacharopoulos wrote:
> It seems that the "critical" bit of the name constraints extension has
> some side-effects on safari. It doesn't recognize the extension and

> follows rfc5280 strictly [and rejects the certificate].

That's just what critical means. In some cases, if you don't understand
an extension and just ignore it, even the legit data emitted by the CA
can be abused to make you believe a certificate is valid in a scenario
where it isn't. That's when critical is really required.

> As long as the NSS users are extra protected by using the name
> constraints extension, we believe it would be best for HARICA to change
> the "critical" bit of the name constraints extension to "non critical".

Indeed. As the text you quoted says, any browser that *does* understand
the extension *must* apply it even if not marked as critical.

[Dimitris Zacharopoulos]

Dear all,

HARICA has implemented the name constraints extension as discussed in
this thread and removed the "critical" bit. The bug report has also been
updated. The updated Root CA can be downloaded in the following versions:
http://www.harica.gr/certs/HaricaRootCA2011.pem
http://www.harica.gr/certs/HaricaRootCA2011.der
Fingerprints: SHA1 is
41:CB:5B:99:D6:EC:E6:8C:29:70:95:EB:5D:9C:89:EC:6C:80:93:32 and MD5 is
14:99:76:B4:34:BC:58:D7:34:02:8F:B6:AD:2F:E6:5F.

The test certificate https://www2.harica.gr is also under the new
hierarchy with the name constraints and is OCSP ready.

The updated CP/CPS (version 2.5) is available at
https://www.harica.gr/documents/CPS-EN.pdf and the name constraints
section is 7.1.5.

Thank you all, once again, for your valuable comments.

Best regards,

[Dimitris Zacharopoulos]

On 7/12/2011 6:23 μμ, Dimitris Zacharopoulos wrote:
> Dear all,
>
> HARICA has implemented the name constraints extension as discussed in
> this thread and removed the "critical" bit. The bug report has also been
> updated. The updated Root CA can be downloaded in the following versions:
> http://www.harica.gr/certs/HaricaRootCA2011.pem
> http://www.harica.gr/certs/HaricaRootCA2011.der
> Fingerprints: SHA1 is
> 41:CB:5B:99:D6:EC:E6:8C:29:70:95:EB:5D:9C:89:EC:6C:80:93:32 and MD5 is
> 14:99:76:B4:34:BC:58:D7:34:02:8F:B6:AD:2F:E6:5F.
>
> The test certificate https://www2.harica.gr is also under the new
> hierarchy with the name constraints and is OCSP ready.
>
> The updated CP/CPS (version 2.5) is available at
> https://www.harica.gr/documents/CPS-EN.pdf and the name constraints
> section is 7.1.5.
>
> Thank you all, once again, for your valuable comments.
>
> Best regards,
> Dimitris Zacharopoulos.
>

Copy-paste mistake. The correct Fingerprints are:
SHA1 is fe:45:65:9b:79:03:5b:98:a1:61:b5:51:2e:ac:da:58:09:48:22:4d and
MD5 is 73:9f:4c:4b:73:5b:79:e9:fa:ba:1c:ef:6e:cb:d5:c9.

The bug report has the correct fingerprints.

[Kathleen Wilson]

I have reviewed the updated CPS, tested browsing to the website (with
OCSP enforced) and checked that the SSL cert is properly chaining to the
new root, and imported the CRLs into my Firefox browser without error.

CPS section 7.1.5, Name constraints:
"HARICA constrains all of its CAs according to RFC 5280. This extension
is marked as “non-critical”.
HARICA ROOT CA is limited to the following domains: .gr, .eu, .edu, .org.
Especially for the “.org” domain, in case an institution requires a
server certificate for a particular educational or research activity (no
user certificates will be allowed for this subCA), they will request it
from a single subCA, limited only to “.org”. This CA doesn't currently
exist, but will be created upon first request of such a certificate.
Each subCA MUST be constrained to the Institution’s domain name that the
subCA signs for. For example, Aristotle University of Thessaloniki subCA
will be limited to the “auth.gr” domain, using the name constraints
extension."

I have update the Information Gathering Document to reflect this new
root, and attached it to the bug. I will also update the pending page.

New Info Gathering Document:
https://bugzilla.mozilla.org/attachment.cgi?id=579752

If there are no further comments regarding this root inclusion request,
then I propose that I close this discussion and recommend approval in
the bug.

Kathleen

[Kathleen Wilson]

On 10/25/11 1:51 PM, Kathleen Wilson wrote:
> HARICA has applied to add the “Hellenic Academic and Research
> Institutions RootCA 2011” root certificate, and enable all three trust
> bits.
>
> The main goal of HARICA (Hellenic Academic and Research Institutions
> Certification Authority / Greek Universities Network) is the deployment
> of an infrastructure for secure communication between the collaborating
> members of the Greek Academic and Research Institutions. All HARICA
> certificates have a clear mark indicating that the certificate is
> subject to Greek laws and their CPS.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=581901
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#HARICA
>
> Noteworthy points:
>
> * The primary document is the CPS, which is provided in English.
>
> Document Repository: http://www.harica.gr/procedures.php
> CPS: http://www.harica.gr/documents/CPS-EN.pdf
>


Thank you to all of you who have reviewed this request and added your
comments and feedback to this discussion. Your contributions are greatly
appreciated.

This discussion was in regards to the request from HARICA to add the
“Hellenic Academic and Research Institutions RootCA 2011” root
certificate and turn on all three trust bits.

During the course of this discussion HARICA generated a new root
certificate and updated their CPS to require the use of name constraints
in the sub CAs.

I will post a summary of the request and my recommendation for approval
in the bug:

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

I am now closing this discussion. Any further follow-up on this request
should be added directly to the bug.

Thanks,
Kathleen

[Jean-Marc Desperrier]

Dimitris Zacharopoulos a écrit :

> On 29/11/2011 10:33 μμ, Erwann Abalea wrote:
>>> The relying party is free to set the initial value for
>>> initial-permitted-subtrees-set to whatever suits its need, but the
>>> algorithm doesn't take into account trust anchors, and this part of the
>>> algorithm hasn't changed since 1997. I doubt it will in the future. So,
>>> placing name constraints on a trust anchor is useless. This shouldn't
>>> have any bad effect, only no effect at all.
>

> Even though this discussion seems more appropriate to take place at the
> PKIX wg, the question would be why would it be useless and why not take
> into account trust anchors. I am sure there will be arguments to support
> both cases.

The discussion already happened on the PKIX wg, several times.

The result was almost exactly what Erwann describe, except with the
precision that implementers are perfectly free to use the data in a X509
root anchor to complement the initials value.
So it does have an effect on quite a few implementations.

IIRC Denis Pinkas took in recent times the position in that it would be
a good thing to change the standard to say that the validity period of
the root should be taken into account. Most implementations do that
already (or else we wouldn't need to renew root certificates when they
expire).

But the standard define a trust anchor as nothing more than a public
key, and there's indeed a number a situation where it won't be a
self-signed X509.