Transcript Current Status of Japanese Government PKI Systems

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
1
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
2
Abstract
• 2 characteristics:
– I. Bridge Model
– II. Signature & non-repudiation centric
• Current Status
3
Overview
2000
I. Bridge Model
2008 Current Status
Efforts on
Interoperability
1. Optimization
2. + Entity Authentication
2. Signature & nonrepudiation centric
* Level of Assurance
* CP (domain policy)
* Smart card data format
CRYPTREC:
“e-Government
Recommended
Ciphers List”
3. Movement in Cryptographic
analysis research
4. Revise Signature Law
5. Migration Plan
4
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 …
5
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
6
I. Trust Model of Government PKI Systems in Japan
7
PKI System Owners
Subject of
Certificates
Respective
Ministry
Bridge CA
GPKI
National
government
employee
MIC
Administrative
Management
Bureau
MIC
Ministries
Administrative
Management
Bureau
LGPKI
Local
government
employee
MIC
LGWAN
Prefectures
Administration
Local
Administration Council
Bureau
JPKI
Prefectures
Council
Citizens
JPKI
8
Other CAs
Vertically Divided Administration again
• Prefectures should be treated equally
• No superior
– Bridge Model is adopted
– Actually, identical CPSs and CPs
9
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
10
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-shimaokamultidomain-pki-13.txt
• Practical factors
– e.g.: ‘Domain Policy Object Identifier’
– Certificate Policy as Domain Policy
11
II. Signature & non-repudiation centric
• The majority of certificates are for Nonrepudiation
– 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/
• With 2 Ministerial Ordinance
• Discussion has started to revise these legislation
– To be explained later
12
FYI: CRYPTREC
• Cryptography Research and Evaluation
Committees
– http://www.cryptrec.jp/english/index.html
– Cryptographic Technique Monitoring
Subcommittee
• “e-Government Recommended Ciphers List”
13
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
14
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
15
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
16
3. Movement in Cryptographic analysis research
Estimating GNFS sieving steps
17
3. Movement in Cryptographic analysis research
Estimating collision of SHA-1
18
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
CA’s business issue
Promotion etc.
Technical issues
Spend most of
the time on
Cryptographic issue
Administrative Scheme issue
Dealt independently
Certifying procedure：heavy !
19
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
20
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
21
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
22
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
23