RE: [egov] Brief report: G2G PKI in the Nordic Region

[Colin.Wallis@ssc.govt.nz]

Anders, 

Mike does not have OASIS permissions so I have forwarded this to them so it
can be accessed by the group, in addition to your own email address. 

Cheers
Colin
............................................................................
...............
Hi,some more information, this time about:

- why secure email versus web mail;
- our unique concepts for online authentication.

Regards, Mike


>SECUREMAIL is something that differs from what is in the works
>here.  We have to almost 100% based all C2G activities on the
>web, using browsers.  

The SecureMail project came out because many NZ government agencies were
implementing web messaging systems.  For an Agency, a web message system is
technically easy - it integrates nicely into existing backend systems and
processes.  For the User, it is equivalent to having every Agency put a
seperate mailbox on their front lawn, normally with a separate lock/key
mechanism.  Typically the User is further disadvantaged because they do not
have a copy of the information, in an easily re-usable format.

The old saying goes that "if all you have is a hammer then every problem
looks like a nail".  With SecureMail, we are providing a new tool - how and
when it will be used, we can only imagine.  As an example of how powerful
the tool might be, I often talk about my milkman, who sends me a paper
invoice for $20 every month:

	SecureMail provides a high degree of confidence
	that the FROM: address is correct.

	Therefore, I can receive an invoice for $20 and 
	trust it is from my milkman.  The invoice can 
	have human-readable information at the top, 
	and XML data at the bottom.

	I can forward the invoice to my bank account as
	an instruction to pay.  I might login to my bank
	account in the future, and receive a schedule of
	invoices awaiting payment, complete with all 
	descriptions.  I might have a standing instruction
	with the bank, to pay small amounts without further
	confirmation.  I might have to confirm larger amounts
	via SMS or other out-of-band process.

	The bank can value-add, by generating a remittance
	advice, based on the XML, back to the milkman 
	and myself.


>What is still [completely] missing in our plot is something
>like the following:
>http://w1.181.telia.com/~u18116613/onlinesigstdprop.ppt


We take a very wide approach to this issue.  We are continually reminding
agencies that technology is not a solution.  Issues of authentication and
non-repudiation, involve many factors, including people, technology,
process, etc.  From our "Best Practice Framework for Authentication":
http://www.e-government.govt.nz/docs/authentication-bpf/index.html.  

	"Will we have credible evidence to persuade a third-party 
	authority that we have enough non-repudiation?"

PKI looks like the single solution for everything, but we are struggling to
see how we can make it work realistically without throwing truckloads of
money at propping it up.  Instead we are taking small bites of the problem,
..., confidentiality, authentication, etc.  Long-term non-repudiation, by
the way, is probably last on our list to think about.


>And of course the problem that we *all* share: how to carry
>our citizen certificates.  Do you have any input on the latter
>I would very much appreciate it!

I cannot offer input as I do not know your unique country requirements.
Since I did the conceptual design for our online authentication project, I
am able to talk about our approach and you may be able to draw ideas.  

Our unique design constraint compared to many European countries: "the
all-of-government model does not require national ID cards, digital
certificates or the exchange of biometric data at the time of transaction
(consistent with authentication principles such as technology-neutral,
affordability and acceptability)" 

Our unique environment compared to many European countries: we are only 4
million people, and we don't have much money.


Our core design concepts are:

[1] ID CREDENTIAL: An ID credential is a recorded set of identity data, or
attributes, provided by a living person and verified by the Authentication
Agency using a process to establish identity. In other words the ID
credential created by the Authentication Agency is an electronic record
containing verified identity data.  The identity data on the ID credential
will be kept to the minimum required to ensure the uniqueness of the
individual.  This function would be carried out by the government.

[2] KEY: In an online environment, a Client must be able to demonstrate they
are authorised to access/present an ID credential.  This is typically
achieved by possession of a Key, which authenticates the Client. A Key is
the technology that allows the Client to unlock and provide the information
on their ID credential to a Service Agency.  This function can be done by
any reliable Service Provider.


Principles associated with Keys:

-- Keys must be unique;

-- a Client can have one or more Keys. Most Clients will only want and need
one Key, but a Client could choose to have multiple Keys;

-- different types of Keys could be used in the all-of-government
authentication solution;

-- a Key has no value until it is authorised to access something;

-- Keys can be issued by entities other than the Authentication Agency; and

-- Service Agencies will not hold copies of their Clients Keys;


[3] SEPARATING THE KEY FROM THE ID CREDENTIAL
The My-Key concept came about, because I was thinking "why should I use your
key (government), I have many keys in my life already, why can't I use my
keys?".  


Separating the Key and ID credential:
-- reduces the risk of a physical Key being perceived as an identity card,
because the Key does not impart identity data and does not expose the ID
credential data at every transaction without the Client authorising the
release;

-- provides the Client with a choice as to which Key they use and when;

-- means the Client can reuse the Key for pseudonymous transactions (trust
level 1), in addition to authenticated transactions (trust levels 2 and 3);

-- will allow a Client to choose to have many different Keys (fit for
purpose) while avoiding the unnecessary duplication of the ID credential;

-- allows the Client to revoke a Key if they are concerned about security,
without the cancellation of the ID credential.

-- provides greater flexibility for agencies delivering services (e.g. they
can retain their own existing Key technologies and processes


Further information on the online authentication project can be found here:
http://www.e-government.govt.nz/authentication/index.asp

The project team can be contacted mailto:authentication@ssc.govt.nz



>I believe Sweden selected a less useful approach, soft certificates
>and Java applets.  

Yes, I would agree - it seems like a very expensive username/password.


Our neighbors' systems runs on ANY
>computer and can also be used at Internet cafés.  Our system
>OTOH is basically only useful from your own trusted
>computers.

There is no such thing as a trusted computer these days.  One of the issues
with SecureMail is that when people start to use computers for "valuable"
purposes, you have to tell them to stop using shared computers, public
computers, etc.


>Personally, I believe that e-governments should go together
>and make sure that the mobile phone becomes the authentication
>device because that potentially beats all alternatives by a mile.

I think phones are one form of authentication device.  New Zealand, outside
of the main population centres, has low population density, lots of hills
and therefore poor cell phone coverage.  Government has to reach 100% of the
population.



Regards, 
Mike Pearson, Senior Advisor     E-government Unit,
mailto:mike.pearson@ssc.govt.nz  STATE SERVICES COMMISSION
Phone : +64  (4) 495-6769        Te Komihana O Nga Tari Kawanatanga
Fax   : +64  (4) 495-6669        Level 4, 100 Molesworth St
Mobile: +64 (21) 631-731         PO Box 329, Wellington 6015, NEW ZEALAND 
*************************************************************************
If you have received this email in error, please let us know as soon as 
possible and then delete it.
*************************************************************************
www.e-government.govt.nz         www.ssc.govt.nz

www.govt.nz - connecting you to New Zealand central & local government
services