F.Y.I.
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.
/anders
- Original Message -
From: Ian Hickson i...@hixie.ch
To: wha...@whatwg.org
Sent: Tuesday, January 06, 2009 13:40
A better solution would be to authenticate the user as well
as is possible. After successful authentication through
a web ID portal (which would identify itself through an
non-personal) org-cert the user would be redirected to the
actual app using SAML. If the user has a personal certificate
it
The originator of this thread has left out what the entities are, apps, orgs,
machines, users, roles
etc. In order to come up with a useful advice, I would start by doing that
because then we also
know where the different entities are administered (and certified).
Keeping machine-certs in
dmccar...@annadaletech.com wrote:
snip
Nothing I've heard thus far has made me think that this is an
inherently bad idea, I suppose what I need is help in accomplishing it
(and preferably accomplish it in Mozilla - our application is quite
AJAXy and the Javascript speedup in Firefox 3.1 is a
Nelson B Bolyard wrote:
Kyle Hamilton wrote
Hey, I just ran into the first application of client certificate
authentication requirement on a public US government website that I've
seen.
snip
I played with it a bit.
As far as I can tell, it is not doing SSL client authentication, per se',
at
http://keycenter.webpki.org
1. Enroll.
2. Then try
Phone Emulator
3. In the Phone Emulator issue Quick Run
Anders
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Yes, client certificates are unusable unless they become mobile.
How are they going to get mobile?
I have thought a bit on that and the only reasonable short-term solution
is to use [slightly enhanced] USB memory sticks that already are owned
by hundreds of millions of people. Unfortunately it
- Original Message -
From: Kyle Hamilton aerow...@gmail.com
To: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org
Sent: Tuesday, March 17, 2009 22:59
Subject: Re: client certificates unusable?
On Tue, Mar 17, 2009 at 2:51 PM, Anders Rundgren
anders.rundg...@telia.com
This is a stupid discussion.
Authentication schemes in general begin with authenticating the user.
How long the authentication should be considered as valid is
not something the client-end has anything to do with unless it
has gotten some kind of expiration data from the server.
It seems pretty
, 2009 at 12:32 AM, Anders Rundgren
anders.rundg...@telia.com wrote:
This is a stupid discussion.
Authentication schemes in general begin with authenticating the user.
How long the authentication should be considered as valid is
not something the client-end has anything to do with unless it
has
On Fri, Mar 20, 2009 at 11:29 AM, Anders Rundgren
anders.rundg...@telia.com wrote:
This is a stupid comment.
Pardon me. I just don't agree with the majority of this list since
many governments and banks in the EU are working in another
direction. This may be due to ignorance but I insists
issue: It seems that the AIA ca issuer extension is not supported. This
complicates
server-setups alternatively requires the end-user to install immediate CA
certificates.
Solution: Update FF. Could preferably be a part of HTTPS.
Anders Rundgren
--
dev-tech-crypto mailing list
dev-tech-crypto
Nelson B Bolyard wrote:
Solution: One solution would be to define signature support as a
browser component.
Especially the component you've invented and have been trying to get
Mozilla to adopt for some time, right? Anders?
At this stage it is enough considering (acknowledging) the 10M+ that
- Original Message -
From: Anders Rundgren
To: KEYPROV
Sent: Tuesday, March 24, 2009 22:01
Subject: IETF KEYPROV bar discussion topic
A major problem with stuff like KEYPROV and KeyGen2 as well as older schemes
like keygen, generateCRMFRequest() and CertEnroll is the absence
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
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://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019338.html
If I were to select between these to solutions, generateCRMFRequest would be my
choice because protocols do not belong to HTML pages.
Anders--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
Michael Ströder wrote:
If I were to select between these to solutions, generateCRMFRequest
would be my choice because protocols do not belong to HTML pages.
That's nonsense. I like keygen more because it's simple, you can put
it in HTML templates and it doesn't need Javascript.
When/if a
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
://developer.mozilla.org/en/GenerateCRMFRequest
please give drop me a line :-)
Anders
- Original Message -
From: Jonas Sicking jo...@sicking.cc
To: Anders Rundgren anders.rundg...@telia.com
Cc: wha...@lists.whatwg.org; Nelson B Bolyard nel...@bolyard.me;
dev-tech-crypto@lists.mozilla.org
Sent: Friday, April
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
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. None of the makers of
smart cards have invested a single cent in a consumer-oriented
on-line provisioning scheme. And if
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
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?
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
That was a very politically correct message.
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:
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
Unfortunately the [potential] problem is much bigger than that!
A hacked browser and/or operating system can essentially screw the user in all
ways possible for a
computer.
The green bar may lit all the time for example.
I would personally be a bit cautious about opening company mail in a
I have two answers.
1. This is an OpenSSL question and should be directed to an OpenSSL forum
2. Browsers indeed have different key-generation methods but they do have one
thing in common: the methods are completely useless, not even PIN protection
is a part of the plot unless you use
openssl
thnx anders..
i have posted in openssl forum my query..
can i make PKCS10 string using keygen tag then ?
2009/5/29 Anders Rundgren anders.rundg...@telia.com
I have two answers.
1. This is an OpenSSL question and should be directed to an OpenSSL forum
2. Browsers
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
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
-
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
http://www.redhat.com/docs/manuals/cert-system/admin/7.2/Administration_Guide-Token_Processing_System-Enrolling_Smart_Cards_through_the_Enterprise_Security_Client.html
Just in case somebody still believes that Firefox's and HTML5's keygen has
any smart card utility except for a handful of
Gervase Markham wrote:
The biggest impediment to secure email today is the existence and
popularity of webmail. In Mozilla terms, the biggest impediment to Thunderbird
today is Firefox.
It seems that people are happy to make the trade-off of privacy against
convenience here. I suspect it's
Eddy Nigg wrote:
On 06/26/2009 09:18 PM, Michael Ströder:
But only a small minority of mail users use MUAs
that reside on their own computers today. Webmail rules,
That might be true in the U.S. It's not true here in Germany.
Webmail doesn't rule...otherwise somebody explain to me from what
Ian G wrote:
Google's Wave will hopefully be the finale for S/MIME.
Hmmm, tell me more. It does look interesting!
How is it secured? I read some blurbs and things but I'm hoping someone
knows the answers.
I must confess that I don't have detailed knowledge about Wave but
it appears to be
I can't help you with the specific problem [:-(] but I can help you
with a diagnostic at least. Which is? Smart card vendors have
spent decades on fighting each other on the spec/middleware
side and naturally we all have to pay the price.
Tokens for consumers have therefore been [rightfully]
PKCS #10? I guess you really meant PKCS #11.
I'm not aware of any such profile. There is smart card profile
but I doubt it has much to do with PKCS #11, it is rather about
7816.
Anyway, the way Firefox is linked to PKCS #11 is probably OK
in Linux-land.
However, in Windows-land where 80% of
Kyle Hamilton wrote:
3) There is no desire at/for the bank to allow smart-card login,
because there are alternatives that are more useful
Exactly! It doesn't work for the really useful applications that
could drive the market.
Anders
PS. There were some oddities in the
!
In answer to your question: Yes, the Linux Software Base now includes NSS.
Numerous products use it, including Google's Chrome and Adobe's Flash Player.
That's good to hear!
Regards
Anders Rundgren
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org
Eddy Nigg wrote:
On 07/03/2009 08:15 AM, Anders Rundgren:
I'm sorry about that. Is there any other place where Mozilla people hang
out where there is an interest in trying to understand why and what is
happening on the PKI side for consumers?
Anders, I think you must take your ideas
This is something I really hate:
http://www.evs.ee/product/tabid/59/p-165216-cents-15480-22007.aspx
Paying for *open* standards!
Anyway, this scheme will get hard competition from a lot of places including
the token vendors who certainly do not want to become replaceable like USB
memory
The URLs didn't work so I repost it and this time with a correct subject line...
This is something I really hate:
http://www.evs.ee/product/tabid/59/p-165216-cents-15480-22007.aspx
Paying for *open* standards!
Anyway, this scheme will get hard competition from a lot of places including
the
This demonstrates that standardization is an option but an increasingly
difficult
option as well in an ever faster-moving world:
http://www.w3.org/2009/06/xhtml-faq.html
I'm sure that (for example) a signature scheme done by a handful of committed
people
as a Firefox extension would likely do
Ian G wrote:
I'm sure that (for example) a signature scheme done by a handful of
committed people
as a Firefox extension would likely do much better than a W3C or OASIS WG
could
even dream of.
No doubt there whatsoever. The notion that W3C or any of the other
acronyms can do a signature
.
Happy 4:th wishes
Anders Rundgren
Reasonably good engineer, lousy salesman
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Eddy Nigg wrote:
Actually, I haven't seen evidence of that, although you did claim that when
you imported the PKCS#12 file into the software token, that the missing CA
cert was then found present.
It's not a good idea to place the CA certificate on the token because
the trust bits may get
William L. Hartzell wrote:
snip
I assume that you been following IETF RFC on the Crypto subject. They
just released a series of RFC on management of keys.
I have not heard of this before unless you are talking about TAM, TAMP
or KEYPROV. None of these efforts have any relevance for the subject
Nelson Bolyard wrote:
Yes, telling the user who wants it would help A LOT. Sadly, that's a
browser architecture matter of which the NSS team has no influence.
Martin Paljak wrote:
I think that approaching Firefox team from the NSS side AND from
outside would give a better result than just
M.Hunstock wrote:
Anders Rundgren schrieb:
BTW, we still don't have a credible system for *remote* provisioning of
smart cards on any OS, so we shouldn't expect too much progress here
because PKCS #11 can't do that job actually!
Why? What are you missing?
http://webpki.org/papers/keygen2
Hi Martin,
The naked truth is that provisioning of TPMs is not supported by
any generally established protocols or APIs (at least using TPM methods),
but this is also a fact for smart cards since there is no way you
can policy-define/set PIN-codes using for example Firfox's keygen.
I once did a
When the TPM is enabled and PKCS #11 configured, PKCS #12 import should
work directly in Firefox,
Unfortunately, I have no knowledge of how you enable a specific TPM
since this is a part of an associated software bundle. I have only
used Wave Systems stuff which is very different to TroUsers.
CA-app will do. End-user provisioning is thus a core theme
but the architecture is also fully compatible with centralized production
of ID-cards. The latter suffer from a serious recovery-from-loss-problem
that the described scheme can deal with in a novel way.
Regards
Anders Rundgren
Reasonably
That TPMs cannot sign CSRs is true but TPMs can do something similar
and IMHO much more interesting which attesting that a public key
(and thus indirectly the associated private key) was created inside of
the TPM.
The problem here is that few APIs and even fewer protocols deals with
this kind
This is an interesting project.
What's not completely obvious is how this relates (or could relate) to
for example Firefox.
I must confess that I know absolutely nothing about NSS but I assume
that the soft-token uses obfuscation and an *optional* password as
the sole protection mechanism.
Ian G wrote:
On 12/7/09 21:58, Anders Rundgren wrote:
Nelson B Bolyard wrote:
On 2009-07-12 05:51 PDT, Anders Rundgren wrote:
This is an interesting project.
What's not completely obvious is how this relates (or could relate) to
for example Firefox.
I must confess that I know absolutely
Would it be possible to get a description of this?
Cheers,
Anders
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
soft tokens should be harder than Firefox's.
If I manage to get the following running http://android-keystore-v2.webpki.org
Android soft keys should be comparable to MSIE's.
Anders
- Original Message -
From: Anders Rundgren anders.rundg...@telia.com
To: mozilla's crypto code discussion
Nelson B Bolyard wrote:
On 2009-07-19 13:43 PDT, Anders Rundgren wrote:
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp815.pdf
I hope this document describes this correctly. If so, it verifies my guess
that NSS does use any operating-system tricks to protect soft keys.
NSS
Udo,
I believe the whole area of on-line provisioning is very immature.
MSIE's Active X c**p in Vista is an indication that Microsoft is no
better than Mozilla.
Although few folks in this list do not acknowledge it, the really big
users of on-line
provisioned PKI (in the EU) do not use the
I concur with Martin, but would also like to mention that
two-factor authentication when deployed in phones (unlike in
PCs), combine convenience *and* security.
The problem with phones is that due to the platform diversity
an interoperable solution must be supported by the platform
vendor
Udo Puetz wrote:
snip
P.s.: I haven't seen anything on the main page of this group that it
shall only deal with NSS. Maybe Nelson or someone could write that
into the description of this group.
There is no Mozilla-list for discussing high-level aspects of PKI-using
applications like TB and FF.
should be
interpreted as /multiple and independent issuers all having their own
ideas about policies/.
Sincerely,
Anders Rundgren
Senior Security Consultant
Adrian Bateman wrote:
On Saturday, August 08, 2009 12:50 AM, Anders Rundgren wrote:
http://lists.w3.org/Archives/Public/public-html
discussion list dev-tech-crypto@lists.mozilla.org
Sent: Tuesday, September 22, 2009 23:13
Subject: Re: keygen- A Requirement Specification
On Tue, Sep 22, 2009 at 10:35:47PM +0200, Anders Rundgren wrote:
http://lists.w3.org/Archives/Public/public-html/2009Sep/0043.html
It is extremely unlikely
September 27, 2009 07:05 Nelson B Bolyard wrote:
To me cluelessness seems to be all over the map since nobody (including
the people subscribing to this list), have bothered the least about what
this thingy is supposed do, and how, and why.
I'm sorry if you feel cluelessness abounds. Let me
Eddy Nigg wrote:
Which is obviously not correct. Most revocations happen due to loss and
compromise of private keys, retirements, software bugs, misuse, but
seldom due to validation failures.
I would be surprised if a single public-TTP-issued server-certificate has ever
been revoked due to loss
Victor,
I would characterize your proposal as a variant of the keeping your
credentials in the cloud
vision.
Google (how surprising...) is indeed pushing this for Information Cards.
Personally, I remain skeptic about the combination of dedicated desktop SW and
the cloud,
a lighter version only
https://www.apache-ssl.org/cgi/cert-export
Any ideas why?
Anders
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Hi,
I can't help it, but TLS client cert auth is really a very crappy system
when used in browsers. I was a little bit surprised once when I logged
on to the Swedish tax department, then did logout, and returned still
being logged in!
Microsoft solved this years ago by offering a
Nelson B Bolyard wrote:
snip
A server that logs you out and doesn't clear your TLS session from its
server session cache is a badly designed server. That's not a fundamental
flaw in TLS or in browsers, and could also happen with cookies or any other
scheme for caching session information. So
Why is replacing the 15 year old Netscape hack suddenly a bad idea?
Because you cannot create a secure provisioning system without having
some kind of [by the issuer recognizably] predefined key in the token.
With such a key, the token would be able to attest generated keys,
import data
using
Nelson B Bolyard wrote:
On 2010-03-12 22:12 PST, Anders Rundgren wrote:
Why is replacing the 15 year old Netscape hack suddenly a bad idea?
Anders,
Your message is evidently a reply to some other message which was not
sent to this list, and which you did not quote. Please provide a URL
where
I don't see much value supporting a function that still misses
the core question: is the key actually in the card?
Anders
Jean-Marc Desperrier wrote:
Emmanuel Dreyfus wrote:
So as I understand, it is not implemented yet. This is a quite
disapointing, since the documentation does suggests it
Emmanuel Dreyfus wrote:
On Wed, Mar 17, 2010 at 11:24:37AM +0100, Anders Rundgren wrote:
I don't see much value supporting a function that still misses
the core question: is the key actually in the card?
I do not understand your concern. As far as I understand, the purpose
crypto code discussion list dev-tech-crypto@lists.mozilla.org
Sent: Wednesday, March 17, 2010 14:12
Subject: Re: popChallengeResponse unimplemented?
Anders Rundgren anders.rundg...@telia.com wrote:
That's correct. But even if you send a stolen static cert req, you don't
get very far
I think I got the overall picture but I do not understand
how LDAP knows what key to prove possession of unless you
have as I suggested do an initial browser-2-web server auth
first.
Anders
Emmanuel Dreyfus wrote:
Anders Rundgren anders.rundg...@telia.com wrote:
I can't say I fullu
Related work:
http://tools.ietf.org/wg/pkix/draft-ietf-pkix-certimage/
will IMHO be difficult to roll out because it mixes local GUI
requirements with relying party ditto.
anders
- Original Message -
From: Kai Engert kaie-dontspa...@kuix.de.example.test
Newsgroups:
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
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
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
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
Hi,
Since there are no standards in this space most banks and e-governments
use proprietary (but cross-browser) Java plugins. In the EU there are at
least 10 different national schemes.
Chrome and Safari presumably do not support any pre-configured solution
since no such solution has gotten
Anders,
Thanks for your mail. Is there any proprietary solution that's
named Message Pro or so??
On Apr 6, 5:26 pm, Anders Rundgren anders.rundg...@telia.com wrote:
Hi,
Since there are no standards in this space most banks and e-governments
use proprietary (but cross-browser) Java plugins
Hi Mountie,
A service provider cannot specify *anything* regarding key protection
using Firefox.
Anders
Mountie Lee wrote:
Thanks Eddy.
in IE
the service provider can choose the private key can be exportable or not.
the manual configuration is not so attractive for service provider.
is it
Nelson B Bolyard wrote:
snip
Hi Mountie,
A service provider cannot specify *anything* regarding key protection
using Firefox.
Anders, I think Mountie was referring to Crypto Service Provider (CSP),
which is Microsoft's name for software modules that follow Microsoft's
alternative that is
- Original Message -
From: Nelson B Bolyard nel...@bolyard.me
snip
I think he's referring to the fact that the PKCS#11 module must be manually
configured to be in FIPS mode or not in FIPS mode.
I'm not aware of any automatic protection settings for manual key import in
Windows, unless
Mountie Lee wrote:
I mean CKA_EXTRACTABLE.
as a Sub-CA, when they issue client certificate, they want to make sure
the private key will be exported outside of browser keystore.
the only one exception is when the private key is in hardware token, it
can be moved to other browser.
I didn't get
Nelson B Bolyard wrote:
snip
keygen since a CA has no options for key protection during issuance
using Firefox which it has using MSIE.
Yes, I quite agree with you on this point, Anders. The problem is that the
CA cannot express to Firefox that it wants Firefox to require that the
generated
Amax Guan wrote:
Hi,
I'm working on a Certificate renew process for a bank in china.
The bank stored the certificate in a USB key, and when the user needs
to renew the certificate, the bank will trigger the cert issue process
to do that, using keygen. But when the issue begins, because the
PM, Anders Rundgren
anders.rundg...@telia.com wrote:
Amax Guan wrote:
Hi,
I'm working on a Certificate renew process for a bank in china.
The bank stored the certificate in a USB key, and when the user needs
to renew the certificate, the bank will trigger the cert issue process
to do that, using
this is primarily a European/Asian issue and we cannot expect to
get any support from Mozilla except maybe a Good luck or so :-)
Regards
Anders Rundgren
And they
want to put their CA Root certificate into Firefox, so that there will
be no alert popup in the certificate generate
-a843-462f-abb5-ff88ea5896f6displaylang=en
But I can't imagine end-users dealing with such a horrible tool.
This is for *cryptopgraphers* only.
Making a Chinese Firefox distribution should be a more workable solution.
Anders
On Wed, Jul 21, 2010 at 11:32 PM, Anders Rundgren anders.rundg
The following is mainly directed to people working with mobile
devices although the issue of course also applies to PCs.
Recently I had an interesting conversation with a security technologist of
a major payment provider who had seen links to my SKS/KeyGen2 stuff [0].
He was quite concerned
I have one question: Why would you want NSS in Android?
The reason I wonder is because apps in Android are
mainly written in (sort-of) java and both bouncycastle
and openssl are already on-board.
If you really want to make a change that would be adding
a useful way to get keys on mobile devices
May I comment a bit on this?
msm Li wrote:
Currently, the smartphone platform is lack of unified
software/hardware security module.
For example, iPhone stores certificates in the Keychain, BlackBerry
stores certificates
in BlackBerry device key store, Android has no such secure storage.
True.
David Stutzman wrote:
I'm assuming not based on my experience, but does NSS support point
compression on EC keys?
Dave
Isn't that a thing that Certicom have patented?
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
http://www.gsmworld.com/newsroom/press-releases/2010/5726.htm
As I said a million times before, on-line provisioning of HW tokens
is the future.
My take on this subject is (still...) defining a standard container based
on Open Hardware because E2ES (End to End Security) cannot be
abstracted
Hi,
I'm in the starting phase upgrading Firefox so that it can provision
credentials in a way that that banks and governments require which
among many things include E2ES (End-to-End Security) and issuer-
specified PIN-codes (or just policies for user-defined dittos).
The plan is mainly
101 - 200 of 282 matches
Mail list logo
