On 29/11/11 17:34, Brian Smith wrote:
What I said/meant is that inquiries regarding legal issues should be
made to Mozilla Legal instead of the technical areas of bugzilla or
the technical mailing lists. I do not know if anybody has contacted
our legal team or if there is a reason to. I just
Scott Thomas a écrit :
keygen name=spkac keytype=EC keyparams=secp384r1/
but the keys are not generated.
i have checked that ECC support from mozilla was removed, can any body
confirm it or tell the way how to enable it, ?
https://bugzilla.mozilla.org/show_bug.cgi?id=367577
Ideas / thoughts ??
Jean-Marc Desperrier wrote:
Brian reported there that this should be investigated by the legal
group, but I'm worried nothing happened since then.
What I said/meant is that inquiries regarding legal issues should be made to
Mozilla Legal instead of the technical areas of bugzilla or the
Bonjour,
I am using the keygen element for client end key generation in
firefox. RSA is working fine but ECC is having problems.
In code when i use RSA
keygen name=spkac keytype=RSA/ Proper RSA keys are generated
In code when i use ECC
keygen name=spkac keytype=EC keyparams=secp384r1
Does anyone know why HTML5 specifies keygen must use the
md5WithRSAEncryption signature algorithm? Was the use of MD5
discussed when keygen was standardized in HTML5?
Eddy, does your CA accept a SignedPublicKeyAndChallenge (SPKAC)
structure signed using sha1WithRSAEncryption?
Wan-Teh
--
Wan-Teh Chang wrote:
Does anyone know why HTML5 specifies keygen must use the
md5WithRSAEncryption signature algorithm? Was the use of MD5
discussed when keygen was standardized in HTML5?
Eddy, does your CA accept a SignedPublicKeyAndChallenge (SPKAC)
structure signed using
Anders,
On Mar 30, 10:57 pm, Anders Rundgren anders.rundg...@telia.com
wrote:
Good to hear, thanx.
Doesn't that also mean that anybody can enumerate your CSPs without your
knowledge?
no, IE still says The site is attempting to perform a certificate
operation, allow (yes/no) when
Since keygen Co do not support smart cards in a reasonable way
except for the creation of administrator cards, I have played
with something that is more in line with how *real* card management
systems work while still using a browser. The following is an
approximation of how this scheme.
After
The most adequate group for this discussion would be mozilla.dev.tech.crypto
I agree than enhancing generateCRMFRequest to let it generate a more
usual format instead of only CRMF would be a big step forward.
And making more obvious that keygen is not a good long term solution is
a very good
On 03/30/2010 01:23 PM, Jean-Marc Desperrier:
And making more obvious that keygen is not a good long term solution
is a very good thing.
Only in case the alternative will be supported by all or most browsers.
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:
Eddy Nigg wrote:
On 03/30/2010 01:23 PM, Jean-Marc Desperrier:
And making more obvious that keygen is not a good long term solution
is a very good thing.
Only in case the alternative will be supported by all or most browsers.
The original message shows that the fact keygen imposes a text of
It might be interesting to note how this works in MSIE since few
CAs can completely ignore MSIE even if they wanted to:
keygen a la Microsoft:
It starts by the poor user trying to get the enroll ActiveX object
to run *by reducing security until it starts*.
Most people fail already at this
On Mar 30, 12:23 pm, Jean-Marc Desperrier jmd...@gmail.com wrote:
The most adequate group for this discussion would be mozilla.dev.tech.crypto
I agree than enhancing generateCRMFRequest to let it generate a more
usual format instead of only CRMF would be a big step forward.
And making more
On 03/30/2010 01:53 PM, Anders Rundgren:
It might be interesting to note how this works in MSIE since few
CAs can completely ignore MSIE even if they wanted to:
The solution is really to define one standard, if that's keygen, so
long...preferable it should be fairly simply with few flags
On Mar 30, 12:53 pm, Anders Rundgren anders.rundg...@telia.com
wrote:
It might be interesting to note how this works in MSIE since few
CAs can completely ignore MSIE even if they wanted to:
keygen a la Microsoft:
It starts by the poor user trying to get the enroll ActiveX object
to run *by
On Mar 30, 4:39 pm, Thomas Zangerl thomas.zang...@freenet.de wrote:
to do it (can be painful) and it create standard PKCS#7 CSRs. Keygen
I meant creates PKCS#10 CSRs. Need more coffee :)
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
Thomas Zangerl wrote:
On Mar 30, 12:53 pm, Anders Rundgren anders.rundg...@telia.com
wrote:
It might be interesting to note how this works in MSIE since few
CAs can completely ignore MSIE even if they wanted to:
keygen a la Microsoft:
It starts by the poor user trying to get the enroll
On Wed, Jun 3, 2009 at 3:31 PM, Ian Hickson i...@hixie.ch 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
A guesstimate is that less than 1 out of 10 000 smart cards actually
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
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 keygen.
Can you backup your statement with facts please?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:
-
From: Eddy Nigg eddy_n...@startcom.org
Newsgroups: mozilla.dev.tech.crypto
To: dev-tech-crypto@lists.mozilla.org
Sent: Thursday, June 04, 2009 20:52
Subject: Re: Smart cards and the keygen element
On 06/04/2009 09:40 PM, Anders Rundgren:
A guesstimate is that less than 1 out of 10 000 smart
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 actual standardized
A genuine problem is that keygen 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 keygen.
Real card provisioning systems
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
On 04/07/2009 06:37 AM, Ian Hickson:
I have now specified thekeygen 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
On Mon, Apr 6, 2009 at 8:37 PM, Ian Hickson i...@hixie.ch 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
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 keygen is implemented in FireFox AFAICT.
Unfortunately this part is also
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
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 Firefox
. 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-tech-crypto@lists.mozilla.org
Sent: Saturday, April 18, 2009 10:04
Subject: Re: The keygen element
Martin Paljak wrote
On 04/18/2009 11:21 AM, Anders Rundgren:
Hi Nelson,
Smart cards are essentially never provisioned usingkeygen 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
On 04/18/2009 11:21 AM, Anders Rundgren:
Hi Nelson,
Smart cards are essentially never provisioned usingkeygen 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
Smart cards are essentially never provisioned usingkeygen 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 generating
Anders Rundgren wrote:
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
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. keygen?
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 stick to the
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.
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?
Oh, come on! I know it's currently not
On Sat, Apr 18, 2009 at 11:04 AM, Nelson B Bolyard nel...@bolyard.me 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
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
On Thu, Apr 16, 2009 at 9:22 PM, Anders Rundgren
anders.rundg...@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
/msg00753.html
Anders
- Original Message -
From: Nelson B Bolyard nel...@bolyard.me
To: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org
Sent: Saturday, April 18, 2009 21:23
Subject: Re: The keygen element
Martin
Thanks for your very informative and useful email
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-line
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
17, 2009 23:16
Subject: Re: [whatwg] The keygen element
On Thu, Apr 16, 2009 at 9:22 PM, Anders Rundgren
anders.rundg...@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
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
Ian Hickson wrote, On 2009-04-06 20:37 PDT:
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
- Original Message -
From: Nelson B Bolyard nel...@bolyard.me
To: Ian Hickson i...@hixie.ch
Cc: wha...@whatwg.org; dev-tech-crypto@lists.mozilla.org
Sent: Monday, April 13, 2009 02:18
Subject: Re: The keygen element
Ian Hickson wrote, On 2009-04-06 20:37 PDT:
I have now specified the keygen
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
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 keygen
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
On Tue, 07 Apr 2009 09:34:44 +0200, Ian Hickson i...@hixie.ch wrote:
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
matches reality.
The spec says: The |keygen
http://www.whatwg.org/specs/web-apps/current-work/#the-keygen-element|
element represents
http://www.whatwg.org/specs/web-apps/current-work/#represents a key
pair generator control. When the control's form is submitted, the
private key is stored
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
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
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
56 matches
Mail list logo
