>And if you want a really detailed client-side smartcard provision you
>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 certifica
Anders Rundgren wrote:
>> 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
That was a very "politically correct" message.
How about Smart Cards and ?
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/msg0075
On Thu, Apr 16, 2009 at 9:22 PM, Anders Rundgren
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
Martin
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
--
dev-tech-crypto mailing list
dev-tech-crypto@lists
On Sat, Apr 18, 2009 at 11:04 AM, Nelson B Bolyard wrote:
> 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:
> - wha
>> Maybe you could enlighten us a bit on how an issuer using
>> (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 possib
Anders Rundgren wrote:
> 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 so
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.
>> And if we stick to the initial
On 04/18/2009 03:00 PM, Michael Ströder:
I don't see any reason why the browser should not be capable to present
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
Anders Rundgren wrote:
>>> 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.
>
> And if we
>> 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.
And if we stick to the initial subject, i.e.
Anders Rundgren wrote:
> 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.
Anders Rundgren wrote:
> "Nelson B Bolyard" wrote [to the WHATWG list]:
>
>
>
>> 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
>> Smart cards are essentially never provisioned using except
>> 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 generati
On 04/18/2009 11:21 AM, Anders Rundgren:
Hi Nelson,
Smart cards are essentially never provisioned using 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
On 04/18/2009 11:21 AM, Anders Rundgren:
Hi Nelson,
Smart cards are essentially never provisioned using except
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 w
Hi Nelson,
Smart cards are essentially never provisioned using 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 eve
Martin Paljak wrote, On 2009-04-18 00:51 PDT:
> 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 Fir
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 certificat
Dropping WHATWG, they do not really work with crypto,
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 is implemented in FireFox AFAICT.
Unfortunately this part is also non
On Mon, Apr 6, 2009 at 8:37 PM, Ian Hickson 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
22 matches
Mail list logo
