I don't know how it maps to NSS, but at the PKCS#11 layer you can generate a
key pair, export the public key (even in FIPS mode, because it's public), use
the public key to encrypt your secret key, then unwrap that with the private
key. Then you can use that secret key to unwrap private keys.
On 04/05/15 21:53, David Woodhouse wrote:
On Mon, May 4, 2015 1:25 pm, David Woodhouse wrote:
Surely that's not unique? Using the above example, surely the first
certificate issued by the 2010 instance of 'My CA', and the first
certificate issued by the 2015 instance, are both going to
On 05/05/15 16:55, David Woodhouse wrote:
On Mon, May 4, 2015 1:25 pm, David Woodhouse wrote:
Hm... so if I have two certificates; one with:
CKA_SUBJECT: My CA
CKA_LABEL: My CA (2010 instance)
and the other:
CKA_SUBJECT: My CA
CKA_LABEL: My CA (2015 instance)
Surely that's not
On 30/04/15 17:56, David Woodhouse wrote:
Has anyone looked at implementing RFC7512 support, allowing an object
to be specified by a PKCS#11 URI?
I don't suppose you know why RFC 7512 uses CKA_ID but not CKA_SUBJECT,
when PKCS#11 says The*CKA_ID*attribute is intended as a means of
On 20/05/14 02:18, Wan-Teh Chang wrote:
On Fri, May 16, 2014 at 2:19 AM, Vicente Olivert Riera
vincent.ri...@imgtec.com wrote:
Sorry, I'm not english native. What's the meaning of I'd like *wtc* to way
in?
wtc is my user id (from the initials of my name) :-)
And way in is a typo for weigh
On 12/04/14 21:33, Florian Weimer wrote:
* Julien Pierre:
Strange that PKCS#11 support is listed as a con for NSS .
I found the PKCS#11 approach rather difficult to deal with if you're
adding cryptography to some library whose client code has no idea that
there is cryptography involved (and
On 08/04/14 13:11, Jean-Marc Desperrier wrote:
Ryan Sleevi a écrit :
reliance on PKCS#11 means that there are non-trivial overheads when
doing something as simple as hashing with SHA-1. For something that is
such a simple transformation, multiple locks must be acquired and the
entire NSS
On 31/01/14 18:28, Ryan Sleevi wrote:
On Fri, January 31, 2014 9:18 am, Alan Braggins wrote:
On 31/01/14 10:24, Julien Pierre wrote:
On 1/27/2014 10:28, Kathleen Wilson wrote:
Draft Design Doc posted by Ryan Sleevi regarding Chrome migrating from
NSS to OpenSSL:
https://docs.google.com
On 31/01/14 10:24, Julien Pierre wrote:
On 1/27/2014 10:28, Kathleen Wilson wrote:
Draft Design Doc posted by Ryan Sleevi regarding Chrome migrating from
NSS to OpenSSL:
https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/edit?pli=1
Strange that PKCS#11 support
On 27/01/14 17:26, ripber...@aol.com wrote:
2) NIST is a US government standards board that drives a lot of compliance
regulation. There are companies what will want to be able show that they
are NIST compliant. The standard at this point does NOT allow you to
use Camellia.
On 06/12/13 13:07, firef...@gmail.com wrote:
Hi,
I have a couple of questions concerning certificate handling in Firefox and
PKCS#11.
When Firefox receives a X.509 cert during HTTPS establishment, the certificate
(chain) is validated by NSS, right?! Is this done via PKCS#11 or are Firefox
On 22/08/13 11:50, Alan Braggins wrote:
On 21/08/13 18:23, Zack Weinberg wrote:
I share concern
about new side channel attacks due to GMAC, though.
You aren't alone.
https://bugzilla.mozilla.org/show_bug.cgi?id=868948
I asked a friend who works for ARM about the chances of
constant time
On 21/08/13 18:23, Zack Weinberg wrote:
On 2013-08-19 2:06 PM, Kurt Roeckx wrote:
I understand that GCM is faster, but the implementations might have side
channel attacks. So I'm not sure if GCM or CBC is better, but
we should probably prefer GCM or CBC.
GCM is (AIUI) preferred because it's
On 19/08/13 19:06, Kurt Roeckx wrote:
I understand that GCM is faster, but the implementations might have side
channel attacks. So I'm not sure if GCM or CBC is better, but
we should probably prefer GCM or CBC.
GCM (while recognizing that it isn't widely supported yet).
(At least unless
14 matches
Mail list logo
