Swiss BIT has applied to add two root certificates. 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.
* 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.
* 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.
* 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.
> Swiss BIT has applied to add two root certificates. 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.
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.
> > Swiss BIT has applied to add two root certificates. 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.
> 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 ;-)
> 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.
> Swiss BIT has applied to add two root certificates. 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.
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.
> * 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.
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.
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.
On 9 Lut, 03:02, Eddy Nigg <eddy_n...@startcom.org> wrote:
> 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.
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
> 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:
/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). /
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.
On 9 Lut, 16:22, Eddy Nigg <eddy_n...@startcom.org> wrote:
> 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.
> > 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:
> /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). > /
> 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.
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. ")
> On Feb 9, 4:22 pm, Eddy Nigg <eddy_n...@startcom.org> wrote:
> > 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:
> > /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). > > /
> > 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.
> 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. ")- Zitierten Text ausblenden -
> - 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.langeneg...@bit.admin.ch> wrote: > On 10 Feb., 10:43, chemalogo <chemal...@gmail.com> wrote:
> > On Feb 9, 4:22 pm, Eddy Nigg <eddy_n...@startcom.org> wrote:
> > > 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:
> > > /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). > > > /
> > > 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.
> > 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. ")- Zitierten Text ausblenden -
> > - 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.- Zitierten Text ausblenden -
Thank you to those who have reviewed this root inclusion request from 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.
> 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 :-)
>> 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).
> 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.
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...
> 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.
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.
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.
> Thank you to those who have reviewed this root inclusion request from > 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.
> 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.
> 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.
> 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.
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.
Here some statements from SwissBIT according the question of relevance 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:
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.
Kathleen Wilson wrote: > 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.
> 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.
This is not what was explained previously. Where can I get a certificate from Swiss BIT, I'd like to enroll for one.
> 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.
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.
> 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.
