- Original Message -
From: "Eddy Nigg"
Newsgroups: mozilla.dev.tech.crypto
To:
Sent: Thursday, June 04, 2009 20:52
Subject: Re: Smart cards and the element
On 06/04/2009 09:40 PM, Anders Rundgren:
> A guesstimate is that less than 1 out of 10 000 smart cards actually
>
On 06/04/2009 09:40 PM, Anders Rundgren:
A guesstimate is that less than 1 out of 10 000 smart cards actually
are provisioned with .
Can you backup your statement with facts please?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog: https://blog.startcom.org
A guesstimate is that less than 1 out of 10 000 smart cards actually
are provisioned with . There are two reasons for that:
1. 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 general
On Wed, Jun 3, 2009 at 3:31 PM, Ian Hickson wrote:
>> 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.
On Sun, 12 Apr 2009, Nelson B Bolyard wrote:
> 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 a
let's clarify what is CA from the user's point of view.
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"
A genuine problem is that and its cousins cannot actually
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 .
Real card provisioning systems therefore typically
On Tue, Jun 02, 2009 at 01:59:47AM +0300, Eddy Nigg wrote:
> On 04/07/2009 06:37 AM, Ian Hickson:
>> I have now specified the element in HTML5.
>>
>> http://www.whatwg.org/specs/web-apps/current-work/#the-keygen-element
>>
>> I would appreciate review by peop
On 04/07/2009 06:37 AM, Ian Hickson:
I have now specified the 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
>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
ov/current/msg00753.html
Anders
- Original Message -
From: "Nelson B Bolyard"
To: "mozilla's crypto code discussion list"
Sent: Saturday, April 18, 2009 21:23
Subject: Re: The element
Martin
Thanks for your very informative and useful email. There was a lot of
go
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
they ever would, it would be
entirely proprietary.
Anders
- Original Message -
From: "Nelson B Bolyard"
To: "mozilla's crypto code discussion list"
Sent: Saturday, April 18, 2009 10:04
Subject: Re: The element
Martin Paljak wrote, On 2009-04-18 00:51 PDT:
>
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
per.mozilla.org/en/GenerateCRMFRequest
please give drop me a line :-)
Anders
- Original Message -
From: "Jonas Sicking"
To: "Anders Rundgren"
Cc: ; "Nelson B Bolyard" ;
Sent: Friday, April 17, 2009 23:16
Subject: Re: [whatwg] The element
On Thu, Ap
"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 things you would never
be able to do in
- Original Message -
From: "Nelson B Bolyard"
To: "Ian Hickson"
Cc: ;
Sent: Monday, April 13, 2009 02:18
Subject: Re: The element
Ian Hickson wrote, On 2009-04-06 20:37 PDT:
> I have now specified the element in HTML5.
>
>http://www.whatwg.org/spe
Ian Hickson wrote, On 2009-04-06 20:37 PDT:
> I have now specified the 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 n
Gervase Markham wrote:
>On 07/04/09 15:38, Jean-Marc Desperrier wrote:
>> 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 :-)
It doesn't really matter if ge
On 07/04/09 15:38, Jean-Marc Desperrier wrote:
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
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.
On 04/07/2009 05:38 PM, Jean-Marc Desperrier:
Eddy Nigg wrote:
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 somethin
Eddy Nigg wrote:
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
On 04/07/2009 06:37 AM, Ian Hickson:
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 at this time. I want to start
by making sure the spec as written matches re
On Tue, 07 Apr 2009 09:34:44 +0200, Ian Hickson wrote:
On Tue, 7 Apr 2009, James Ide wrote:
Going one step further, if the element does support multiple
algorithms, would it be worthwhile to allow it to contain parameters,
e.g. ? On one hand, the set of
widely-implemented algorithms seems
On Tue, 7 Apr 2009, James Ide wrote:
>
> Going one step further, if the element does support multiple
> algorithms, would it be worthwhile to allow it to contain parameters,
> e.g. ? On one hand, the set of
> widely-implemented algorithms seems small and fixing attribut
I have now specified the 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, Ander
43 matches
Mail list logo
