Japanese GPKI Root Inclusion Request

222 views
Skip to first unread message

Kathleen Wilson

unread,
Oct 1, 2009, 1:01:23 PM10/1/09
to
As per the CA Schedule at https://wiki.mozilla.org/CA:Schedule the
Japanese Government Public Key Infrastructure (GPKI) is the next
request in the queue for public discussion.

The Japanese Government has two primary root CAs, one is GPKI which
acts as a root for national government agencies, and the other one is
LGPKI (Local Government PKI) which serves the same function for
regional and local governments. GPKI is controlled by Japan’s Ministry
of Internal Affairs and Communications (MIC). LGPKI is controlled by
Japan’s Local Government Wide Area Network (LGWAN) Operation
Committee.

The Japanese GPKI (Japan national government CA) has applied to add
the “ApplicationCA - Japanese Government” root certificate and enable
the Websites and Code Signing trust bits. The request is documented in
the following bug:

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

And in the pending certificates list here:

http://www.mozilla.org/projects/security/certs/pending/#Japanese%20GPKI

Summary of Information Gathered and Verified:

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

Noteworthy points:

* The CP/CPS has been translated into English:
https://bug474706.bugzilla.mozilla.org/attachment.cgi?id=379657

* This root is operated by the national government of Japan. It issues
server certificates and code signing certificates to national
government agencies. This root issues end-entity certificates
directly, and does not have any subordinate CAs.

* The request is to enable the Websites and Code Signing trust bits.

** CP/CPS Section 3.2.2, Authentication of organization identity: As
for the application procedure of a Server certificate and code-signing
certificate, the LRA shall confirm the authenticity of the
organization to which the subscriber belongs by collating the
information (organization and so on) described in the application with
the directory of government officials issued by National Printing
Bureau and so on.

** CP/CPS Section 3.2.3, Authentication of individual identity: As for
the application procedure of a Server certificate and codesigning
certificate, the LRA shall confirm the authenticity of the subscriber
by collating the information (name, contact address and so on)
described in the application with the directory of government
officials issued by National Printing Bureau and so on. And the LRA
shall confirm the intention to subscribe by telephone or face to face.

** CP/CPS Section 4.1.2, Enrollment process and responsibilities
Server certificate: The LRA shall confirm that the domain holder of
the common name (CN) described in the Server certificate application
is the organizations of offices and ministries to which the LRA
belongs by using the database provided by the third-party body and so
on, and apply accurate information to the IA and RA.

** CP/CPS Section 4.1.2, Enrollment process and responsibilities Code
signing certificate: The LRA shall confirm that the organization name
of the common name (CN) described in the code-signing application
exists and it is the organization name of offices and ministries to
which the LRA belongs by using the public documents published by
offices and ministries, and apply accurate information to the IA and
RA.

* Test website: https://www.gpki.go.jp/selfcert/finger_print.html

* GPKI provides CRL, NextUpdate is 48 hours
* GPKI does not provide OCSP

* Audit: The Japanese GPKI was audited within the past year by
Deloitte Touche Tohmatsu, using the WebTrust CA criteria.
https://cert.webtrust.org/SealFile?seal=886&file=pdf (Japanese)
https://bugzilla.mozilla.org/attachment.cgi?id=374841 (English)

* Noted in Audit: MIC (Japan’s Ministry of Internal Affairs and
Communications) “makes use of external registration authorities for
specific subscriber registration activities as disclosed in MIC’s
business practice disclosures. Our examination did not extend to the
controls of external registration authorities.”
** The prescribed procedure is documented in detail in the LRA
business management and system operation manual. This document is
disclosed for government agencies only because the CA only issues
certificates for government agencies, and it contains internal
operating details.

This begins the 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

Ian G

unread,
Oct 1, 2009, 1:50:35 PM10/1/09
to dev-secur...@lists.mozilla.org
On 01/10/2009 19:01, Kathleen Wilson wrote:
> https://bug474706.bugzilla.mozilla.org/attachment.cgi?id=379657


> ** CP/CPS Section 3.2.3, Authentication of individual identity: As for
> the application procedure of a Server certificate and codesigning
> certificate, the LRA shall confirm the authenticity of the subscriber
> by collating the information (name, contact address and so on)
> described in the application with the directory of government
> officials issued by National Printing Bureau and so on. And the LRA
> shall confirm the intention to subscribe by telephone or face to face.


1. Can we confirm whether any certs are issued to individuals?

My quick scan indicated that the certs only are issued to organisations
(government departments) so the above seems odd, possibly written in an
over-zealous mode to say something.


> ** CP/CPS Section 4.1.2, Enrollment process and responsibilities
> Server certificate: The LRA shall confirm that the domain holder of
> the common name (CN) described in the Server certificate application
> is the organizations of offices and ministries to which the LRA
> belongs by using the database provided by the third-party body and so
> on, and apply accurate information to the IA and RA.


Although there are few things that we can expect governments to be
competent at, one of those things is recognising their individual
departments and so forth. I don't think this area is our biggest of
problems.


> * GPKI does not provide OCSP


I imagine the technical people would be upset at this.

2. I would ask what their plans are to put in OCSP?


> * Audit: The Japanese GPKI was audited within the past year by
> Deloitte Touche Tohmatsu, using the WebTrust CA criteria.
> https://cert.webtrust.org/SealFile?seal=886&file=pdf (Japanese)
> https://bugzilla.mozilla.org/attachment.cgi?id=374841 (English)
>

> * Noted in Audit: MIC (Japan�s Ministry of Internal Affairs and
> Communications) �makes use of external registration authorities for
> specific subscriber registration activities as disclosed in MIC�s


> business practice disclosures. Our examination did not extend to the

> controls of external registration authorities.�

Yes, saw that. But these LRAs are all local government departments
within the government. They are all the same entity at one level or
another, legally (following the "mammoth government school" of legal
theory...). So I see no problem here; it's within their competence and
it's the same legal domain.


> ** The prescribed procedure is documented in detail in the LRA
> business management and system operation manual. This document is
> disclosed for government agencies only because the CA only issues
> certificates for government agencies, and it contains internal
> operating details.

Point of clarification: this prescribed procedure is the one referring
tot ha above, use of external registration authorities, specifically the
LRAs?


I have one other question.

3. To what extent do non-government users get exposed to this root?

If the servers and code is all for governmental use only then there is a
trivial situation because the relying party is the subscriber is the CA.
Aka the govt. If however the citizens of the country are served up
these sites and code, this becomes more of an issue.

(In sum, I don't see an issue yet.)

iang

Japan GPKI ApplicationCA

unread,
Oct 5, 2009, 1:18:54 AM10/5/09
to
Hi Ian,

On 10/2, 2:50, Ian G <i...@iang.org> wrote:
> On 01/10/2009 19:01, Kathleen Wilson wrote:
>
> >https://bug474706.bugzilla.mozilla.org/attachment.cgi?id=379657
> > ** CP/CPS Section 3.2.3, Authentication of individual identity: As for
> > the application procedure of a Server certificate and codesigning
> > certificate, the LRA shall confirm the authenticity of the subscriber
> > by collating the information (name, contact address and so on)
> > described in the application with the directory of government
> > officials issued by National Printing Bureau and so on. And the LRA
> > shall confirm the intention to subscribe by telephone or face to face.
>
> 1.  Can we confirm whether any certs are issued to individuals?

No. This root issues certificates to organizations (government
departments).
CP/CPS section 3.2.3 mentions authenticity of subscriber.


> My quick scan indicated that the certs only are issued to organisations
> (government departments) so the above seems odd, possibly written in an
> over-zealous mode to say something.
>
> > ** CP/CPS Section 4.1.2, Enrollment process and responsibilities
> > Server certificate: The LRA shall confirm that the domain holder of
> > the common name (CN) described in the Server certificate application
> > is the organizations of offices and ministries to which the LRA
> > belongs by using the database provided by the third-party body and so
> > on, and apply accurate information to the IA and RA.
>
> Although there are few things that we can expect governments to be
> competent at, one of those things is recognising their individual
> departments and so forth.  I don't think this area is our biggest of
> problems.
>
> > * GPKI does not provide OCSP
>
> I imagine the technical people would be upset at this.
>
> 2.  I would ask what their plans are to put in OCSP?

No. There is no plans to put in OCSP at this time.


> > * Audit: The Japanese GPKI was audited within the past year by
> > Deloitte Touche Tohmatsu, using the WebTrust CA criteria.
> >https://cert.webtrust.org/SealFile?seal=886&file=pdf (Japanese)
> >https://bugzilla.mozilla.org/attachment.cgi?id=374841(English)
>

> > * Noted in Audit: MIC (Japan’s Ministry of Internal Affairs and
> > Communications) “makes use of external registration authorities for
> > specific subscriber registration activities as disclosed in MIC’s


> > business practice disclosures. Our examination did not extend to the

> > controls of external registration authorities.”


>
> Yes, saw that.  But these LRAs are all local government departments
> within the government.  They are all the same entity at one level or
> another, legally (following the "mammoth government school" of legal
> theory...).  So I see no problem here;  it's within their competence and
> it's the same legal domain.
>
> > ** The prescribed procedure is documented in detail in the LRA
> > business management and system operation manual. This document is
> > disclosed for government agencies only because the CA only issues
> > certificates for government agencies, and it contains internal
> > operating details.
>
> Point of clarification:  this prescribed procedure is the one referring
> tot ha above, use of external registration authorities, specifically the
> LRAs?

Yes. LRA business management and system operation manual is
used by LRAs.


> I have one other question.
>
> 3.  To what extent do non-government users get exposed to this root?

The certificates issued by this root are used for services of
government
(electronic application receipt page, software distributed from
government
and so on).
So both government and non-government users are served up these sites
and codes.


> If the servers and code is all for governmental use only then there is a
> trivial situation because the relying party is the subscriber is the CA.
>   Aka the govt.  If however the citizens of the country are served up
> these sites and code, this becomes more of an issue.
>
> (In sum, I don't see an issue yet.)
>
> iang

--
Yoshikazu Ooe

Ian G

unread,
Oct 5, 2009, 11:31:45 AM10/5/09
to Japan GPKI ApplicationCA, dev-secur...@lists.mozilla.org
Hi Yoshikazu Ooe,

Thanks for your quick response!


On 05/10/2009 07:18, Japan GPKI ApplicationCA wrote:

>> 1. Can we confirm whether any certs are issued to individuals?
>
> No. This root issues certificates to organizations (government
> departments).
> CP/CPS section 3.2.3 mentions authenticity of subscriber.


Thanks.


>>> * GPKI does not provide OCSP
>>
>> I imagine the technical people would be upset at this.
>>
>> 2. I would ask what their plans are to put in OCSP?
>
> No. There is no plans to put in OCSP at this time.


I had a read of Mozilla OCSP position over the weekend for another task,
and it seems that this is not an issue. So no problem from me.


>>> ** The prescribed procedure is documented in detail in the LRA
>>> business management and system operation manual. This document is
>>> disclosed for government agencies only because the CA only issues
>>> certificates for government agencies, and it contains internal
>>> operating details.
>>
>> Point of clarification: this prescribed procedure is the one referring
>> tot ha above, use of external registration authorities, specifically the
>> LRAs?
>
> Yes. LRA business management and system operation manual is
> used by LRAs.


OK.


>> I have one other question.
>>
>> 3. To what extent do non-government users get exposed to this root?
>
> The certificates issued by this root are used for services of
> government
> (electronic application receipt page, software distributed from
> government
> and so on).
> So both government and non-government users are served up these sites
> and codes.


OK. So this is the point where Mozilla takes on some uncertainty and
risk, because Mozilla is the party that delivers the browser/mailer/etc
to the end-users. So in theory, we should be examining the CA's
agreements with those end-users in order to determine the level of that
risk/liabilities/obligations that is residual/unallocated, so as to
discharge Mozilla's responsibility towards itself and end-users.

However precedent is that we/Mozilla do not do that. And in this
particular case, it is not the normal commercial situation, and most
analyses will rest heavily on govt<-->citizen relationship. E.g., it's
not expected to be an issue.

I would conclude "not a problem." I note that this is an approximation,
but given the situation, I think it serves us.

Eddy Nigg

unread,
Oct 7, 2009, 2:31:08 AM10/7/09
to
On 10/01/2009 07:01 PM, Kathleen Wilson:

Kathleen, I'm missing some more information regarding the domain control
validation. I've seen the attachment at the bug, still it's not entirely
clear to me. I'd also like to note the following:

root for national government agencies
root regional and local governments

It's not clear to me what the purposes of those roots exactly are. Do
they issue certificates only to government agencies? I need here a
clarification!

There are problematic practices mentioned, direct issuance from the
roots and missing OCSP responder. In both cases users may be at risk
with this CA. Additionally there appear to be RAs, none are audited.
What exactly does the Japanese GPKI or the responsible ministry in order
to guaranty adherence and proper execution of the RA functions?

--
Regards

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


Japan GPKI ApplicationCA

unread,
Oct 9, 2009, 5:08:09 AM10/9/09
to
Hi Eddy,

On 10/7, 3:31PM, Eddy Nigg <eddy_n...@startcom.org> wrote:

> > Kathleen, I'm missing some more information regarding the domain control
> > validation. I've seen the attachment at the bug, still it's not entirely
> > clear to me.

Validation of contents described in the server certificate application
are following:
- The server's absolute domain name (FQDN) which described in
certificate application is part of go.jp domain or registered
beforehand and registered in DNS.
- The organization of domain holder which is verified with the whois
service (http://whois.jprs.jp/) is part of organizations including
offices and ministries.


> > I'd also like to note the following:
> > root for national government agencies
> > root regional and local governments
> >
> > It's not clear to me what the purposes of those roots exactly are. Do
> > they issue certificates only to government agencies? I need here a
> > clarification!

The LGPKI root is being handled in a different request (http://
bugzilla.mozilla.org/show_bug.cgi?id=477314), this one is only for
GPKI.


> > There are problematic practices mentioned, direct issuance from the
> > roots

In physical term:
Network access to the CA server is restricted to minimal hosts and
ports by FireWall.
The CA server is placed in the room which shall be subject to strict
entry/exit control at multiple biometric authentication by multiple
persons.

In operation term:
Our CA issues small amount of certificates, because our CA only issues
certificates for SSL and code signing to national government agencies.
When the important services are performed, authorities of personnel
are separated for mutual checks and balances.


> > and missing OCSP responder.

Our CRLs follow the Mozilla Policy, and OCSP does not appear to be
required.


> > In both cases users may be at risk
> > with this CA.
> > Additionally there appear to be RAs, none are audited.
> > What exactly does the Japanese GPKI or the responsible ministry in order
> > to guaranty adherence and proper execution of the RA functions?

As described in figure 1-1 and section 1.3.3 of CP/CPS, the
organization in each office and ministry acts as LRA.
Based on section 8 of CP/CPS, we have been auditing the LRAs every
year, and our CA's external auditor has been auditing our execution of
the audit.

The procedures and internal checks performed by the LRAs are
documented in the LRA business management and system operation manual,
each LRAs follow this manual.
This manual is issued by Administrative Management Bureau, Ministry of
Internal Affairs and Communications that direct this root.


Best Regards,
--
Yoshikazu Ooe

Kyle Hamilton

unread,
Oct 9, 2009, 4:53:38 PM10/9/09
to Japan GPKI ApplicationCA, dev-secur...@lists.mozilla.org
I perceive no issues to fault with this application, and recommend
approval as-is.

I do have a question, though: can you provide an example of a Japanese
national government website which does *not* end in '.go.jp'? (If
there isn't one, under what circumstances would/could one be created?)

-Kyle H

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

Eddy Nigg

unread,
Oct 9, 2009, 5:15:15 PM10/9/09
to
Hi Yoshikazu,

Thank you for your response.

On 10/09/2009 11:08 AM, Japan GPKI ApplicationCA:


> The LGPKI root is being handled in a different request (http://
> bugzilla.mozilla.org/show_bug.cgi?id=477314), this one is only for
> GPKI.
>

OK, that answers my next question already. I believe there is some value
for Mozilla users with this request, even though the scope of this CA is
very limited.

> In physical term:
> Network access to the CA server is restricted to minimal hosts and
> ports by FireWall.
> The CA server is placed in the room which shall be subject to strict
> entry/exit control at multiple biometric authentication by multiple
> persons.
>
> In operation term:
> Our CA issues small amount of certificates, because our CA only issues
> certificates for SSL and code signing to national government agencies.
> When the important services are performed, authorities of personnel
> are separated for mutual checks and balances.
>

Excellent! Please note that in case should anything ever happen to the
root, recovery with the existing root is almost impossible and a new
root will have to be issued. That's one of the reasons intermediate CA
certificates are preferred, but since your root isn't used on an online
system, I think this is one of the exceptions which allows for such
usage. I nevertheless suggest to consider using intermediate CA
certificates for signing in the future.

>>> and missing OCSP responder.
>>>
> Our CRLs follow the Mozilla Policy, and OCSP does not appear to be
> required.
>

Correct. OCSP has advantages over CRLs and currently is the only means
for revocation checking by Firefox. Even though it's planned to have CRL
and CDP support, I think you should know about the fact that users of
Mozilla software right now will have no protection.

> The procedures and internal checks performed by the LRAs are
> documented in the LRA business management and system operation manual,
> each LRAs follow this manual.
> This manual is issued by Administrative Management Bureau, Ministry of
> Internal Affairs and Communications that direct this root.
>

Thanks again.

Japan GPKI ApplicationCA

unread,
Oct 13, 2009, 2:18:19 AM10/13/09
to
Hi Kyle,

On 10/10, 5:53AM, Kyle Hamilton <aerow...@gmail.com> wrote:

> I do have a question, though: can you provide an example of a Japanese
> national government website which does *not* end in '.go.jp'?  (If
> there isn't one, under what circumstances would/could one be created?)

The websites which do not end in '.go.jp' are as follows.

www.e-procurement-cao.jp
www.cupes.jp

These websites are serving electronic procurement for Japanese
national government and customs procedure entry system.

Kathleen Wilson

unread,
Oct 13, 2009, 1:35:03 PM10/13/09
to
Thank you to all of you who have reviewed this request and added your
comments and feedback to this discussion. Your contributions are
greatly appreciated.

This discussion was in regards to the request from the Japanese
Government Public Key Infrastructure (GPKI) to add the “ApplicationCA


- Japanese Government” root certificate and enable the Websites and
Code Signing trust bits.

There are no action items resulting from this discussion.

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

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

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

Thanks,
Kathleen

Reply all
Reply to author
Forward
0 new messages