Swiss BIT Root Inclusion Request
Kathleen Wilson
enable the email trust bit for the �Admin-Root-CA� root, and to enable
all three trust bits for the �AdminCA-CD-T01� root.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=435026
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Swiss%20BIT
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=422392
Noteworthy points:
* Swiss Bundesamt f�r Informatik und Telekommunikation (BIT) is also
known as the Federal Office of Information Technology and
Telecommunication (FOITT). The FOITT is responsible for networking the
Swiss cantons and the Principality of Liechtenstein.
* The �Admin-Root-CA� root has three internally-operated intermediate
CAs, with two currently in operation. The intermediate CAs issue
certificates for hardware tokens to be used for identification, digital
signatures, encryption, and authentication of individuals. The hardware
tokens are issued to employees of an administrative unit (federal,
cantonal or municipal administration) who already have their information
published in Swiss BIT's Admin-Directory.
* The �AdminCA-CD-T01� root does not have intermediate CAs; it issues
end-entity certificates directly. The purpose of AdminCA-CD-T01 is to
issue user/organization certificates and device/server certificates of
classes C/C-TrustCenter and D. A certificate of class C/C-Trustcenter is
issued for natural persons and organizations and can be used for signing
purposes, encryption, and authentication. Class D certificates are only
for authentication. These certificates may be applied for by members of
an administrative unit (federal, cantonal or municipal administration)
that have concluded a framework agreement and SLA with Swiss BIT, such
that their information is already in Swiss BIT�s Admin-Directory.
* The CPS documents have been translated into English.
** AdminPKI-ClassA CPS (email, digital signature; applies to both roots):
https://bugzilla.mozilla.org/attachment.cgi?id=374130
**AdminCA-CD-T01 CPS (SSL, code signing):
https://bugzilla.mozilla.org/attachment.cgi?id=376403
* The request is to enable the email trust bit for the �Admin-Root-CA�
root, and to enable all three trust bits for the �AdminCA-CD-T01� root.
* AdminPKI-ClassA CPS Section 3.2.3: The tasks of identifying the
certificate applicants and gathering all the information required for
issuing a certificate is delegated to the Local Registration Authority.
The Local Registration Authority must:
** verify the content of the certificate application form
** verify that the applicant is registered in the Admin-Directory
** ensure that the applicant�s name in the directory is the same as that
on the ID presented
** scan the identification documents presented.
* The procedures for verifying that the subscriber has ownership/control
of the email address to be included in the certificate is the same for
both Admin-Root-CA and AdminCA-CD-T01.Sections 4.1.1 and 4.3.2 of both
CPS documents listed above provide the details.
** Summary: The Federal Administration maintains a meta-directory called
the Admin-Directory. Employees of an administrative unit (federal,
cantonal or municipal administration) are registered in the
Admin-Directory. Anyone whose personal data are published in the
Admin-Directory may complete the certificate application form. The
Registration Authority compares the information in the certificate
application with the data in the Admin-Directory, including the
subscriber�s last and first names, distinctive hash code, and e-mail
address. The consent of the administrative unit employing the subscriber
is required for publishing the certificate in the public version of the
Admin-Directory. The applicant is notified by e-mail of the issuance of
the certificate. The e-mail address in the certificate is used for this
purpose.
* The procedures for verifying that the subscriber owns/controls the
domain name to be included in the certificate are described in the
AdminCA-CD-T01 CPS, an internal security officer process document, and a
manual for an internal certificate issuance application.
** There is a web-based registration application for issuing SSL
certificates that can only be accessed by authorized persons as defined
in section 4.1.2 of the AdminCA-CD-T01 CPS. Only authorized persons can
issue/revoke certificates in this registration application. These
authorized persons are specially selected by the chief of their
departments/organizations (AdminPKI issues certificates only for the
federal government and canton departments in Switzerland). They are
trained and have to pass security audits. They are only authorized to
issue Certificates for their Department/Organization and they are aware
of the consequences of misuse.
** As per AdminCA-CD-T01 CPS section 4.1.2, To avoid misuse, the
security officer has to observe the system once per week for wrong or
illegally issued certificates.
*** In Detail, the security officers receive reports. In these reports
is declared, which authorized person has issued each specific domain,
including organization/department name, address, Issuing Date, and so
on... The security officer now checks these reports for suspicious
elements (if domain is not a subdomain of admin.ch, it is suspicious
because AdminPKI only issues Certificate for federal government and
cantonal departments). If such elements were found, he checks if domain
and authorized person matches with different WHOIS queries. If not, he
has to revoke the certificate and send a notice to the specific chief of
department, respective his office. With all the other elements, which
are not suspicious, the security officer makes random checks with the
same methods as described before. This whole process is described in
the internal security officer process.
*** In the current Release of the Provisioning Platform, the AdminPKI
handles these security issues reactive. In further release, it will be
most likely proactive.
* The Code Signing procedures are documented on the request forms for
CodeSigning Certificates. Basically the person who requests a Code
Signing Certificate must also be a authorized person according to
AdminCA-CD-T01 CPS section 4.1.2, but the issuing is different: After
the personal identification of this person, the AdminPKI itself is
issuing the requested CodeSigning Certificate and delivers it personally
to the requester.
* Test Website: https://www.aramis.admin.ch/
* CRL:
** Admin-Root-CA ARL: http://www.pki.admin.ch/crl/Admin-Root-CA.crl
** AdminCA-CD-T01 CRL: http://www.pki.admin.ch/crl/AdminCA-CD-T01.crl
(NextUpdate: 8 days)
* OCSP: Not provided.
* Audit: Swiss BIT is audited annually by KPMG according to the ETSI 101
456 criteria. The 2009 audit statement was attached to the bug
(https://bug435026.bugzilla.mozilla.org/attachment.cgi?id=385981) and I
confirmed the authenticity of the document by independently contacting KPMG.
This begins a one-week discussion period. After that week, 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
Kathleen Wilson
> enable the email trust bit for the �Admin-Root-CA� root, and to
> enable all three trust bits for the �AdminCA-CD-T01� root.
Reminder: I have started the discussion for Swiss BIT's root inclusion
request. I would greatly appreciate it if at least two people would
review and comment on this request.
Kathleen
Eddy Nigg
> > Swiss BIT has applied to add two root certificates. The request is to
> > enable all three trust bits for the “AdminCA-CD-T01” root.
>
> Reminder: I have started the discussion for Swiss BIT's root inclusion
> request. I would greatly appreciate it if at least two people would
> review and comment on this request.
>
Sorry Kathleen, but I believe that we need another week or so for this
one. Incidentally this is another one apparently closely affiliated or
run by government ;-)
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Kathleen Wilson
> I believe that we need another week or so for this one.
Understood. Also, I will re-iterate that I will greatly appreciate it
if at least two people review and comment on this request.
> Incidentally this is another one apparently closely affiliated or
> run by government
Yes, we have included many root certificates that are operated by CAs
who either are run by their government, are closely affiliated with
their government, and/or must be approved by their government to issue
certain types of certificates after having proven that they follow their
government's practices/policies.
Kathleen
Eddy Nigg
> Swiss BIT has applied to add two root certificates. The request is to
> all three trust bits for the “AdminCA-CD-T01” root.
Kathleen, I'm sorry for not having had much time to invest into this
request.
>
> * Swiss Bundesamt für Informatik und Telekommunikation (BIT) is also
> known as the Federal Office of Information Technology and
> Telecommunication (FOITT). The FOITT is responsible for networking the
> Swiss cantons and the Principality of Liechtenstein.
I doubt how the inclusion of these roots are any relevant for a typical
user of Mozilla software. Even though Mozilla has accepted and will
accept CA focused on particular countries and audience they intend to
serve, this request smacks much more of a private, very limited CA with
limited scope and use beyond their own.
I think there must be some more value for the typical user base or
perhaps there must be some more convincing reasons in order to consider
to include these roots.
I've read this now a few times, including in the attachment 422392. I'm
not convinced that this comes even close to the requirements as set
forth by the Mozilla CA Policy section 7 . The verification of domain
names and email addresses is not meant to be voluntary nor sampled nor
retroactively confirmed. Instead, a requirement to reasonable verify the
relevant attributes is conditioned.
The steps outlined above could be useful in addition to other
verification mechanisms as part of a self-audit procedure, but under no
circumstances instead thereof. This doesn't comply to the policy.
> ** Admin-Root-CA ARL: http://www.pki.admin.ch/crl/Admin-Root-CA.crl
Apparently one root issues end-user certificates directly from the root
- are there any pressing reasons for this?
> ** AdminCA-CD-T01 CRL: http://www.pki.admin.ch/crl/AdminCA-CD-T01.crl
> (NextUpdate: 8 days)
This appears to be a bit long and should be probably reduced to a more
frequent cycle.
> * OCSP: Not provided.
This effectively means that at the moment these roots have no revocation
mechanism that works without manual intervention by the user. This
probably affects any relying party negatively. Swiss BIT shall note that
revocation of a certificate will be not recognized by Mozilla products.
Michal
>
> I've read this now a few times, including in the attachment 422392. I'm
> not convinced that this comes even close to the requirements as set
> forth by the Mozilla CA Policy section 7 . The verification of domain
> names and email addresses is not meant to be voluntary nor sampled nor
> retroactively confirmed. Instead, a requirement to reasonable verify the
> relevant attributes is conditioned.
>
> The steps outlined above could be useful in addition to other
> verification mechanisms as part of a self-audit procedure, but under no
> circumstances instead thereof. This doesn't comply to the policy.
>
Apparently there are limited number of subjects that may even apply to
issue certificate so I assume that internal procedures describes how
any certificate request have to be validated.
> > ** Admin-Root-CA ARL:http://www.pki.admin.ch/crl/Admin-Root-CA.crl
>
> Apparently one root issues end-user certificates directly from the root
> - are there any pressing reasons for this?
>
What is more interesting, the diagram at http://www.bit.admin.ch/adminpki/00247/index.html
suggest that there are two intermediate certificates under Admin-Root-
CA (Admin-CA3 and AdminCA-CD-T01)
Other things related to Admin-Root-CA:
4.10.2 Service availability "after hours" is pretty poor (80%).
7.1 CPS - reference to RFC3280 - obsoleted by RFC5280
Eddy Nigg
Apparently there are limited number of subjects that may even apply to issue certificate so I assume that internal procedures describes how any certificate request have to be validated.
The security officer now checks these reports for suspicious elements (if domain is not a subdomain of admin.ch, it is suspicious because AdminPKI only issues Certificate for federal government and cantonal departments).
I suggest that they get a couple of certs from another CA (there are even already trusted CAs based and operating in Switzerland) and get on with it. At the most they could engage for an intermediate CA - they already absolved an audit, therefore I suspect that they would be ready to go.
As in the previous response, I recommend not to consider this root for inclusion, except in case the scope and scale has been grossly misunderstood.
Michal
>
> As in the previous response, I recommend not to consider this root for
> inclusion, except in case the scope and scale has been grossly
> misunderstood.
>
I've reviewed all the information once again, and I have to agree with
Eddy. It looks like adding this roots to NSS store may have limited
relevance to Mozilla's users.
Michal
chemalogo
> On 02/09/2010 04:50 PM, Michal:
>
> > Apparently there are limited number of subjects that may even apply to
> > issue certificate so I assume that internal procedures describes how
> > any certificate request have to be validated.
>
> Not really, consider this:
>
> elements (if domain is not a subdomain of admin.ch, it is suspicious
> because AdminPKI only issues Certificate for federal government and
> cantonal departments).
>
> But this begs really the question what this has lost here. I mean, if
> all they are securing one domain and everything else is considered
> suspicious, then this root has no relevance for Mozilla's users.
>
> I suggest that they get a couple of certs from another CA (there are
> even already trusted CAs based and operating in Switzerland) and get on
> with it. At the most they could engage for an intermediate CA - they
> already absolved an audit, therefore I suspect that they would be ready
> to go.
>
> As in the previous response, I recommend not to consider this root for
> inclusion, except in case the scope and scale has been grossly
> misunderstood.
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd.
On one hand I agree with Eddy Nigg on the point regarding end entity
issuance directly from a Root CA. It does have not only secutiry
concerns but also practical ones, limitanting the growth of this
hierarchy and exposing the CA.
I also agree that perhaps this is a very small group of people to
consider the inclusion of certificates in the distribution of Mozilla,
which reaches around the world, and contributes to increase the number
of certificates distribute.
On the other hand, I have worked with a regional goverment agency
(#295474), which involves also a small group of people (compared with
the whole world I mean) and the difficulties that the non-inclusion of
the CAR root certificates can create to end users and, overall,
relying parties.
To sum up. In order to spread and ease the use of certificates and
electronic signature arround the world I recommend to include this
certificate, but I would ask for details regarding the issuance of End
Entity Certificates from a Root CA and also ask for any evidence of
the security audits of personnel ("These authorized persons are
specially selected by the chief of their departments/organizations
(AdminPKI issues certificates only for the federal government and
canton departments in Switzerland). They are trained and have to pass
security audits. ")
Philipp Langenegger
>
> - Zitierten Text anzeigen -
We’ve read your comments and think there are basically two things
which might be misunderstood:
1.Process of issuing SSL-Certs:
As we already pointed out, only trained personnel is authorized to
issue certificates. These people belong to the government and are
audited. The issuance of a SSL-certificate is not possible without
strong authentication (by means of a smartcard “class B” that is
issued with a personal face-to-face registration on behalf of the
passport). That means, that there exists a strong audit trail, so that
wrong usage can and will lead to serious legal consequences for the
respective employee.
2.Relevance of our request:
At the moment , there are 4 officially accredited Certificate Service
Provider (CSP) in Switzerland (see: http://www.seco.admin.ch/sas/00229/00251/index.html?lang=de).
Swiss BIT is the CSP with the largest amount of Certificates in use.
At the moment SwissBIT has over 55’000 valid Certificates, most of
the Certificates are used for personal Authentication (e.g. police
officer that need strong authentication) but we have also a growing
amount of Server Certificates. However, there are many end users which
operate with OpenSource like Mozilla. Our goal with this request is to
provide Certificates not only to closed Source (SwissBIT is included
in Microsoft and Apple Root CA Store), but also to OpenSource.
Admin.ch is the same for Switzerland like usa.gov for the USA. And
even if the SwissBIT CA issues certificates only for National
Governement and Swiss Cantons, the enduser are often normal swiss or
european people, which use amongst others firefox.
So we think there is a relevance for Mozilla users, even if
Switzerland is a small country
Let us add a comment to OCSP: So far is has not been a request of our
customers. However, we will build and provide the OCSP-Service this
year.
Philipp Langenegger
>
> - Zitierten Text anzeigen -
English Version of Website in Point 2:
Kathleen Wilson
Swiss BIT and contributed to this discussion.
Here is a summary of the items that have been pointed out in this
discussion.
1) Relevancy of root to Mozilla users
The concern has been raised that there might not be enough relevancy of
this particular service to typical Mozilla users.
The CA responded that Swiss BIT is one of the 4 officially accredited
CSPs in Switzerland, and of these four is the CSP with the largest
amount of certificates in use. Even if the SwissBIT CA issues
certificates only for National Government and Swiss Cantons, the end
users are often normal Swiss or European people who use the Firefox browser.
My opinion is that typical Firefox users living in Switzerland and
Europe probably believe that this service is relevant to them.
Therefore, I am of the opinion that this service is relevant.
ACTION: None
2) Verification of Domain Name as per section 7 of the Mozilla CA Policy
Concern was raised that domain name verification happens as part of an
audit after the certificate has been issued.
The CA responded: …only trained personnel is authorized to issue
certificates. These people belong to the government and are audited. The
issuance of a SSL-certificate is not possible without strong
authentication (by means of a smartcard “class B” that is issued with a
personal face-to-face registration on behalf of the passport). That
means, that there exists a strong audit trail, so that wrong usage can
and will lead to serious legal consequences for the respective employee.
Precedence has been set with other CAs that the procedures for verifying
that the certificate subscriber owns/controls the domain name included
in the certificate must be done before the certificate may be issued.
ACTION Swiss BIT: Update Swiss BIT’s practice to verify that the
certificate subscriber owns/controls the domain name to be included in
the certificate before the certificate may be approved for issuance.
Update the CPS documents to describe the new procedures. Obtain an audit
that meets the requirements of the Mozilla CA Policy that confirms that
the new procedures are in place as documented.
ACTION Swiss BIT: Update the bug to provide links to the new
documentation and audit.
ACTION Kathleen: Verify the new documentation and audit, and start a
second round of public discussion.
3) Verification of Email Address as per section 7 of the Mozilla CA Policy
Concern was raised that email address verification procedures do not
meet the requirements of section 7 of the Mozilla CA Policy.
As is documented in the CPS documents: The Federal Administration
maintains a meta-directory called the Admin-Directory. Employees of an
administrative unit (federal, cantonal or municipal administration) are
registered in the Admin-Directory. Anyone whose personal data are
published in the Admin-Directory may complete the certificate
application form. The Registration Authority compares the information in
the certificate application with the data in the Admin-Directory,
including the subscriber’s last and first names, distinctive hash code,
and e-mail address. The consent of the administrative unit employing the
subscriber is required for publishing the certificate in the public
version of the Admin-Directory. The applicant is notified by e-mail of
the issuance of the certificate. The e-mail address in the certificate
is used for this purpose.
My understanding is that the act of an employee being added to the
Admin-Directory ensures the accuracy of the data therein, including the
email address that is included in the Admin-Directory. However, I do not
see clear documentation that the email address to be included in the
certificate is confirmed to be the same as the email address in the
Admin-Directory. The statement that the certificate is sent via the
email address that is included in the certificate is not enough – the
check should be performed before the certificate is created.
ACTION Swiss BIT: Update Swiss BIT’s CPS documentation to further
clarify the verification procedures for confirming that the certificate
subscriber owns/controls the email address to be included in the
certificate.
ACTION Swiss BIT: Update the bug to provide links to the new documentation.
ACTION Kathleen: Verify the new documentation, and start a second round
of public discussion when all Swiss BIT action items have been completed.
4) Root directly signing end-entity certificates
The “AdminCA-CD-T01” root does not have intermediate CAs; it issues
end-entity device/server certificates directly.
As noted in the potentially problematic practices wiki page, we think
that issuing end-entity certificates directly from a root is not a good
practice, and that a better practice would be to issue end-entity
certificates from a subordinate CA that can act as the issuing CA.
However there is nothing in our current CA policy that prohibits issuing
end-entity certificates directly from a root.
RECOMMENDATION for Swiss BIT: Reconsider having an intermediate CA for
signing end-entity certificates.
ACTION: None. This item alone, would not prevent approval for inclusion.
5) NextUpdate for CRL for end-entity certificates
A concern was raised that the NextUpdate of 8 days seems long, and
should be reduced to a more frequent cycle.
EV Guidelines: “CRLs MUST be updated and reissued at least every seven
days, and the nextUpdate field value SHALL NOT be more than ten days
after the current update”
Even though this request does not include enablement of EV, the
NextUpdate of 8 days is within the boundaries of the EV guidelines.
ACTION: None
6) OCSP not provided
It is strongly recommended that CAs provide an OCSP service for their
end-entity certificates.
Swiss BIT has stated that they plan to implement an OCSP service this year.
ACTION: None
7) Other
Two other points were raised in regards to Admin-Root-CA: 1) Service
availability "after hours" is pretty poor (80%). 2) CPS - reference to
RFC3280 - obsoleted by RFC5280
Swiss BIT is encouraged to update their CPS.
ACTION: None
Please review my summary to ensure accuracy and completeness.
If this summary correctly represents the results of this discussion,
then I will close this discussion and post the action items in the bug.
Thanks,
Kathleen
Eddy Nigg
>
> My opinion is that typical Firefox users living in Switzerland and
> Europe probably believe that this service is relevant to them.
> Therefore, I am of the opinion that this service is relevant.
>
Just want to make you aware that a root similar to this one comes very
close to any private CA or enterprise scenario. This isn't a public CA.
This CA doesn't sell or provide PKI services to the Swiss population as
subscribers, lest to Europe or world-wide.
By including this root I believe you are opening the door to something
you probably don't want. What will you say, if IBM tomorrow wants its
root included and they probably issued a lot more certificates than this
CA every will. Can you deny it based on such a precedent?
I believe that this is wrong approach for application software like
Mozilla. Instead I believe Swiss BIT should do what a private or
enterprise CA would likely do (like what IBM, Microsoft and Google do)
and get their root sub or cross signed by another CA (Swiss Sign?).
Since Swiss BIT has an audit, I believe this would be perfectly in order.
The important factor here is PUBLIC CA - Swiss BIT is with all due
respect a PRIVATE CA. For your consideration :-)
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
David E. Ross
> On 02/11/2010 09:26 PM, Kathleen Wilson:
>>
>> My opinion is that typical Firefox users living in Switzerland and
>> Europe probably believe that this service is relevant to them.
>> Therefore, I am of the opinion that this service is relevant.
>>
>
> Just want to make you aware that a root similar to this one comes very
> close to any private CA or enterprise scenario. This isn't a public CA.
> This CA doesn't sell or provide PKI services to the Swiss population as
> subscribers, lest to Europe or world-wide.
>
> By including this root I believe you are opening the door to something
> you probably don't want. What will you say, if IBM tomorrow wants its
> root included and they probably issued a lot more certificates than this
> CA every will. Can you deny it based on such a precedent?
>
> I believe that this is wrong approach for application software like
> Mozilla. Instead I believe Swiss BIT should do what a private or
> enterprise CA would likely do (like what IBM, Microsoft and Google do)
> and get their root sub or cross signed by another CA (Swiss Sign?).
> Since Swiss BIT has an audit, I believe this would be perfectly in order.
>
> The important factor here is PUBLIC CA - Swiss BIT is with all due
> respect a PRIVATE CA. For your consideration :-)
>
I'm not sure Swiss BIT is indeed private. While the certificates it
signs have a distribution limited to government agencies, it appears
that those certificates are relied upon by the general public in
Switzerland for accessing government Web sites and authenticating
messages from government officials.
In this case, Swiss BIT serves the same function in Switzerland that
commercial certificate authorities serve in the U.S. For example,
VeriSign signed the intermediate certificate that signed the site
certificate for the Centers for Medicare & Medicaid Services (a U.S.
government agency), which then allows me to have secure access to my
Medicare claims history on the Web.
To me, a private certificate authority would be signing certificates for
internal use only within an organization (e.g., for an intranet).
--
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
Eddy Nigg
> In this case, Swiss BIT serves the same function in Switzerland that
> commercial certificate authorities serve in the U.S. For example,
> VeriSign signed the intermediate certificate that signed the site
> government agency), which then allows me to have secure access to my
> Medicare claims history on the Web.
>
Right, and so could Swiss Sign sign that of Swiss BIT - exactly the same
case here. Swiss BIT is not Verisign, but Medicare. Swiss Sign is the
Verisign of Switzerland if you will...
> To me, a private certificate authority would be signing certificates for
> internal use only within an organization (e.g., for an intranet).
>
Google has a private (intermediate) CA, it's private because you can't
buy certificates from Google. Relying parties don't have to be internal
only (which would be mostly an enterprise scenario), but as in the case
of Google and many, many others, Swiss BIT is not a public CA.
I believe that this opens a Pandora box which once opened will be very
hard to close again. I understand the desire that Mozilla wants to have
users use Firefox for these sites - and they should, but I believe the
solution should be a different one.
Swiss BIT apparently is going to secure one sub domain of one particular
domain. Everything else is suspicious according to their words. Nobody
besides the cantons of Switzerland can get server certificates - this
seems to me an extremely limited scope. Sorry for not buying into this...
Eddy Nigg
> Swiss BIT apparently is going to secure one sub domain of one
> particular domain.
Sorry, that should have been "sub domains of one particular domain" and
not one sub domain.
Gervase Markham
> The CA responded that Swiss BIT is one of the 4 officially accredited
> CSPs in Switzerland, and of these four is the CSP with the largest
> amount of certificates in use. Even if the SwissBIT CA issues
> certificates only for National Government and Swiss Cantons, the end
> users are often normal Swiss or European people who use the Firefox
> browser.
In the past, this has not been a sufficient argument. For example, Cisco
might want us to include the CA they use to sign the certificates for
the SSL interface on all their routers, on the basis that the end users
of the routers are ordinary Firefox users. But we have declined, I
believe on the basis that the CA services themselves need to be
available to the general public, or a large subset of it.
Gerv
Kathleen Wilson
public or a large subset of it. I had been under the impression that
this root was relied on by people in Switzerland and Europe to use
government websites, and thus acted as a national government CA.
However, now it appears that may not have been completely accurate.
I think the relevancy of the root inclusion to Mozilla users needs to be
determined before closing this discussion. Perhaps Swiss BIT can provide
more information about the type of Mozilla users who would benefit from
the inclusion of their root.
I am going to leave this discussion open for a while longer, but in the
meantime I'm going to start the next discussion in the queue.
Kathleen
Eddy Nigg
> It is not yet clear if Swiss BIT's PKI service benefits the general
> public or a large subset of it. I had been under the impression that
> this root was relied on by people in Switzerland and Europe to use
> government websites, and thus acted as a national government CA.
> However, now it appears that may not have been completely accurate.
>
> the meantime I'm going to start the next discussion in the queue.
I believe that government/national sponsored or operated CAs have some
value when the CA issues certificates to its citizens which may be used
with one or more products of Mozilla. For example some of those CAs
issue client certificates which may be used for S/MIME (provided a
validated email address is included). Some of those CAs operate also
additional intermediate CA certificates from which they issue server
certificates to the public. That's typical for the CAs issuing so-called
qualified certificates in the EU.
Even though we found that some of those CAs are fairly limited in scope,
they do provide some value because they issue certificates to their
citizens and others, which may be used with Mozilla applications.
However here we have a clear case where the CA is not issuing
certificates to the public, the subscribers are all internally
affiliated (as being cantons of the Swiss Federation) and therefore can
not be considered a public CA - rather a CA with a very limited scope to
secure a very limited set of web sites and some client certificates
consumed within their structure.
Additionally Switzerland is not a member of the EU and I believe that
the use of the admin.ch web sites is fairly limited beyond the area of
Switzerland. And even for the use within the boundaries of Switzerland,
securing one domain is certainly not a reason for a CA root inclusion.
As I mentioned previously, there are better ways to achieve support with
Mozilla software and this inclusion request is in my opinion not reasonable.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Philipp Langenegger
to mozilla users:
SwissBIT Certificates are not only used to support government-to-
government applications. In fact most of the class CD Certificates are
used by government-to-citizen applications and some government-to-
business applications. Swiss BIT is hosting most of G2C -applications
of Switzerland. The respecting Servers where the applications are
running, use SwissBIT -certificates. Today, the customers need to
accept the Admin CD-T01 Root CA manually (or use a different
browser).
Here are three examples:
- Termdat is large database-application which provides Terminology for
journalists and the media.
- AGIS provides agro-political Information’s to farmers
- SENTINELLA is used by doctors and medical research as a detection-
system for recovery of epidemiological data and other medicinal issues
On the other hand, server-certificates are used for public websites
which are accessed by citizen, business customers and other
governments.
Here are some examples:
- https://www.news-service.admin.ch/NSBSubscriber/login?lang=de - News-
Portal of Swiss Government
- https://www.sonderbewilligungen.admin.ch/ - Application for Special
Dispensations
- https://www.aramis.admin.ch - Information System regarding
research, development and evaluation of Swiss Fed Administration
There would be much more examples for both cases, but this would go
beyond the scope. There is one other to point out/summaries: Only
authorized government or canton user can issue certificates, not only
for federal employees but also for citizen.
We hope that this information will help to put all your concerns about
the relevance of this request out of the way.
Jean-Marc Desperrier
> My opinion is that typical Firefox users living in Switzerland and
> Europe probably believe that this service is relevant to them.
> Therefore, I am of the opinion that this service is relevant.
Would be nice to be able to ask that to at least a few of them instead
of only guessing.
I am more and more of the opinion this is an important point that's
missing in the current reviewing policy.
Eddy Nigg
- https://www.news-service.admin.ch/NSBSubscriber/login?lang=de - News- Portal of Swiss Government - https://www.sonderbewilligungen.admin.ch/ - Application for Special Dispensations - https://www.aramis.admin.ch - Information System regarding research, development and evaluation of Swiss Fed Administration
There is one other to point out/summaries: Only authorized government or canton user can issue certificates, not only for federal employees but also for citizen.
-- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP: star...@startcom.org
Philipp Langenegger
https://www.ichschweiz.ch/Default.asp?lang=en
https://www.eofcom.ch/welcome.do
https://www.national-registry.ch/?LANGUE=en
https://www.veva-online.ch/veva/start.cmd
> This is not what was explained previously. Where can I get a certificate
> from Swiss BIT, I'd like to enroll for one.
Also this, probably not stated clear enough: Only Class D user
certificates, can be applied to citizen or business customer if they
have a reasonable statement. Per example: A Farmer needs access to the
application AGIS (posted before), so he can contact the specified
Authority and obtain a certificate.
I doubt the relevance of the question about relevance in this request,
because first there is no statement in the policy which tells about
relevance and how relevance is measured and secondly there are other
government CA’s (Taiwan, Nederland,..) which are already included. Not
to mention that SwissBIT IS providing services which are used by the
general public.
Eddy Nigg
> Ok, my fault, here some examples with different domains:
>
Thank you Phillip for the additional information.
> https://www.ichschweiz.ch/Default.asp?lang=en
>
CN = www.ichschweiz.ch
OU = Server
OU = Services
O = admin
C = CH
> https://www.eofcom.ch/welcome.do
>
Issued by Verisign.
> https://www.national-registry.ch/?LANGUE=en
>
CN = www.national-registry.ch
OU = Server
OU = Services
O = admin
C = CH
> https://www.veva-online.ch/veva/start.cmd
>
>
CN = www.veva-online.ch
OU = Server
OU = Services
O = admin
C = CH
May I ask what those values in the subject lines are? Can you please
explain how this is consistent with the verification requirements as
stated in the opening thread of Kathleen's initial post "Swiss BIT Root
Inclusion Request" ?
> Also this, probably not stated clear enough: Only Class D user
> certificates, can be applied to citizen or business customer if they
> have a reasonable statement. Per example: A Farmer needs access to the
> application AGIS (posted before), so he can contact the specified
> Authority and obtain a certificate.
>
Unfortunately I'm not a farmer, so I guess I can't get a certificate :-)
> I doubt the relevance of the question about relevance in this request,
> because first there is no statement in the policy which tells about
> relevance and how relevance is measured and secondly there are other
> government CA’s (Taiwan, Nederland,..) which are already included.
>
Every CA has different policies and the above mentioned CAs underwent
the same process here. They operate vastly different than your CA
according to my memory.
Philipp Langenegger
> >https://www.veva-online.ch/veva/start.cmd
>
> CN =www.veva-online.ch
> OU = Server
> OU = Services
> O = admin
> C = CH
>
> May I ask what those values in the subject lines are? Can you please
> explain how this is consistent with the verification requirements as
> stated in the opening thread of Kathleen's initial post "Swiss BIT Root
> Inclusion Request" ?
These values points to the location in the AdminDir (X500 Directory)
where the certificates are stored. You have to know the SwissBIT is
also providing a hosting platform. The posted websites are all hosted
by SwissBIT (webservers are owned by BIT, but not applications who are
running on them), because they are related in some way to the Federal
Administration. That is the reason why it points always to the same
subject lines.
Eddy Nigg
> These values points to the location in the AdminDir (X500 Directory)
> where the certificates are stored. You have to know the SwissBIT is
> also providing a hosting platform. The posted websites are all hosted
> by SwissBIT (webservers are owned by BIT, but not applications who are
> running on them), because they are related in some way to the Federal
> Administration. That is the reason why it points always to the same
> subject lines.
>
I understand, I thought you were using LDAP for that. But I also
understood that the details of the subscribers were validated, it
obviously doesn't appear in the certificate, so it has no real value.
Together with the domain validation requirement, perhaps there is some
room for improvement in any case? It would be much better if the
certificates would actually state the verified details - not that this
is a requirement of the Mozilla CA Policy, just common sense. :-)
Kathleen Wilson
> Swiss BIT has applied to add two root certificates. The request is to
> all three trust bits for the �AdminCA-CD-T01� root.
I recently noticed something that I think is a problem.
To find these two roots in the Certificate Manager, you have to look
under "admin", rather than something having to do with Swiss BIT or FOITT.
The issuer and subject information in the certs is as follows.
CN = Admin-Root-CA
OU = Certification Authorities
OU = Services
O = admin
C = ch
CN = AdminCA-CD-T01
OU = Certification Authorities
OU = Services
O = admin
C = CH
There is no clear indication about who owns/operates these certificates.
This inhibits the users' ability to establish a chain of trust, and to
pursue complaints when appropriate.
One of the projects that I've been working on is to phase out legacy
root certificates that aren't clearly labeled with their issuer
information. I don't think that we should add new root certificates that
don't provide visible linkage to their CA organization.
I am open to suggestions, but this appears to be a show stopper.
Kathleen
Eddy Nigg
>> Swiss BIT has applied to add two root certificates. The request is to
>> all three trust bits for the “AdminCA-CD-T01” root.
> One of the projects that I've been working on is to phase out legacy
> root certificates that aren't clearly labeled with their issuer
> information. I don't think that we should add new root certificates
> that don't provide visible linkage to their CA organization.
Good catch - sometimes we don't see the forest because of all the trees.
> I am open to suggestions, but this appears to be a show stopper.
As per recent efforts in this respect and
https://wiki.mozilla.org/CA:Problematic_Practices#Generic_names_for_CAs
it might be. Considering the other issues noted, you might have to make
such a decision perhaps.
Kurt Seifried
>
> To find these two roots in the Certificate Manager, you have to look under
> "admin", rather than something having to do with Swiss BIT or FOITT.
>
> The issuer and subject information in the certs is as follows.
>
> CN = Admin-Root-CA
> OU = Certification Authorities
> OU = Services
> O = admin
> C = ch
>
> CN = AdminCA-CD-T01
> OU = Certification Authorities
> OU = Services
> O = admin
> C = CH
>
> There is no clear indication about who owns/operates these certificates.
> This inhibits the users' ability to establish a chain of trust, and to
> pursue complaints when appropriate.
I would strongly agree. As a technical user I find even I have trouble
truly establishing who is in control of what, and even once I have
figured it out (thanks largely to your spread sheet) I still have
trouble figuring who these organizations are. Some are easy like
Verisign, but some like E-TUGRA "E-TUGRA is the EBG Informatics
Technologies and Services Corporation. E-TUGRA is a privately held CA
operating in Ankara, Turkey"... how exactly am I supposed to figure
out if I should trust them or not? I love their website, click on the
american flag and you get a URL that indicates "en-US" but the site is
still in Turkish.
> One of the projects that I've been working on is to phase out legacy root
> certificates that aren't clearly labeled with their issuer information. I
> don't think that we should add new root certificates that don't provide
> visible linkage to their CA organization.
As a CA they are selling trust. If I cannot easily and reliably verify
who/what they are/etc. then they aren't doing a very good job selling
trust. Being included in Firefox/etc. is not a right so I would say it
is incumbent on the CAs to make some effort to do it properly and in a
way that supports end users of their product.
> I am open to suggestions, but this appears to be a show stopper.
>
> Kathleen
-Kurt
Gen Kanai
<kathle...@yahoo.com> wrote:
> On 1/26/10 1:19 PM, Kathleen Wilson wrote:
>>
>> Swiss BIT has applied to add two root certificates. The request is to
>> all three trust bits for the “AdminCA-CD-T01” root.
>
> I recently noticed something that I think is a problem.
>
> To find these two roots in the Certificate Manager, you have to look under
> "admin", rather than something having to do with Swiss BIT or FOITT.
>
> The issuer and subject information in the certs is as follows.
>
> CN = Admin-Root-CA
> OU = Certification Authorities
> OU = Services
> O = admin
> C = ch
>
> CN = AdminCA-CD-T01
> OU = Certification Authorities
> OU = Services
> O = admin
> C = CH
>
> There is no clear indication about who owns/operates these certificates.
> This inhibits the users' ability to establish a chain of trust, and to
> pursue complaints when appropriate.
>
> One of the projects that I've been working on is to phase out legacy root
> certificates that aren't clearly labeled with their issuer information. I
> don't think that we should add new root certificates that don't provide
> visible linkage to their CA organization.
>
> I am open to suggestions, but this appears to be a show stopper.
>
> Kathleen
I would agree with you Kathleen. We should require very clear naming
within the cert. There's no way to tell with the current information
who is the CA, where to find out information about it, etc.
Gen Kanai
Kathleen Wilson
I have added the following to
https://wiki.mozilla.org/CA:Problematic_Practices#Generic_names_for_CAs
--
Additionally, the issuer and subject information in the root certificate
must provide clear indication about who owns or operates the
certificate. Generic issuer and subject information inhibits the users'
ability to establish a chain of trust, and to pursue complaints when
appropriate. For instance, the following issuer information would not be
acceptable in a root certificate to be included in NSS.
* CN = Root CA
* OU = Certification Authorities
* OU = Services
* O = admin
--
To the representatives of Swiss BIT, I apologize for not noticing this
issue much earlier in the process. Please note Eddy's previous
recommendation: "get their root sub or cross signed by another CA
(Swiss Sign?). Since Swiss BIT has an audit, I believe this would be
perfectly in order."
To all others who have participated in this public discussion, Thank you
for volunteering your time to assist in reviewing this CA
request.
I am now closing this discussion. I will post a summary in the bug. Any
further follow-up on this request should be added directly to the bug.
Thanks,
Kathleen