Hi Matt,
My personal reason for scanning certain
lists and specs as well as putting "newbie" questions is because I don't believe
I have monopoly on good ideas.
Regarding IP: it is close to impossible to
know if there are any IPR in the stuff you find at home or on the web.
Personally, I find IPR on protocols as the best way NOT to succeed, so I publish
everything that feels the slightest bit "novel" on
http://defensivepublications.org
including putting in a specific notice that I don't
have any IPR claims myself (but of course somebody else could).
Device
certificates is not a unique idea so KMIP should be able to use it if they
want. I'm going to publish the (unfortunately) probably unique enrollment
concept that you get as a bonus so that anybody can use it
without fear:
A side-effect of using
certificate-based device IDs is that you can create efficient and still quite
secure on-line enrollment processes where a non-authenticated user signs-up
for credentials by sending an SKS-attested request to an issuer. The issuer
can then verify the user’s identity with an OOB (Out Of Band) method meeting
the issuer’s policy which can be anything from the classic “e-mail roundtrip”,
to requiring the user to show up in an office with an identity card. The final
part is asking the user for something like the first 8 characters of the 40
hexadecimal-digit SHA1 certificate hash which is the short-form of the device
ID. If the answer is matching the device ID of the request, the issuer returns
the completed credential package to the user’s SKS. Note that this scheme can
completely eliminate enrollment passwords!
Air-tight provisioning is already published.
It is pretty cool idea but applying to a protocol is not trivial; it caused at
total rewrite of KeyGen2 as well as requiring complete reprogramming of smart
cards:
http://sourceforge.net/mailarchive/forum.php?thread_name=E39A6481FD734E9EA548052072D201A8%40AndersPC&forum_name=trousers-users
Many people would consider such requirement
as fairly stupid but the fact is that I'm "fighting" with HTML5's
<keygen> which is a really useless thing that the browser vendors have
decided to make the *their* KM solution:
http://www.nabble.com/Re%3A-Smart-cards-and-the-%3Ckeygen%3E-element-p23876670.html
Actually, quite a bunch of the smart card vendors
have indicated interest in air-tight provisioning. It might be a better
thing than JavaCard3 because it is very unclear why you need WS* inside a smart
card while air-tight provisioning enables faster and cheaper ways of
enrolling and distributing tokens.
enjoy!
Anders
----- Original Message -----
From: Matt Ball
To: Anders Rundgren
Cc:
Sent: Thursday, June 11, 2009
23:20
Subject: Re: KMIP & EKMI Credential Bootstrapping
Hi
Anders,
This message appears to be a suggestion that the OASIS KMIP TC
adopt certain ideas. Before the TC can consider these recommendations, you
need to do one of these things:
Join KMIP as a member and agree to the IP
Policy
Sign the "Feedback License" (see
http://www.oasis-open.org/who/intellectualproperty.php#appendixa)
Without
one of these two things, there's not much the KMIP TC can do with this
information.
Thanks!
-Matt
Anders Rundgren wrote:
When you
are about to perform trustworthy operations between different entities,
authentication of the end-points is typically necessary.
It seems that
KMIP (as well as EKMI) leaves the bootstrapping of end-point authentication
credentials to somebody else to cater for.
Since this process is both
highly device-dependent as well as generally difficult, KMIP interoperability
may in practice prove to be quite limited.
As a comparison, my own
brain-child, KeyGen2, builds on the fact that devices are shipped with a device
certificate.
One may claim that KeyGen2 requires enhanced devices, and yes
this is true!
The problem with not requiring enhanced devices is that
"the tyranny of the least common denominator" will rule which is a stopgap to
progress. That is, the missing bootstrap may severely impede market
acceptance.
Note: KeyGen2 does not compete with KMIP because KeyGen2
(deliberately) supports a very limited range of devices that are used by
everybody (phones) but would be totally useless for storage. I would if I
were you consider "borrowing" the device certificate concept.
Properly
implemented, all kinds of shared secrets and enrollment passwords are eliminated
by device certificates.
If you are curious on how such a scheme could work
you may take a peek in section "Dual-use Device IDs"
in:
http://webpki.org/papers/keygen2/secure-key-store.pdf
thanks
Anders
