1. 1 Current Status of Japanese Government PKI Systems Yasuo Miyakawa*+, Takashi Kurokawa*, Akihiro Yamamura* and Yasushi Matsumoto+ * National Institute of Information and Communications Technology (NICT), Japan + Information-technology Promotion Agency (IPA), Japan

2. 2 Background There are many e-Government projects around the world Also in Japan –As the main system, Government PKI system was constructed –In about 2000 There may have been similar projects in other countries in those days

3. 3 Abstract 2 characteristics: –I. Bridge Model –II. Signature & non-repudiation centric Current Status

4. 4 Overview 20002008 Current Status I. Bridge Model 2. Signature & non- repudiation centric Efforts on Interoperability CRYPTREC: “e-Government Recommended Ciphers List” 1. Optimization 2. + Entity Authentication 4. Revise Signature Law 3. Movement in Cryptographic analysis research 5. Migration Plan * Level of Assurance * CP (domain policy) * Smart card data format

5. 5 Our Standpoint We have not assumed the responsibility about the design of Government PKI systems - very complicated systems But, we had been consulted by the contractors, system integrators, and ministries Although it was managed to operate up to now… It will not be easy to cope with …

6. 6 I. Before talking about Bridge CA Model Ministry A Ministry B Our PKI system Our PKI System Vertically Divided Administration –Ministries should have dealt equally No superior –Ministries wished to have flexibility

7. 7 I. Trust Model of Government PKI Systems in Japan

8. 8 PKI System Owners Subject of Certificates Respective Ministry Bridge CAOther CAs GPKI National government employee MIC Administrative Management Bureau MIC Administrative Management Bureau Ministries LGPKI Local government employee MIC Local Administration Bureau LGWAN Administration Council Prefectures JPKI CitizensJPKI Prefectures Council

9. 9 Vertically Divided Administration again Prefectures should be treated equally No superior –Bridge Model is adopted –Actually, identical CPSs and CPs

10. 10 Our efforts regarding Bridge Model In 2002 –There was not Trust Status List Test-suite for Japanese government PKI software –Testing datum for path validation over Bridge CA –IPA’s Contractor http://www.jnsa.org/mpki/index.html

11. 11 Our efforts regarding Bridge Model IETF Internet-Draft: Guidance –“Memorandum for multi-domain Public Key Infrastructure Interoperability” Already cleared – RFC will be published soon http://www.ietf.org/internet-drafts/draft-shimaoka- multidomain-pki-13.txthttp://www.ietf.org/internet-drafts/draft-shimaoka- multidomain-pki-13.txt Practical factors –e.g.: ‘Domain Policy Object Identifier’ –Certificate Policy as Domain Policy

12. 12 II. Signature & non-repudiation centric The majority of certificates are for Non- repudiation –keyUsage bit: set in US style –CP: not well utilized, no confusion ? ACT ON ELECTRONIC SIGNATURES AND CERTIFICATION BUSINESS (2001) –http://www.moj.go.jp/ONLINE/CERTIFICATION/http://www.moj.go.jp/ONLINE/CERTIFICATION/ With 2 Ministerial Ordinance Discussion has started to revise these legislation –To be explained later

13. 13 FYI: CRYPTREC Cryptography Research and Evaluation Committees –http://www.cryptrec.jp/english/index.htmlhttp://www.cryptrec.jp/english/index.html –Cryptographic Technique Monitoring Subcommittee “e-Government Recommended Ciphers List”

14. 14 Recent Undertakings 1.Optimizing GPKI System 2.Concerns for Entity Authentication 3.Estimating the Improvement of Factoring Power 4.Revising ACT ON ELECTRONIC SIGNATURES AND CERTIFICATION BUSINESS and its Ministerial Ordinance 5.Migration Plan about Cryptography which is used in PKI Systems

15. 15 1. Optimizing GPKI System Conducted by MIC Administrative Management Bureau –Planed in March, 2005 –To be completed in FY 2008 –From economic point of view Duplication in issuing function Managing operational practices may be centralized –Centralized CA for GPKI CAs: 14 -> 1 RAs will remain Several exceptions: –commercial register system’s CA

16. 16 2. Concern for Entity Authentication Level of Assurance –Developing Guideline documents Citizen’s Smart Cards Format –Multiple credentials –Open specification is expected Certificate Policy (PKI domain Policy) –Risk to confuse: Signature non-repudiation Other purpose Written in RFC 5280 –MUST be distinguished

17. 17 3. Movement in Cryptographic analysis research Estimating GNFS sieving steps

18. 18 3. Movement in Cryptographic analysis research Estimating collision of SHA-1

19. 19 4. Revising ACT ON ELECTRONIC SIGNATURES AND CERTIFICATION BUSINESS and its Ministerial Ordinance Under discussion We are supporting Technical issues Technical issues are not dealt widely yet Administrative Scheme issue Certifying procedure ： heavy ! CA’s business issue Promotion etc. Technical issues Spend most of the time on Cryptographic issue Dealt independently

20. 20 4. Status of the discussion Technical issue –Based on certifying conforming CAs –As a requirement for certified CA: cryptographic issue is included Although it was the main topic in the first stage… There are many other technical issues Need to get understood by lawyers

21. 21 4. To be discussed Preventing misrecognition on Section 10 –Often considered as Prohibition of other business Serious effect on CA’s business Can be solved by CP description Confusion: signature on certificates vs. signature on digital documents –different level of Risks Actually, Not well utilized –Signature is for Authority person and Professionals

22. 22 5. Migration Plan about Cryptography which is used in PKI Systems RSA-1024 and SHA-1 May be Internationally common issue How we can deal this issue? –Application level discussion may be different from Primitive level discussion –Multi level of risks –Roadmap / Procedure

23. 23 Conclusion Bridge Model may be the typical trust model for national level PKI systems –Efforts to keep interoperability is required Additional system requirements –Which have not supposed before 2000 –Not only Signature & non-repudiation –Should be put into design consistently Thank you