Hi Adrian,
Thank you for the prompt response.
I believe that <keygen> only represent the tip of an iceberg because the
fact is that in the EU banks and governments are spending huge sums on
developing proprietary and national replacements of the local PKI-client
in browsers because the latter are not only all over the map; they do
not support things like on-line signatures.
The following is a recent example of maybe 20 different efforts of this
kind:
http://egovlabs.gv.at/projects/mocca
I.e. even if <keygen> would be standardized (and adopted by Microsoft
and other leading browser vendors...), it would not make any difference
for the major users of PKI since /they still would need to deploy their
own stuff/.
There is though one area which /desperately/ needs a standard "<keygen>"
and that are mobile phones. Why is that? It is because unlike for PCs
where most serious users of PKI use with smart cards that are physically
distributed, mobile phones lack such a possibility, because SIMs are
tied to operators and are thus generally useless as key-containers.
The real problem here is that this issue spans multiple "departments"
and "platform owners" which so far has lead to a decade-long
stand-still. My guess is that this effectively makes it unreachable
from a traditional standardization perspective. I believe Microsoft's
introduction of InformationCards was a very good way of introducing new
technology which was a bit similar to WHATWG did with HTML5 (i.e. code +
specs in a rather non-formal way).
FWIW, I'm personally involved in creating a de-facto standard for
on-line provisioning. Unlike HTML5 I have spent considerable time
investigating and listing "requirements" for such a facility with
on-line banking and e-government services for consumers/citizens as the
primary (but not only) targets. It has recently morphed into an
eight-pass (!) XML protocol which is an indication that a single HTML
tag probably doesn't fill the bill.
That <keygen> doesn't allow a bank to set PIN-code or PIN-code policy is
just a starter since this innocent-looking requirement actually has
major implications, even including core platform cryptography: To my
knowledge this is outside of CertEnroll/Xenroll as well since the
underlaying standard Windows CSPs do not support PIN settings or
PIN-policies, at least not in a consumer setup. The latter should be
interpreted as /multiple and independent issuers all having their own
ideas about policies/.
Sincerely,
Anders Rundgren
Senior Security Consultant
Adrian Bateman wrote:
On Saturday, August 08, 2009 12:50 AM, Anders Rundgren wrote:
http://lists.w3.org/Archives/Public/public-html/2009Aug/0389.html
However, that doesn't make Microsoft's solution ideal either because it
also fails to address provisioning in a way that is even remotely
comparable to what current card management software offers.
Hi Anders,
Thanks for the mail and the forward to the lists in the CC line.
I certainly wasn't trying to make a claim that Microsoft's solution is ideal - this
isn't my area of expertise so I wouldn't be able to judge that. I have forwarded your
mail on to a team better equipped to give feedback. My question was, based on the
feedback I'd heard, whether or not it made sense to standardize the old
<keygen> behaviour in HTML 5 when a more modern solution might be more
appropriate.
I will follow-up here when I get more feedback from the team that looks after
this area.
Regards,
Adrian.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
