The <keygen> element
Ian Hickson
I have now specified the <keygen> element in HTML5.
http://www.whatwg.org/specs/web-apps/current-work/#the-keygen-element
I would appreciate review by people who know what this stuff means, as
I'll be the first to admit not having any idea what I'm doing here.
On Mon, 1 Sep 2008, Anders Rundgren wrote:
>
> Among glaring omissions I would include:
> - No support for PINs and associated policies
> - No support for TPMs
> - No support for key management
I haven't added any new features to <keygen> at this time. I want to start
by making sure the spec as written matches reality.
On Tue, 6 Jan 2009, Bjoern Hoehrmann wrote:
>
> You don't say which documentation you read, but the original Netscape
> documentation was rather clear that the private component is stored in
> the local keystore, and from there you can of course use it when a site
> requests that you identify yourself with a certificate.
"Very clear" is not the terminology I would use. Hopefully the text of the
HTML5 spec now shows the level of detail I was looking for. (Hopefully it
is correct, too.)
On Tue, 6 Jan 2009, Yngve Nysaeter Pettersen wrote:
>
> The CA then uses the received data, along with other information, some
> possibly provided through other forms or Out-of-Band, and generates a
> X509 certificate. The certificate can, depending on CA infrastructure,
> be downloaded immediately as a result of the request, or later, with the
> content-type application/x-x509-user-cert (which can contain several
> certificate encapsulation formats, X509, Netscape Multicert, PKCS #7
> Signed Data, or a PKCS #7 with an encapsulated Signed data message). The
> client acts on the downloaded certificate by opening a certificate
> installation dialog. It is also possible to import such certificate
> manually. The certificate is installed together with the previously
> stored private key.
I haven't specified this bit, since it seems out of scope for HTML5.
> Submission formats:
>
> The default format, introduced by Netscape, is the SPKAC format, see the
> above link, and includes the public key and the Keygen challenge
> attribute, and is signed by the private key.
>
> The actual standardized format is PKCS #10, in form a more advanced and
> flexible version of SPKAC (it is the format used to request certificates
> for webservers), and I am not sure if this is now used by default in
> some clients. In Opera this format can be selected by using a
> type="pkcs10" attribute in the keygen tag.
I haven't added support for PKCS10 since it doesn't seem to actually add
anything to the feature set.
> My suggestion for the keygen tag is to add some functionality, such as
> the format selector:
>
> - A type attribute, or a better way to select the format. I think the
> specification should encourage PKCS10 as the default, but specifically
> require servers to accept SPKAC. Adding a format selector allows future
> enhancements with new formats in a backwards compatible fashion. I
> should think that a registration method should be defined for such
> formats (similar to IANA)
I think we should wait until we have some future enhancements before
adding new formats here.
> - An algorithm preference list, specifiying the key algorithms
> preferred by the server, in order of preference. In this case a keyword
> registration process should also be defined. Initial keywords should
> cover RSA, DSA and Elliptic Curves. As some methods may require
> parameters to be transferred to the client the syntax should cover such
> extensions, e.g "alg1;param1=x;param2=y,alg2", name of parameters should
> be selected by the specification for the algorithm, but two parameters
> should be defined: Minimum length (e.g. "min-len") and Maximum Length
> ("max-len") of the key that can be used to guide the client in what
> keylength it should selects (These should be suggestions, not absolute
> limits, at least for the maximum; the minimum should probably be
> considered a lower limit)
I haven't added this, because right now the only browser I could find
which supports more than one algorithm is Firefox, and it just has two
(RSA and ECs, as far as I could tell).
Going forward maybe we should add this to the keytype="" attribute,
though, making it a space separated list instead of an enumerated
attribute. For the parameters, maybe we can use different attributes for
the different types? e.g. dsaparams="" ecparams="" etc? Netscape 4 used to
have pqg="" for DSA (PQG is what DSA's parameters are called) so there is
some precedent there.
> It is also conceivable that the server should be able to specify which sites
> the certificate can be used for. A common usability problem with client
> certificates in SSL/TLS is selection of certificate, particularly when you
> have many certificates. A list of hostname:port pairs would probably be a good
> way to ease that (the SSL/TLS server can also specify which CAs it prefers to
> the certificate was issued by, but nobody is currently using that capability).
> A list of such sites provided at generation time might help the user in cases
> where the SSL/TLS server does not specify preferred CAs.
It seems like we should encourage people to use the existing feature you
mention rather than adding more features to do effectively the same thing.
> In the future it is also conceivable that such requests is to be made
> for keys stored on smartcards, so a source selector might be an idea,
> perhaps also with the capability to specify specific cards.
I'd rather we didn't specify this before it was ready to be a reality.
On Wed, 7 Jan 2009, Anders Rundgren wrote:
>
> I still maintain that <keygen> is too deficient to achieve standard
> status. Microsoft has a better system and will never implement <keygen>
> as it stands today.
That's possible, but I'm not sure what to do about it.
On Thu, 8 Jan 2009, Nelson B Bolyard wrote:
>
> This is documented at
> https://developer.mozilla.org/En/HTML/HTML_Extensions/KEYGEN_Tag
> which (I have just noticed) has not been updated with the info for ECC
> key generation. I will update that page soon.
I haven't added ECs to HTML5 since I couldn't find any documentation on it
(the above isn't updated yet). Also, I omitted DSA support which is
claimed to be supported on the above page, because as far as I can tell
nobody actually supports it.
> However, having said that, there are a number of known shortcomings of
> the keygen tag, which is why the Netscape and Mozilla browsers also
> support the generateCRMFRequest() method on the crypto object. See
> https://developer.mozilla.org/En/JavaScript_crypto/GenerateCRMFRequest
> for documentation on that method.
I haven't specified this method. I would recommend specifying the entire
"crypto" object in a separate working group, since it is orthogonal to the
rest of HTML (unlike <keygen>, which fits into the parser and form
submission and so on).
> Among the shortcomings are:
> a) SPKAC is non-standard, but is openly specified and has become a
> de facto standard and is now supported in numerous packages.
It's not non-standard any more, I guess!
> b) The tag has no way to specify whether the key is to be used for
> signing-only, or whether it can also be used for data/key encryption.
> c) The SPKAC format requires that the key be usable for signing, not
> useful for generating encryption-only keys.
> d) The tag has no provision for key escrow.
I haven't addressed these; I'm not sure how to for <keygen>. I suppose the
methods on the "crypto" object are a better long term solution for this,
if there is interest in formally specifying them (e.g. in the W3C Web Apps
working group).
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Ian Hickson
>
> Going one step further, if the <keygen> element does support multiple
> algorithms, would it be worthwhile to allow it to contain parameters,
> e.g. <param name="dsa" value="some-value">? On one hand, the set of
> widely-implemented algorithms seems small and fixing attribute names
> like dsaparams="" makes sense. But on the other, allowing params with
> arbitrary names seems like a more flexible approach.
Why would it be more flexible to use another element? Surely attributes
are just as flexible.
Anne van Kesteren
> On Tue, 7 Apr 2009, James Ide wrote:
>> Going one step further, if the <keygen> element does support multiple
>> algorithms, would it be worthwhile to allow it to contain parameters,
>> e.g. <param name="dsa" value="some-value">? On one hand, the set of
>> widely-implemented algorithms seems small and fixing attribute names
>> like dsaparams="" makes sense. But on the other, allowing params with
>> arbitrary names seems like a more flexible approach.
>
> Why would it be more flexible to use another element? Surely attributes
> are just as flexible.
More importantly, we cannot use an element because <keygen> parses just
like <input> and friends.
--
Anne van Kesteren
http://annevankesteren.nl/
Eddy Nigg
Among glaring omissions I would include: - No support for PINs and associated policies - No support for TPMs - No support for key managementI haven't added any new features to <keygen> at this time. I want to start by making sure the spec as written matches reality.
keygen
element represents
a key pair generator control. When the control's form is submitted, the
private key is stored in the local keystore, and the public key is
packaged and sent to the server."However the store can be any of the choice of the user, including smart cards. Not sure if this is covered under local keystore or if keystore was a reference to the software device only.
Adding parameters which adds additional control such a policies and forcing of smart cards (storage device) would be extremely helpful, once you get to add some features.
-- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: star...@startcom.org Blog: https://blog.startcom.org
Jean-Marc Desperrier
> Adding parameters which adds additional control such a policies and
> forcing of smart cards (storage device) would be extremely helpful, once
> you get to add some features.
No, the keygen tag is just too bad to be updated to something really useful.
crypto.generateCRMFRequest is a much better and more flexible solution,
but I'd like it to be usable to generate pkcs#10 request, which have
became the standard.
Eddy Nigg
However this doesn't follow any standard either to all of my knowledge.
At least the keygen tag is understood by most browsers. For the short
term it might be worth to consider keygen since it's also fairly easy.
Gervase Markham
> No, the keygen tag is just too bad to be updated to something really
> useful.
Then you need to persuade Hixie not to standardize it, otherwise people
will be using it for a long time :-)
Gerv
Anders Rundgren
It doesn't really matter if <keygen> gets standardized or not, it will be obviated
by other solutions anyway since it doesn't support even the most basic
security features needed, like giving the issuer an indication whether the
keys are stored in the file system, or are generated and stored in a secure container
like a smart card. The technique for doing that (container attestations) has been
known for a decade or more, and since trusted HW is already a part of high-end
mobile devices, it seems pretty short-sighted not to make use it.
Note: I don't think WHATWG should be blamed for this situation, it is rather
the result of a collective non-action by the PKI community.
BTW, <keygen> and its numerous cousins are actually MUCH more interesting
for mobile devices than for PCs, since for the latter we already have physical
token distribution (PIV/FIPS201), which I think is the main reason why the
state of browser key-generation isn't exactly high on the agenda. One may
argue that the SIM already does that but then you probably haven't tried it
in practice :-) Everything bound to SIMs is either locked-down or costly,
and often quite useless as well since SIMs typically have very limited capacity;
even the phone book is on-line these days!
Anders
Nelson B Bolyard
> I have now specified the <keygen> element in HTML5.
>
> http://www.whatwg.org/specs/web-apps/current-work/#the-keygen-element
>
> I would appreciate review by people who know what this stuff means, as
> I'll be the first to admit not having any idea what I'm doing here.
I apologize for replying to this thread so late.
Yngve Nysaeter Pettersen wrote:
>> Submission formats:
>>
>> The default format, introduced by Netscape, is the SPKAC format, see the
>> above link, and includes the public key and the Keygen challenge
>> attribute, and is signed by the private key.
>>
>> The actual standardized format is PKCS #10, in form a more advanced and
>> flexible version of SPKAC (it is the format used to request certificates
>> for webservers), and I am not sure if this is now used by default in
>> some clients. In Opera this format can be selected by using a
>> type="pkcs10" attribute in the keygen tag.
That's an interesting idea. But PKCS#10 is like a self-signed certificate.
It has a full-blown X.500 Directory Name in it, just like a certificate,
and the KEYGEN tag doesn't provide the input for that. I guess the browser
could prompt the user, perhaps using a form something like:
http://mxr.mozilla.org/security/source/security/nss/cmd/certcgi/main.html
But heaven help the user to fill that in! :-/
Also like a real certificate, a PKCS#10 certificate request may have
extensions. This is the way that a cert requester requests that particular
extensions be put into his cert. Again, the keygen tag has no way of
specifying these. (But the browser could use a form like:
http://mxr.mozilla.org/security/source/security/nss/cmd/certcgi/stnd_ext_form.html
There's one other problem with PKCS#10 (and SPKAC too) that I mentioned
before: it only works with public keys that can be used for signing.
If you have an "encryption only" key, you can't request a cert for it
with PKCS#10 because doing so requires generating a signature with it.
To solve these and other problems, an alternative protocol named CRMF
(the "Certificate Request Message Format") was created. Mozilla supports
that with the crypto.generateCRMFRequest method. If we're really going to
standardize something like a keygen tag, we should design it to be able
to do the things that can be done with crypto.generateCRMFRequest, too.
That should not be difficult. See
https://developer.mozilla.org/En/JavaScript_crypto/GenerateCRMFRequest
> I haven't added support for PKCS10 since it doesn't seem to actually add
> anything to the feature set.
Well, it potentially allows the user to request specific cert extensions,
but this is generally handled by other means in the form that the user is
filling in.
>> - An algorithm preference list, specifiying the key algorithms
>> preferred by the server, in order of preference. In this case a keyword
>> registration process should also be defined. Initial keywords should
>> cover RSA, DSA and Elliptic Curves. As some methods may require
>> parameters to be transferred to the client the syntax should cover such
>> extensions, e.g "alg1;param1=x;param2=y,alg2", name of parameters should
>> be selected by the specification for the algorithm, but two parameters
>> should be defined: Minimum length (e.g. "min-len") and Maximum Length
>> ("max-len") of the key that can be used to guide the client in what
>> keylength it should selects (These should be suggestions, not absolute
>> limits, at least for the maximum; the minimum should probably be
>> considered a lower limit)
Typically, a given CA only certifies certs with a single public key type.
If the user wants to choose a different key type, he probably needs to
choose a different CA (or at least a different CA page).
> I haven't added this, because right now the only browser I could find
> which supports more than one algorithm is Firefox, and it just has two
> (RSA and ECs, as far as I could tell).
And DSA.
>> It is also conceivable that the server should be able to specify which
>> sites the certificate can be used for. A common usability problem with
>> client certificates in SSL/TLS is selection of certificate,
>> particularly when you have many certificates. A list of hostname:port
>> pairs would probably be a good way to ease that (the SSL/TLS server can
>> also specify which CAs it prefers to the certificate was issued by, but
>> nobody is currently using that capability). A list of such sites
>> provided at generation time might help the user in cases where the
>> SSL/TLS server does not specify preferred CAs.
Sure, but this doesn't seem relevant to the keygen tag. It's just more
info that the CA can put into the page that contains the form that contains
the keygen tag.
>> In the future it is also conceivable that such requests is to be made
>> for keys stored on smartcards, so a source selector might be an idea,
>> perhaps also with the capability to specify specific cards.
Yes, and I think FF UI has that. It's a feature of the browser's UI, I
think, not of the keygen tag itself.
> On Thu, 8 Jan 2009, Nelson B Bolyard wrote:
>> This is documented at
>> https://developer.mozilla.org/En/HTML/HTML_Extensions/KEYGEN_Tag
>> which (I have just noticed) has not been updated with the info for ECC
>> key generation. I will update that page soon.
I apologize for not finishing that sooner. (I was waiting for a reply.)
I have just updated that page with all the presently relevant details
(AFAIK). I'm thinking about adding some examples of its use to that page.
> I haven't added ECs to HTML5 since I couldn't find any documentation on it
> (the above isn't updated yet). Also, I omitted DSA support which is
> claimed to be supported on the above page, because as far as I can tell
> nobody actually supports it.
It's not popular in the commercial world, but I thin a certain government
still likes it. :)
>> However, having said that, there are a number of known shortcomings of
>> the keygen tag, which is why the Netscape and Mozilla browsers also
>> support the generateCRMFRequest() method on the crypto object. [...]
>> Among the shortcomings are:
>> a) SPKAC is non-standard, but is openly specified and has become a
>> de facto standard and is now supported in numerous packages.
>
> It's not non-standard any more, I guess!
Well, your new element definition is a proposal at this point, right?
>> b) The tag has no way to specify whether the key is to be used for
>> signing-only, or whether it can also be used for data/key encryption.
>> c) The SPKAC format requires that the key be usable for signing, not
>> useful for generating encryption-only keys.
>> d) The tag has no provision for key escrow.
>
> I haven't addressed these; I'm not sure how to for <keygen>. I suppose the
> methods on the "crypto" object are a better long term solution for this,
> if there is interest in formally specifying them (e.g. in the W3C Web Apps
> working group).
I think that the KEYGEN tag's attributes could be extended to accept all
the arguments that can be passed to crypto.generateCRMFRequest, quite easily.
Which is more likely to be adopted as a cross browser standard?
A new html tag? or a new JavaScript object/method?
If I knew the answer to that question, that would influence my suggestions
for a direction here.
Anders Rundgren
A lot of things which I agree with but I would like to start in another end :-)
On-line provisioning of PKI is rather little used because the big users of
PKI (banks and governments), prefer using physical token distribution like
for PIV/CAC/eID.
What those large users have not bothered much with to date is how they are
going to use PKI in the most popular IT-device there is, the mobile phone.
IMHO the availability of trusted HW at a very small premium motivates a
completely new key-generation scheme, presumably based on TPM 1.2
or enhanced TPM-schemes.
Regarding the <keygen> tag itself, I personally don't see that such mechanisms
need any explicit links to an HTML page, at least none of the alternatives
including generateCRMFRequest and CertEnroll do, they are just APIs.
To give you an indication of that key-generation standards is not an easy
task, IETF's KEYPROV has been running for almost three years!
My own contribution to this field, KeyGen2, requires not less than six
message rounds compared to <keygen>'s three. Take a peek at the
[beta] XML Schema at: http://keycenter.webpki.org/resources
in case you are interested....
Anders Rundgren
http://mxr.mozilla.org/security/source/security/nss/cmd/certcgi/main.html
http://mxr.mozilla.org/security/source/security/nss/cmd/certcgi/stnd_ext_form.html
https://developer.mozilla.org/En/JavaScript_crypto/GenerateCRMFRequest
And DSA.
--
dev-tech-crypto mailing list
dev-tec...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Anders Rundgren
<snip>
>I think that the KEYGEN tag's attributes could be extended to accept all
>the arguments that can be passed to crypto.generateCRMFRequest, quite easily.
Yes, but the crypto.* functions could be extended to do things you would never
be able to do in a page mark-up language like capability discovery.
>Which is more likely to be adopted as a cross browser standard?
>A new html tag? or a new JavaScript object/method?
Probably none of these alternatives. All other efforts in this space (KEYPROV,
KMIP, SKSML, XKMS, KeyGen2, etc.) builds on a protocol concept
>If I knew the answer to that question, that would influence my suggestions
>for a direction here.
If Mozilla would like to contribute to progress, I think you should start in
another end, and see how protocols could be invoked in FireFox in a
generic fashion.
Based on WHATWG comments, this it is not really about standardization
but about documenting the current practice for key generation in the HTML
layer without comparing this to other ways of achieving the similar goals
including generateCRMFRequest. JavaScript is thus outside of the
scope AFAICT.
Anders
Anders Rundgren
Microsoft there is little point in elevating <keygen> to some kind
of standard since it will fail in the majority of cases.
Anyway, it seems that the security people are uninterested in
on-line key provisioning so you can go ahead without regrets :-)
As a web-CA writer I know that I will have to check User-Agent
etc. because this isn't going to be _the_ solution :-(
When you have added the missing 5-10 attributes including repeated
keys (!) to reach generateCRMFRequest level (easy according to Nelson...)
https://developer.mozilla.org/en/GenerateCRMFRequest
please give drop me a line :-)
Anders
----- Original Message -----
From: "Jonas Sicking" <jo...@sicking.cc>
To: "Anders Rundgren" <anders....@telia.com>
Cc: <wha...@lists.whatwg.org>; "Nelson B Bolyard" <nel...@bolyard.me>;
<dev-tec...@lists.mozilla.org>
Sent: Friday, April 17, 2009 23:16
Subject: Re: [whatwg] The <keygen> element
On Thu, Apr 16, 2009 at 9:22 PM, Anders Rundgren
<anders....@telia.com> wrote:
> "Nelson B Bolyard" wrote [to the WHATWG list]:
> Based on WHATWG comments, this it is not really about standardization
> but about documenting the current practice for key generation in the HTML
> layer without comparing this to other ways of achieving the similar goals
> including generateCRMFRequest. JavaScript is thus outside of the
> scope AFAICT.
The <keygen> discussion is not about creating a new standard, that is
correct. It is about standardizing current practices that are required
by *todays* browsers in order to be compatible with the web and thus
considered by users.
As for coming up with a new, better standard for accomplishing what
keygen was originally envisioned to do, way back when, I think this
would be a great idea.
Nothing is out of scope for such a new standard. However the
apropriate standards organization and working group should be used. So
for example if the new solution is a pure javascript API, then either
the webapps wg in w3c, or some security related standards org seems
more apropriate than whatwg.
If on the other hand a new HTML element is proposed, then this list
seems like a fine place for such a discussion.
Hope that makes sense?
/ Jonas
Kyle Hamilton
>> Submission formats:
>>
>> The default format, introduced by Netscape, is the SPKAC format, see the
>> above link, and includes the public key and the Keygen challenge
>> attribute, and is signed by the private key.
>>
>> The actual standardized format is PKCS #10, in form a more advanced and
>> flexible version of SPKAC (it is the format used to request certificates
>> for webservers), and I am not sure if this is now used by default in
>> some clients. In Opera this format can be selected by using a
>> type="pkcs10" attribute in the keygen tag.
>
> anything to the feature set.
...except one marketing checkbox: "Compliant with the Public Key
Cryptography Standards".
>> - An algorithm preference list, specifiying the key algorithms
>> preferred by the server, in order of preference. In this case a keyword
>> registration process should also be defined. Initial keywords should
>> cover RSA, DSA and Elliptic Curves. As some methods may require
>> parameters to be transferred to the client the syntax should cover such
>> extensions, e.g "alg1;param1=x;param2=y,alg2", name of parameters should
>> be selected by the specification for the algorithm, but two parameters
>> should be defined: Minimum length (e.g. "min-len") and Maximum Length
>> ("max-len") of the key that can be used to guide the client in what
>> keylength it should selects (These should be suggestions, not absolute
>> limits, at least for the maximum; the minimum should probably be
>> considered a lower limit)
>
> I haven't added this, because right now the only browser I could find
> which supports more than one algorithm is Firefox, and it just has two
> (RSA and ECs, as far as I could tell).
RSA and DH/DSA are in almost everything. Besides, insisting that the
browser itself hold the keys is counterproductive.
>> It is also conceivable that the server should be able to specify which sites
>> the certificate can be used for. A common usability problem with client
>> certificates in SSL/TLS is selection of certificate, particularly when you
>> have many certificates. A list of hostname:port pairs would probably be a good
>> way to ease that (the SSL/TLS server can also specify which CAs it prefers to
>> the certificate was issued by, but nobody is currently using that capability).
>> A list of such sites provided at generation time might help the user in cases
>> where the SSL/TLS server does not specify preferred CAs.
>
> It seems like we should encourage people to use the existing feature you
> mention rather than adding more features to do effectively the same thing.
The "existing feature" is a list of external authorities that the site
trusts, rather than necessarily showing "all".
>> In the future it is also conceivable that such requests is to be made
>> for keys stored on smartcards, so a source selector might be an idea,
>> perhaps also with the capability to specify specific cards.
>
> I'd rather we didn't specify this before it was ready to be a reality.
I'd rather it be specified before it's ready to be a reality, to
provide marketing pressure for "hey, we've already got support for
it". Otherwise, it's a chicken&egg problem.
-Kyle H
Anders Rundgren
they just "inherited" something they will probably regret :--)
Kyle wrote:
>Besides, insisting that the
>browser itself hold the keys is counterproductive.
That's not how <keygen> is implemented in FireFox AFAICT.
Unfortunately this part is also non-trivial. If you look at Microsoft-
solutions you typically have to select from a list of cryptographic
service providers which is total BS for consumers.
Here we need a standard where the issuer has a way signaling
that it wants to use a particular container type.
Ideas are welcome since this (of course) is a part of KeyGen2.
Anders
Martin Paljak
On 18.04.2009, at 10:28, Kyle Hamilton wrote:
>>> It is also conceivable that the server should be able to specify
>>> which sites
>>> the certificate can be used for. A common usability problem with
>>> client
>>> certificates in SSL/TLS is selection of certificate, particularly
>>> when you
>>> have many certificates. A list of hostname:port pairs would
>>> probably be a good
>>> way to ease that (the SSL/TLS server can also specify which CAs it
>>> prefers to
>>> the certificate was issued by, but nobody is currently using that
>>> capability).
>>> A list of such sites provided at generation time might help the
>>> user in cases
>>> where the SSL/TLS server does not specify preferred CAs.
>>
>> It seems like we should encourage people to use the existing
>> feature you
>> mention rather than adding more features to do effectively the same
>> thing.
>
> The "existing feature" is a list of external authorities that the site
> trusts, rather than necessarily showing "all".
FYI, Apple has made it virtually impossible to use smart cards with
Safari because of *requiring* such configuration on the client side
(host:port configuration for every certificate for every site where
you want to use it).
With Firefox I can configure my client once and my wife can use her
card in the same account by just changing the card in the reader. With
Apple, I can't do it as one Mac user account can have only one
certificate defined for a website profile. It might be a "privacy
enhancing" but it sure is usability busting feature.
For me, CA list from the server and a "common sense" implementation by
the client is pretty OK for SSL.
--
Martin Paljak
http://martin.paljak.pri.ee
+372.515.6495
Nelson B Bolyard
> FYI, Apple has made it virtually impossible to use smart cards with
> Safari because of *requiring* such configuration on the client side
> (host:port configuration for every certificate for every site where
> you want to use it).
>
> With Firefox I can configure my client once and my wife can use her
> card in the same account by just changing the card in the reader.
>
> With Apple, I can't do it as one Mac user account can have only one
> certificate defined for a website profile. It might be a "privacy
> enhancing" but it sure is usability busting feature.
Martin, please tell us about your uses of smart cards. Some info I'd
like to know include:
- what kind of entity issued your smart card?
government?
bank
post office?
employer?
other?
Do you and your wife have cards from the same issuers? or different?
If different, what kind of entity issued her card?
How long have you had your cards?
How many different sites do your cards work with?
1? 2? 5? 10? etc?
How many times a week do you actually use your card for authenticating
to a web site?
Do you also use your card for other purposes, such as signed email?
TIA
Anders Rundgren
Smart cards are essentially never provisioned using <keygen> except
in very local instances such as within an organization.
Why is that? Because it doesn't work. None of the makers of
smart cards have invested a single cent in a consumer-oriented
on-line provisioning scheme. And if they ever would, it would be
entirely proprietary.
Anders
----- Original Message -----
From: "Nelson B Bolyard" <nel...@bolyard.me>
To: "mozilla's crypto code discussion list" <dev-tec...@lists.mozilla.org>
Sent: Saturday, April 18, 2009 10:04
Subject: Re: The <keygen> element
TIA
Eddy Nigg
> On 04/18/2009 11:21 AM, Anders Rundgren:
>> Hi Nelson,
>>
>> Smart cards are essentially never provisioned using<keygen> except
>> in very local instances such as within an organization.
>>
>> Why is that? Because it doesn't work.
I'm not sure what you mean with "it doesn't work". We are using smart
cards almost everywhere without a problem. We use keygen for generating
the keys on the smart card. It works every time...perhaps you can
explain where exactly the problem is?
>
>> None of the makers of
>> smart cards have invested a single cent in a consumer-oriented
>> on-line provisioning scheme. And if they ever would, it would be
>> entirely proprietary.
>
Yes, unfortunately the proprietary drivers and PKCS11 modules work a but
better. But I had success using both open and closed source...as a
matter of fact, some proprietary solutions use also open source modules
(on Linux and Mac) in conjunction with theirs.
Anders Rundgren
>> in very local instances such as within an organization.
>
>> Why is that? Because it doesn't work.
>I'm not what you mean "it doesn't work". We are using smart cards almost
>everywhere without a problem. We use keygen for generating the keys on
>the smart card. It works every time...perhaps you can explain where
>exactly the problem is?
Before going into details you/we need to set the scenery otherwise
we don't know what we are discussing.
Q: Why use smart cards?
A: Because they are conveniant. Wrong answer; issuers don't care about
end-users, they care about protecting their business and enforcing their policy.
Q: How can an issuer know that the end-user is actually using a smart card?
A: It cannot, smart cards were never designed for "open" on-line provision.
Q: Can you host a multitude of keys in a smart card?
A: No, smart cards are typically designed for a single provider.
Q: Can you buy a card from anywhere and start provisioning it?
A: Yes, if you are expert, otherwise not.
etc etc etc
Anders
Michael Ströder
> "Nelson B Bolyard" wrote [to the WHATWG list]:
>
> <snip>
>
>> I think that the KEYGEN tag's attributes could be extended to accept all
>> the arguments that can be passed to crypto.generateCRMFRequest, quite easily.
>
> Yes, but the crypto.* functions could be extended to do things you would never
> be able to do in a page mark-up language like capability discovery.
I don't see any reason why the browser should not be capable to present
<keygen> as a list for choosing one of the available PKCS#11- or
CAPI-based key stores and the wanted key length.
>> Which is more likely to be adopted as a cross browser standard?
>> A new html tag? or a new JavaScript object/method?
>
> Probably none of these alternatives. All other efforts in this space (KEYPROV,
> KMIP, SKSML, XKMS, KeyGen2, etc.) builds on a protocol concept
For security reasons I'd strongly prefer something which is rather
hard-coded in the browser and not a protocol between the enrollment web
app and the browser's key store.
> If Mozilla would like to contribute to progress, I think you should start in
> another end, and see how protocols could be invoked in FireFox in a
> generic fashion.
It always rings some bells regarding generic protocols. The more
flexible they are the harder it is for implementors to get them securely
implemented.
One of the real caveats of PKIX is the complexity.
Ciao, Michael.
Michael Ströder
> Q: Why use smart cards?
> A: Because they are conveniant. Wrong answer; issuers don't care about
> end-users, they care about protecting their business and enforcing their policy.
E.g. (corporate) CAs do care about end-users. Otherwise costs in the
helpdesk are rising.
> Q: How can an issuer know that the end-user is actually using a smart card?
> A: It cannot, smart cards were never designed for "open" on-line provision.
It all depends on the smartcard software and how it interacts with the
enrollment software.
> Q: Can you host a multitude of keys in a smart card?
> A: No, smart cards are typically designed for a single provider.
Nonsense!
> Q: Can you buy a card from anywhere and start provisioning it?
> A: Yes, if you are expert, otherwise not.
We often debated that cert enrollment itself is complicated even if just
using a file-based key store. But nobody came up with a really good idea
how to solve that issue. Please, don't raise the Skype-is-so-wonderful
discussion again.
Ciao, Michael.
Anders Rundgren
>> A: It cannot, smart cards were never designed for "open" on-line provision.
>It all depends on the smartcard software and how it interacts with the
>enrollment software.
And if we stick to the initial subject, i.e. <keygen>?
Anders
Michael Ströder
Yes, so what?
For Mozilla prodcuts it depends how well the PKCS#11 module for a
certain smartcard is implemented. When looking at the OpenSC mailing
list much of the issues are with different smartcard file system
layouts. But that's a level below <keygen>.
Ciao, Michael.
Eddy Nigg
> I don't see any reason why the browser should not be capable to present
> <keygen> as a list for choosing one of the available PKCS#11- or
> CAPI-based key stores and the wanted key length.
>
Me either...
> For security reasons I'd strongly prefer something which is rather
> hard-coded in the browser and not a protocol between the enrollment web
> app and the browser's key store.
>
It's actually good point Michael is making here.
Anders Rundgren
>>>> A: It cannot, smart cards were never designed for "open" on-line provision.
>>> It all depends on the smartcard software and how it interacts with the
>>> enrollment software.
>> And if we stick to the initial subject, i.e. <keygen>?
>For Mozilla prodcuts it depends how well the PKCS#11 module for a
>certain smartcard is implemented. When looking at the OpenSC mailing
>list much of the issues are with different smartcard file system
>layouts. But that's a level below <keygen>.
Maybe you could enlighten us a bit on how an issuer using <keygen>
(which in Mozilla's implementation means connecting to a PKCS #11 driver),
in some way can be assured that the user really is using a smart card rather
than a file-based key-store?
Anders
Michael Ströder
Oh, come on! I know it's currently not possible.
And in opposite to you IMO it's more the user's interest to use a secure
key store.
Furthermore I don't see a reason why there can't be an additional HTML
attribute for <keygen> which lists the names of acceptable PKCS#11
and/or CAPI key stores. I'd vote against an abstract "smartcard bit" or
"HSM bit" anyway. If a CA wants to make a provision about which key
store to use it should explicitly specify acceptable key stores by name.
Because these names e.g. registered with IANA can be explicitly written
into a CPS.
Ciao, Michael.
Anders Rundgren
>> (which in Mozilla's implementation means connecting to a PKCS #11 driver),
>> in some way can be assured that the user really is using a smart card rather
>> than a file-based key-store?
>Oh, come on! I know it's currently not possible.
Good. We agree on one thing at least :-)
>And in opposite to you IMO it's more the user's interest to use a secure
>key store.
So you mean that banks and governments run their eID/PIV programs
because their customers and citizens have asked for it?
>Furthermore I don't see a reason why there can't be an additional HTML
>attribute for <keygen> which lists the names of acceptable PKCS#11
>and/or CAPI key stores.
You mean that issuers must know the name of their client's cryptographic drivers?
You mean that consumers should understand this?
You mean that issuers in spite of having a "standard-to-be" method like <keygen>
*still* must know if client's are on msie, firefox, mac etc?
> I'd vote against an abstract "smartcard bit" or "HSM bit" anyway.
Me too since this thing is not resistant to malware and thus is no guarantee.
>If a CA wants to make a provision about which key
>store to use it should explicitly specify acceptable key stores by name.
>Because these names e.g. registered with IANA can be explicitly written
>into a CPS.
"Microsoft Enhanced Cryptographic Service Provider" is registered by IANA?
Don't take it personal, but browser-PKI is totally lame. It is a 15-year old
Netscape "hack" that is since long overdue.
Anders
Martin Paljak
> Martin, please tell us about your uses of smart cards.
Personally I use different smart cards for different purposes but I
assume you're more interested in usages related to an average user.
> Some info I'd like to know include:
> - what kind of entity issued your smart card?
government, Estonian eID
> Do you and your wife have cards from the same issuers? or different?
> If different, what kind of entity issued her card?
Same
> How long have you had your cards?
Me - Since 2003 when they were introduced (I have changed cards and
updated certificates of course, I think my current card is my 3rd or
fourth, and I've re-generated my keys and certificates on two cards.
You can only do it once during the lifetime of the card.) My wife -
since 2005 I guess.
> How many different sites do your cards work with?
> 1? 2? 5? 10? etc?
Many Estonian websites use it (banking, taxes, self-services of
commodity service providers (telco, electricity etc), e-voting,
e-school, e-government portal ...) I guess the number might be around
50..100 "heavy-weight" (public service) websites these days. As in
real life SSL does not fulfill all the promises of password-less web
(I can't use my client certificates on websites which have not been
configured for it, so on 99.999% of SSL enabled websites can not use
my card), openid.ee OpenID provider allows me to use my card for
authentication on any OpenID enabled website in the world. Those do
not count as SSL-enabled sites, but there are thousands of them out
there.
> How many times a week do you actually use your card for authenticating
> to a web site?
I'm a heavyweight user so I use it almost daily. My wife uses it it
maybe a few times a month, when she needs to do some banking or
related activities (which she does not do usually).
Estonia is the forerunner in internet banking and 80% of users log
into their bank at least once a week. Not all of them use eID cards
for authentication, but people using eID still count in tens of
thousands (<200k though). Those who use eID for online authentication
I believe use it a few times a week.
> Do you also use your card for other purposes, such as signed email?
Sure, electronic signatures (in XAdES format). Almost all contracts I
sign as a private person or for my company are in the form of a PDF
and digital signatures (not PDF signatures, but PDF signatures in
XAdES envelopes). Documents are forwarded in e-mail but not in S/MIME,
which has no practical use in Estonia other than e-mail encryption for
transport. S/MIME signatures do not count as legally binding
signatures. Also bank transactions are signed (There are two
certificates and two PIN codes on the card, one for authentication and
one for non-repudiation/digital signatures)
There was a huge mess about two years ago when FF tried to use
non-repudiation keys without SSL client certificate extensions for SSL
client authentication. The workaround is still in use these days - a
special PKCS#11 module for Firefox which only exposes the
authentication certificate. This is because FF still tries to use the
certificate where the key has non-repudiation KU and no EKU for SSL
client authentication from the same CA even if there is a certificate
with client authentication EKU.
So even if Apple is bad, there's a bad apple in FF garden as well :)
In the end I gave up the fight in Bugzilla as there was no consensus
on how the client should behave and what is a "vendor glitch" and what
is not...
--
Martin Paljak
mar...@paljak.pri.ee
http://martin.paljak.pri.ee
GSM:+3725156495
Nelson B Bolyard
Thanks for your very informative and useful email. There was a lot of
good information in there. It's good to see how PKI and smart cards are
being taken up in the world, even if at the present it is limited to a
few nations.
/Nelson
Jonas Sicking
Anders Rundgren
How about Smart Cards and <keygen>?
Is Michael Stroder on the right track???
BTW, it is essentially only in the US consumer PKI is
not already in various states of rollout.
Maybe of some interest:
http://www.ietf.org/mail-archive/web/keyprov/current/msg00753.html
Anders
----- Original Message -----
From: "Nelson B Bolyard" <nel...@bolyard.me>
To: "mozilla's crypto code discussion list" <dev-tec...@lists.mozilla.org>
Sent: Saturday, April 18, 2009 21:23
Subject: Re: The <keygen> element
Martin
/Nelson
Michael Ströder
>> And in opposite to you IMO it's more the user's interest to use a secure
>> key store.
>
> So you mean that banks and governments run their eID/PIV programs
> because their customers and citizens have asked for it?
Yes, here in Germany people do care about security of on-line banking.
Government failed to provide good services (and still fails despite some
buzz coming recently through the news.)
>> Furthermore I don't see a reason why there can't be an additional HTML
>> attribute for <keygen> which lists the names of acceptable PKCS#11
>> and/or CAPI key stores.
>
> You mean that issuers must know the name of their client's cryptographic drivers?
Yes. The overall security does not only depend on whether a private key
is stored on a smartcard or not. It also depends on how the smartcard
drivers interacts with the key store.
> You mean that consumers should understand this?
More or less. Depends on the enrollment and the provisions the CA makes.
Note that you can already mandate with XENROLL.DLL which CAPI key store
to use without the user noticing it.
> You mean that issuers in spite of having a "standard-to-be" method like <keygen>
> *still* must know if client's are on msie, firefox, mac etc?
No. My idea would be to have a namespace for key stores registered with
IANA which could be used in a multi-valued attribute in <keygen> to
specify the acceptable key stores during enrollment.
>> I'd vote against an abstract "smartcard bit" or "HSM bit" anyway.
>
> Me too since this thing is not resistant to malware and thus is no guarantee.
>
>> If a CA wants to make a provision about which key
>> store to use it should explicitly specify acceptable key stores by name.
>> Because these names e.g. registered with IANA can be explicitly written
>> into a CPS.
>
> "Microsoft Enhanced Cryptographic Service Provider" is registered by IANA?
No, it's not. It could be though.
> Don't take it personal,
Don't worry, I won't. ;-)
> but browser-PKI is totally lame. It is a 15-year old
> Netscape "hack" that is since long overdue.
Well, I still disagree.
And if you want a really detailed client-side smartcard provisiong you
could already implement this with a Java applet doing exactly what you want.
<keygen> is not one of the main problems.
Ciao, Michael.
Anders Rundgren
>could already implement this with a Java applet doing exactly what you want.
The reason why I brought this to begin with is because this is what in fact
the *majority* of big PKI deployments (0.5M and up) using "soft certificates" do.
><keygen> is not one of the main problems.
I'm pretty sure that <keygen> will die in phones, where on-line provisioning
is not an esoteric "workaround", but rather more or less a *prerequisite*.
What's more. A "<keygen>++" would help much either. You need a "P11++"
and a "Card++" as well. Yes, you need "requirements", something the
HTML5 WG apparantly do not consider an issue :-)
Would you and Nelson like to bet on this?
I mean, could we come back in 5 years and see if <keygen> actually "lives"?
I plan to "kill" it next year already so I'm interested :-)
Anders
Eddy Nigg
> I have now specified the<keygen> element in HTML5.
>
> http://www.whatwg.org/specs/web-apps/current-work/#the-keygen-element
>
> I would appreciate review by people who know what this stuff means, as
> I'll be the first to admit not having any idea what I'm doing here.
>
>
Hixie, could you comment on bug 495876? Are there already some
precedences by other browser vendors?
(https://bugzilla.mozilla.org/show_bug.cgi?id=495876)
Georgi Guninski
> On 04/07/2009 06:37 AM, Ian Hickson:
>> I have now specified the<keygen> element in HTML5.
>>
>> http://www.whatwg.org/specs/web-apps/current-work/#the-keygen-element
>>
>> I would appreciate review by people who know what this stuff means, as
>> I'll be the first to admit not having any idea what I'm doing here.
>>
>>
the standard should make it clear how the signed response is handled.
currently, after you visit a malicious page the only thing you see is:
"your certificate is installed [OK]"
the certificate can be issued to whatever name the attacker choses.
if an attacker can force a weak private key which is later broken, it
can be self signed and stored on the poor user's machine - this is not
much fun anymore.
i think the standard should write something like:
after receiving the certificate, the user must be given an option to
examine it and to ignore it.
there is a bugzilla bug exactly about it - can't remember the # ATM
Anders Rundgren
tell the CA if the key is stored on the hard-disk or on a smart card and
if there is PIN protection etc. From a practical point-of-view this means
that smart cards are out-of-scope for <keygen>.
Real card provisioning systems therefore typically cost $10 000 and up
and mostly only run on Windows. They usually come with professional
services as well :-)
Now, over to your concerns....
>the standard should make it clear how the signed response is handled.
Yes.
>currently, after you visit a malicious page the only thing you see is:
>"your certificate is installed [OK]"
>the certificate can be issued to whatever name the attacker choses.
>if an attacker can force a weak private key which is later broken, it
>can be self signed and stored on the poor user's machine - this is not
>much fun anymore.
I think you need to analyze this a bit more. It is the RP (relying party)
that trusts the certificate and the CA who issues it. If the key is weak (short?)
the CA (who has a policy) will presumably reject the request. If the key is
self-signed the RP will reject it (unless it is S/MIME which is very difficult
to deal with anyway since you need to "trust" an infinite number of CAs
but that's not a <keygen> issue).
>i think the standard should write something like:
>after receiving the certificate, the user must be given an option to
>examine it and to ignore it.
The user should IMO have an option to abort a key generation request
because such opens for (pretty lame) attacks on key db space.
The rest is in the hands of RPs and CAs. CAs that produce bogus
certificates do not constitute of a threat to end-users but maybe to
RPs but that's out-of-scope for most users. It is similar to credit-cards;
you don't have to verify the validity of your VISA card, that's an
issue for merchants and payment networks. If users want to study
certificates, the existing browser GUIs already offer this option.
If you pay money for a bogus certificate that's bad but unfortunately
PKI is far too complex for human verification so there is no cure.
It is BTW no different to buying anything else on the Internet.
Anders
Georgi Guninski
i *did* install certificates in a test scenario, so my self signed
openssl setup is without doubt CA to the users - no matter if it
verifies up to the root chain.
the point is i don't want certs in *my* keystore with CN="joro the terrorist"
signed by whatever CA - FYI i trust the root CAs as much as i trust
viagra spammers.
about the weak key: the idea is to force a <keygen> to generate weak
key that is sent to attacker. the attacker cracks the private key by
only using the public key and
returns self signed cert to the luser - the luser doesn't realize this.
Ian Hickson
> Yngve Nysaeter Pettersen wrote:
> >>
> >> The default format, introduced by Netscape, is the SPKAC format, see
> >> the above link, and includes the public key and the Keygen challenge
> >> attribute, and is signed by the private key.
> >>
> >> The actual standardized format is PKCS #10, in form a more advanced
> >> and flexible version of SPKAC (it is the format used to request
> >> certificates for webservers), and I am not sure if this is now used
> >> by default in some clients. In Opera this format can be selected by
> >> using a type="pkcs10" attribute in the keygen tag.
>
> certificate. It has a full-blown X.500 Directory Name in it, just like a
> certificate, and the KEYGEN tag doesn't provide the input for that. I
> guess the browser could prompt the user, perhaps using a form something
> like:
>
> http://mxr.mozilla.org/security/source/security/nss/cmd/certcgi/main.html
>
> But heaven help the user to fill that in! :-/
>
> Also like a real certificate, a PKCS#10 certificate request may have
> extensions. This is the way that a cert requester requests that
> particular extensions be put into his cert. Again, the keygen tag has
> no way of specifying these. But the browser could use a form like:
>
> http://mxr.mozilla.org/security/source/security/nss/cmd/certcgi/stnd_ext_form.html
>
> There's one other problem with PKCS#10 (and SPKAC too) that I mentioned
> before: it only works with public keys that can be used for signing. If
> you have an "encryption only" key, you can't request a cert for it with
> PKCS#10 because doing so requires generating a signature with it.
>
> To solve these and other problems, an alternative protocol named CRMF
> (the "Certificate Request Message Format") was created. Mozilla
> supports that with the crypto.generateCRMFRequest method. If we're
> really going to standardize something like a keygen tag, we should
> design it to be able to do the things that can be done with
> crypto.generateCRMFRequest, too. That should not be difficult. See
>
> https://developer.mozilla.org/En/JavaScript_crypto/GenerateCRMFRequest
I agree that standardising this would be a good idea; I recommend
approaching the public-webapps WG at the W3C to do this.
> > I haven't added this, because right now the only browser I could find
> > which supports more than one algorithm is Firefox, and it just has two
> > (RSA and ECs, as far as I could tell).
>
> And DSA.
The DSA code doesn't appear to be hooked up.
> > I haven't added ECs to HTML5 since I couldn't find any documentation
> > on it (the above isn't updated yet). Also, I omitted DSA support which
> > is claimed to be supported on the above page, because as far as I can
> > tell nobody actually supports it.
>
> It's not popular in the commercial world, but I think a certain
> government still likes it. :)
I'm definitely not adding features to HTML5 for a single vendor, even if
that vendor has an army.
> Which is more likely to be adopted as a cross browser standard? A new
> html tag? or a new JavaScript object/method?
It would presumably depend on how it is to be used. If it's for form
submission, then an element would make more sense. If it's for
applications, then an API would be better.
On Mon, 13 Apr 2009, Anders Rundgren wrote:
>
> On-line provisioning of PKI is rather little used because the big users
> of PKI (banks and governments), prefer using physical token distribution
> like for PIV/CAC/eID.
>
> What those large users have not bothered much with to date is how they
> are going to use PKI in the most popular IT-device there is, the mobile
> phone. IMHO the availability of trusted HW at a very small premium
> motivates a completely new key-generation scheme, presumably based on
> TPM 1.2 or enhanced TPM-schemes.
>
> Regarding the <keygen> tag itself, I personally don't see that such
> mechanisms need any explicit links to an HTML page, at least none of the
> alternatives including generateCRMFRequest and CertEnroll do, they are
> just APIs.
>
> To give you an indication of that key-generation standards is not an
> easy task, IETF's KEYPROV has been running for almost three years!
>
> My own contribution to this field, KeyGen2, requires not less than six
> message rounds compared to <keygen>'s three. Take a peek at the [beta]
> XML Schema at: http://keycenter.webpki.org/resources in case you are
> interested....
Thanks for the info!
On Fri, 17 Apr 2009, Anders Rundgren wrote:
>
> I understand what you are saying, but without a "buy-in" from Microsoft
> there is little point in elevating <keygen> to some kind of standard
> since it will fail in the majority of cases.
Even if IE's market share stops dropping (which it shows no signs of
doing), I believe that getting interop amongst three browser vendors is an
important enough goal that it is still worth standardising even if
Microsoft never implement <keygen>.
Cheers,
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Jonas Sicking
>> Which is more likely to be adopted as a cross browser standard? A new
>> html tag? or a new JavaScript object/method?
>
> It would presumably depend on how it is to be used. If it's for form
> submission, then an element would make more sense. If it's for
> applications, then an API would be better.
As a browser developer I'd say that the likeliness something is
implemented depends heavily on how useful it is perceived to be, and
somewhat on how hard it is to implement.
If a feature doesn't seem very useful, I wouldn't advocate adding it
no matter how easy it is to implement. On the other hand, if a feature
is hard enough to implement that we can implement two other features,
that add up to more usefulness, then implementing those two features
seem to serve the web more.
All of this is very simplified of course, and highly subjective.
But neither a new element or a new JS object is hard to implement in
and of itself. So use the best solution for the task, that's the most
likely to yield a useful feature.
/ Jonas
Anders Rundgren
are provisioned with <keygen>. There are two reasons for that:
1. <keygen> does not support the information/processes involved
2. current smart cards are unsuitable for on-line provisioning by end-users
Due to this smart cards are generally always provisioned by card
administrators using highly proprietary and expensive software,
mostly only running on Windows.
There's no problem to fix in other words!
Anders
Eddy Nigg
> A guesstimate is that less than 1 out of 10 000 smart cards actually
> are provisioned with <keygen>.
Can you backup your statement with facts please?
Anders Rundgren
>> A guesstimate is that less than 1 out of 10 000 smart cards actually
>> are provisioned with <keygen>.
> Can you backup your statement with facts please?
I wrote "guesstimate". However, if we exclude a limited number
of security nerds (that mainly produce cards for themselves), and
concentrate on REAL smart card deployments; you got about a
million eID cards in Estonia, None of these were provisioned using
<keygen>; they were presumably produced in some kind of card factory.
For enterprises most of us know that Windows is the de-facto standard
so even if they had actually used end-user provisioning, it would have been
through Xenroll and CSPs rather than with <keygen> and PKCS #11.
But why in the world would anybody bother with <keygen>, Xenroll,
or generateCRMFRequest, for provisioning smart cards when:
- you still have to do 80% of the gory stuff (formatting, PIN, PUK)
in a Windows-only proprieterary card management application?
- all bets are off regarding where keys actually were created?
That is, <keygen> is left for "soft certificates" that by default are not
even PIN-protected. In my vocabulary that spells "insignificant".
Anders
--
Regards
--