Re: libnsssysinit

[Robert Relyea]

On 12/08/2014 08:59 AM, David Woodhouse wrote:
I still maintain that the path to sanity involves killing 
/etc/pki/nssdb entirely, and then you can look at applying *correct* 
fixes to whatever's still not behaving correctly.


The whole point of /etc/pki/nssdb is so you have one place to install 
stuff. It's the default for anything that I've had a say in and will 
continue to be the default.


bob






smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Accessing Firefox keystore

[Robert Relyea]

On 01/09/2015 08:03 AM, Opa114 wrote:

i do. but i want to parse the cert8.db or maybe access this fle in an easier 
way with JAVA. i have to read the file and maybe i have to remove and/or add 
new certificate to it.
While there is some documentation on the format of cert8.db, If you are 
accessing it from Java inside firefox and you aren't accessing it from 
JSS, then you run the risk of corrupting the database.


If you are just accessing it standalone, then you may have more success, 
though that's a pretty complicated route. The file is in the old 
berkeley DB format, which means you'll need to access it some how. I 
doubt there are java bindings for that code, berkeley stopped 
maintaining it before Java existed (it eventually became sleepycat). So 
first you'd need the old DB format.


They way NSS uses the database records is documented here: 
http://www-archive.mozilla.org/projects/security/pki/nss/db_formats.html
Even though this says cert7.db, it's basically the same, except cert 8 
databases may contain crls (iirc).


This doesn't get you signing access. For that you'd need to also access 
key3.db, which has it's own set of 'row'/'payload' values, as well as 
PKCS5 encoded keys.


bob



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Using JSS SSLSocket and and SSLServerSocket TLS 1.1 and 1.2

[Robert Relyea]

On 01/13/2015 09:18 AM, Christina Fu wrote:
jss-4.2.6-35 can be found on koji for various supported fedora 
platforms.  For rhel it's the same version number.


Christina

Are there any outside available builds, like windows?

bob


On 01/13/2015 09:09 AM, Robert Relyea wrote:

Christina, which version of JSS has TLS 1.1 and 1.2 support enabled?

Bob

On 01/12/2015 02:10 PM, deepr...@gmail.com wrote:

Folks,

Sorry for the totally newbie question but I've hunted high and low.

I am supporting some Java code that uses JSS4, NSS to provide
SSL Server side services.

In response to Poodle I've been looking this code and was able to 
Enable TLS explicitly and disable SSL to mitigate that in it's most 
basic form.


However I was hoping to be able to add at least TLS 1.1 if not 1.2 
support.


I cannot find how this is done or if possible.

I've build the latest NSS code base which seemingly supports these 
protocols, and build JSS around it but can't seem to get a TLS 
1.1/1.2 connection.


The JSS source code also doesn't show any of the SHA256 ciphers etc 
that imply TLS 1.2..so I've come the conclusion that I cannot use 
JSS to execute TLS 1.1/1.2 server side connections.


Hopefully I'm wrong, or stupid but not both.

Can anyone confirm, deny or otherwise point me in the right 
direction on this topic.


Thank you

Colin










smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Using JSS SSLSocket and and SSLServerSocket TLS 1.1 and 1.2

[Robert Relyea]

Christina, which version of JSS has TLS 1.1 and 1.2 support enabled?

Bob

On 01/12/2015 02:10 PM, deepr...@gmail.com wrote:

Folks,

Sorry for the totally newbie question but I've hunted high and low.

I am supporting some Java code that uses JSS4, NSS to provide
SSL Server side services.

In response to Poodle I've been looking this code and was able to Enable TLS 
explicitly and disable SSL to mitigate that in it's most basic form.

However I was hoping to be able to add at least TLS 1.1 if not 1.2 support.

I cannot find how this is done or if possible.

I've build the latest NSS code base which seemingly supports these protocols, 
and build JSS around it but can't seem to get a TLS 1.1/1.2 connection.

The JSS source code also doesn't show any of the SHA256 ciphers etc that imply 
TLS 1.2..so I've come the conclusion that I cannot use JSS to execute TLS 
1.1/1.2 server side connections.

Hopefully I'm wrong, or stupid but not both.

Can anyone confirm, deny or otherwise point me in the right direction on this 
topic.

Thank you

Colin





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Accessing Firefox keystore

[Robert Relyea]

On 12/11/2014 12:33 AM, helpcrypto helpcrypto wrote:

Hi again, sorry for delay.

Yes, you can (SHOULD) use SunPKCS#11 to access directly the
libraries/modules.
You can do it two ways:

  - attack libraries directly
  - parse (legacy) secmod.db on Firefox profile to list modules/libraries.
Actually this is a very good way to corrupt your database. Mozilla still 
uses the old database, so accessing you NSS database from SunPKCS#11 
with another softoken module while you are running will corrupt your 
database.


Unfortunately the only safe way is to use JSS, as sucky as it is. You 
can use JSS as just a provider and use your normal Java interfaces, 
however. You don't need to use the direct to NSS bindings.


bob


Have a look on

http://stackoverflow.com/questions/2873581/is-it-possible-to-access-a-bdb-from-pure-java
 sethi.org/tmp/ssh/src/com/mindbright/bdb/DBHash.java

It's quite complex, so if you get lost, I could try to send you some code.

Regards.




On Mon, Dec 8, 2014 at 7:48 PM, opa...@gmail.com wrote:


I have the same question / problem.

I want to access the mozilla keystore (firefox and thundebird) via Java
(No Java Applet) or C#? I found the JSS/NSS Provider, but no information on
how to use it and on which way i can access the keystores. So how is it
possible? Little example Code would be helpful. And is it possible with C#?

Or there are other ways to access them? maybe read in the whole cert8.db
file, but it looks like that the file is encrypted. so the question is, how
could i decrpyt the file?

Hope someone could help :)
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto






smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Key zeroization in NSS DB

[Robert Relyea]

On 03/25/2015 04:30 AM, Jan Otte wrote:

Hi,

When finding out how to do key zeroization in NSS DB I stumbled upon

https://bugzilla.mozilla.org/show_bug.cgi?id=347450

The last comment states that key zeroization is not needed for FIPS,
which is in contrast with the initial description.

What is the reason behind this - why is the key zeroization in NSS DB
not needed?


This isn't about zeroization of the database, it's about zeroing the 
internal databuffers from the database. Those buffers don't need to be 
zeroized because the data in them is encrypted. Keys in your nss 
database are stored encrypted, which is why you need to supply a 
password before you use it. If you don't have to supply a password, then 
the keys are still encrypted, but they key they are encrypted in can be 
trivially calculated given an NSS database (the password is set to the 
NULL string).


As for zeroization of the database itself, it depends on why you want to 
do it. If you are trying to meet a particular security policy are just 
paranoid, you can set the password to an arbitrarily random string that 
you don't save (like the output of 128 bytes of /dev/random converted to 
hex). Setting the password reencrypts each entry in the database with 
that password. At this point you can simply do a database reset. (which 
basically deletes the old database and creates a new empty database). If 
you just want to 'get rid of your keys' you ca simply do a database 
reset, though in that case it's possible that data blocks in your 
database are still floating around on your harddisk free list.


It should be obvious that both of these methods would get rid of all 
your private and secret keys. What may not be obvious is the secret keys 
used to encrypt your website passwords will also be gone... Even if you 
didn't have an NSS password set initially (those passwords are also 
always encrypted and if you loose or change your NSS key database you 
will loose those passwords as well).


Also it may not be obvious that this only affects the key database, not 
the cert database. The cert database stores cryptographicly public 
information (that is information that can be sent publicly without 
breaking cryptographic security). For example, your personal email and 
client auth certificates are stored in the cert database. You can't use 
them for signing, authentication, or email decryption however, without 
the associated private keys, so the certs will still be accessible, but 
they won't be usable as user certs (they won't show up in the user cert 
side of the firefox cert view, for example).


bob


Thanks  best regards,
Jan





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS support for RFC7512 PKCS#11 URIs

[Robert Relyea]

On 05/03/2015 02:17 AM, David Woodhouse wrote:

On Sat, 2015-05-02 at 18:33 -0700, Jan Pechanec wrote:

On Fri, 1 May 2015, David Woodhouse wrote:


On Fri, 2015-05-01 at 11:35 +0100, Alan Braggins wrote:

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
distinguishing multiple public-key/private-key pairs held by the same
subject
and it is possible that keys for different subjects may have the
same*CKA_ID*value without introducing any ambiguity?

That question would be better directed to the authors of the RFC. I've
added Jan to Cc.

Yes, in isolation both CKA_SUBJECT and CKA_ID are ambiguous since
multiple certificates can exist with the same subject, and multiple
certificate can exist with the same private key (hence the same
CKA_ID).

I'm not quite sure of the motivation for omitting CKA_SUBJECT from the
URI specification. Perhaps because it's redundant to a *certain*
extent with CKA_LABEL — in the relatively rare case that CKA_ID isn't
actually unique, hopefully CKA_LABEL is sufficient to disambiguate.

Hi David, that's a very good question.  It was a deliberate decision
back in the days of filing the first I-D in March 2010.

I didn't want to delve into a certificate.  I know there is a key ID
in X.509 v3 which is expected to be in CK_ID if present in the cert,
but I didn't want to go beyong an id.  Any other component path
attributes are directly PKCS #11 related.

I thought about adding CK_SUBJECT there while writing 00 based on what
we were doing with Darren (cc'ed) in Solaris those days.  But then,
CKA_START_DATE and CKA_END_DATE could be useful as well, to pick valid
certificates, for example, and also CKA_SERIAL_NUMBER and CKA_ISSUER,
and even CKA_HASH_OF_SUBJECT_PUBLIC_KEY.  Possibly something else.

The scheme definition would grow significantly and in general we were
concerned that the more complex the scheme would become to be, the
more difficult would be to use it.  Using the object attribute
seemed like the best way to identify a key, with an ID if needed, and
possibly library attributes.  Also note that comparing URIs would
become more difficult as the subject attribute would need to be
normalized (how exactly?).

So, we started with a basic list of attributes we thought were enough
to identify an object or token and expected people to tell us what
else was useful for them.  That's how we added library-* and slot-*
attributes (after a long discussion a few years ago, we deliberately
decided not to use a slot since its ID is not stable across PKCS #11
module initialization, but then again, someone asked for it and we
thought that it was just better to add it), and we also added query
component attributes, including the PIN in the URI, which we also
initially opposed to have but were convinced to add by early adopters.

And in those more than 5 years since the draft 00, no one asked for
the CKA_SUBJECT attribute.

Having said that, I assumed that other URI attributes might be needed
in the future, possibly with new versions of the PKCS #11 standard; I
didn't see anything new in upcoming 2.40 useful to be added to the URI
though.  So, if there is a strong feeling about a new attribute, there
is always a way of patching the parser and filing an I-D to extend the
scheme, and let the community decide.

In this situation though, I still believe that it's better not to put
the certificate subject in there, due to the reasons mentioned above.

Regards, Jan.

Hi Jan,

Thanks for the prompt response (as ever), which I've cited in its
entirety since I'm not sure it made it to the list.

For the case of NSS, I suspect the lack of CKA_SUBJECT shouldn't be a
real problem. I've just started looking at NSS with a view to fixing
it to take PKCS#11 URIs, and it looks like the common way of
specifying a certificate is by its nickname, which is CKA_LABEL,
using the PK11_FindCertFromNickname() function.


So in NSS, CKA_LABEL is simply a short cut to CKA_SUBJECT. That is NSS 
looks up a cert from the nickname and picks all the certs that match 
that cert's subject. The idea (back 2 decades ago when this was 
implemented) was that nickname was the user facing name for the cert 
'identity'. Multiple certs made up that identity (auth certs, 
non-repudiation certs, key exchange/encryption certs, expired versions 
of the above). As a result CKA_LABEL is not unique to a cert (anymore 
than a subject is). LABEL is not required as well (certain intermediate 
CA's may not have a label associated with them).


Currently the only unique way to identify a cert is CKA_ISSUER and 
CKA_SERIAL_NUMBER unless you want to include the value. The PKCS #11 
working group is active again at OAISIS. If we want a unique object 
identifier


I think we just need to either extend 

Re: Problems with FF and internal certificates

[Robert Relyea]

On 05/04/2015 10:09 AM, Brian Smith wrote:

On Fri, May 1, 2015 at 9:11 AM, Tanvi Vyas tv...@mozilla.com wrote:


On Apr 27, 2015, at 2:03 PM, Michael Peterson 

michaelpeterson...@gmail.com wrote:

Now, in the album I posted above (https://imgur.com/a/dmMdG), the last

two screenshots show a packet capture from Wireshark. It appears that
Firefox does not support SHA512, which is kind of supported by this article
(
http://blogs.technet.com/b/silvana/archive/2014/03/14/schannel-errors-on-scom-agent.aspx).
I'm not exactly sure this is true, and it seems like a silly thing for
Firefox to drop support though (this previously worked), especially if
every other browser in the world supports this.


I think this was an NSS bug where we didn't include the SHA512 hash in 
the advertized list of supported hashes. It wasn't dropped support. In 
previous versions of TLS you didn't advertise which hashes you 
supported, so things signed with SHA512 just worked.  Now you need to 
advertise it, and NSS was just missing the hash (it's fixed in the 
latest version of NSS).



So there's everything we've found, and some of my assumptions. Does

anyone know what is actually going on with Firefox. Is this a bug? Are we
doing something wrong? How do we fix this?


SHA-384 is SHA-512 truncated to 384 bits.


Not exactly. SHA-384 is mechanically the same algorithm as SHA-512, with 
a truncation, but it's not the same bits. SHA-384 has a unique set of 
initializers so if you do a SHA-512 and truncate it to 384 bits and the 
do a SHA-384  on the same data, you have the same security and 
performance characteristics, but not the same bits.


 (I think Brian knows this, and that his point is from a security point 
of view, they are exactly identical, both in performance and in the 
actual security of the hash. For the uninitiated, though, the actual 
bits on the wire are different).




I guess your ECDSA certificate is using the P-384 curve. If so, your
SHA-512 digest is truncated to ~384 bits in order to work with the P-384
curve. (If you are using the P-256 curve, then it is truncated to ~256
bits.)

Consequently, there's no advantage to using SHA-512 instead of SHA-384.


Other than compatibility with someone that chose to sign using SHA-512.

bob


Cheers,
Brian





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: target parameter to PK11_Derive

[Robert Relyea]

On 05/05/2015 08:42 AM, Andrew Cagney wrote:

Hi,

I'm cleaning up some code (it has a long history) that, among other things,
computes IKE's PRF (hmac) and PRF+ (key derivation function).  The
computation involves the use of PK11_Derive to perform lots of
concatenation, padding, xoring, and hashing(1).  To get an idea, the PRF+
function (which uses PRF, which uses HASH) is described in the RFC as:

prf+ (K,S) = T1 | T2 | T3 | T4 | ...

where:

T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04)

For specifics: PRF http://tools.ietf.org/html/rfc2104 PRF+
http://tools.ietf.org/html/rfc7296#page-48

The code works - at least in the sense that it computes the same values as
the test vectors found on http://csrc.nist.gov/groups/STM/cavp/index.html

The thing I'm not sure about is how the code is using PK11_Derive target
parameter for its intermediate(2) operations.

For instance, when doing concatenation and xoring, the derive parameter
might have sane with values like:

   CKM_CONCATENATE_DATA_AND_BASE
   CKM_CONCATENATE_BASE_AND_DATA
   CKM_CONCATENATE_BASE_AND_KEY
   CKM_XOR_BASE_AND_DATA

while the *target* parameter gets values like:

   CKM_EXTRACT_KEY_FROM_KEY
   CKM_ SHA1_KEY_DERIVATION (when BASE_AND_KEY)
   CKM_CONCATENATE_BASE_AND_DATA

Similarly, when performing the hash using PK11_Derive, the derive
parameter is something sane like:

   CKM_SHA1_KEY_DERIVATION

yet the *target* parameter is:

   CKM_CONCATENATE_BASE_AND_KEY

Does any of this matter?  Is there a preferred value?  (If there is I could
simplify some code further).  And are there any, mumble mumble, security,
mumble, mumble, implications?


The target Mechanism is the operation you are going to use the target 
key for, It shouldn't match the mechanism used to derive the key. It is 
basically used to set the appropriate key type and flags on the 
resultant key. Example psuedo code:


key1 = derive(keybase, mech=CKM_XOR_BASE_AND_DATA, 
target=CKM_SHA1_KEY_DERIVATION, data);

key2 = derive(key1, mech=CKM_SHA1_KEY_DERIVATION, target=CKM_AES_CBC, NULL);
decrypt(key2, mech=CKM_AES_CBC, input, output);

 Ideally you should try to keep it consistent with how your are 
planning on using the key, but in practice as long as the key is 
basically the same kind of key, the extact value of target is not 
necessary (You can use a key generated with target CKM_AES_CBC on an 
CKM_AES_ECB operation, for instance). Target may also be used to try to 
set the appropriate key length (if key length isn't supplied).


Most of these key derive operations either ignore keyType or take 
CKK_GENERIC_SECRET keys, so bad things aren't likely to happen if you 
mix up target a bit, but certainly the final resultant keys should 
target the proper crypto targets our your decrypt operation will fail 
with an inappropriate key type.


bob


Andrew

PS: If there's documentation I've missed, please let me know :-)

--

(1): It's computing the hash using calls like PK11_Derive
(derive=CKM_SHA1_KEY_DERIVATION) rather than the lower level hash
interface.  This is because PK11_Derive returns a PK11SymKey, hopefully
keeping the result secure.

(2): Once the keying material has been created things become more sane, for
instance when extracting (CKM_EXTRACT_KEY_FROM_KEY) an AES_GCM key the
target is CKM_AES_GCM; and when extracting IV that ends up on the wire the
target is CKM_VENDOR_DEFINED.





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: target parameter to PK11_Derive

[Robert Relyea]

On 05/07/2015 11:49 AM, Andrew Cagney wrote:

[inline]

On 5 May 2015 at 13:18, Robert Relyea rrel...@redhat.com wrote:

The target Mechanism is the operation you are going to use the target key

for, It shouldn't match the mechanism used to derive the key. It is
basically used to set the appropriate key type and flags on the resultant
key. Example psuedo code:

key1 = derive(keybase, mech=CKM_XOR_BASE_AND_DATA,
target=CKM_SHA1_KEY_DERIVATION, data);
key2 = derive(key1, mech=CKM_SHA1_KEY_DERIVATION, target=CKM_AES_CBC,
NULL);
decrypt(key2, mech=CKM_AES_CBC, input, output);

  Ideally you should try to keep it consistent with how your are planning
on using the key, but in practice as long as the key is basically the same
kind of key, the extact value of target is not necessary (You can use a key
generated with target CKM_AES_CBC on an CKM_AES_ECB operation, for
instance). Target may also be used to try to set the appropriate key length
(if key length isn't supplied).



Thanks for the clarification; my reading of the documentation wasn't too
far off.

For the intermediate values I think I'll try something like
CKM_VENDOR_DEFINED; and, to your point, ensure all the final keys have
meaningful values.
I'm not sure CKM_VENDOR_DEFINED will be the right thing. The 
intermediate values are likely CKK_SECRET_KEYS with CKA_DERIVE set to 
true, It's probably best if you want to use the same value to use 
something like CKM_XOR_BASE_AND_DATA or something similiar.


bob




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PK11SymKey in FIPS mode from nothing

[Robert Relyea]

On 05/12/2015 08:58 AM, Andrew Cagney wrote:

Hi,

I'm looking to clean up some test code (IKEv2, NISTs CAVP tests), so that
they work in FIPS mode (what ever that means).
So CAVS tests require hooking outside  the FIPS mode boundary because 
CAVS tests access CSPs which aren't allowed outside the boundary in 
FIPS. When we run NSS CAVS, we run them through private interfaces that 
aren't available when the module is up and running in FIPS mode.


The test inputs look like:

Ni = 3651fef5c9c35e93
Nr = c09a8b90a3f04d59
g^ir =
d084a30166a50fb7325c3960874a839449ef9741c2f4f947d0201dd8c1269273d79509f37e3ca3eb4fa2fe2a28254e289cd3f34dad4eb4df1a07685a4b8a94fa61e2491f7598b3ce65547ff133b3f63d1ac4175eaa695033f3cedb026a6873a36455172a8540b8a5d23a0143bed0390ee49b168269d75fffee9fb62be965993c
g^ir (new) =
52f00ab174c25d5b7139ae5ff4e8e9eddee5992d2e36adf8a559ffd90dab1442e4fbe429d320c0f33552a17d1557fa41ea70e8fb916c4fa27ed52b5f8ebd8461afa78f1159159a64055ac5f6319e29c28eae58cbc6847770f32c3fed1d04750484f854790f95e9ec01bc5bc461f24966462e359511329305038e94deb6dd42c2
SPIi = 8e5c3ae507221684
SPIr = b1f201bb155c3acd

The problem is with g^ir.(which is the DH exponentiation).  The
calculations rely on g^ir being in a PK11SymKey.

In the real world (as in the non-test code),  i is created as a
PK11SymKey, and hence a g^ir PK11SymKey can be derived from that.  Here,
though, I've no secure starting point - I'm just given the raw byte value
of g^ir.

So, in FIPS mode, in a standalone test program, what is the correct way to
turn g^ir into PK11SymKey.

Andrew

PS: The current code uses the hack (something like) from the NSS examples:

 PK11SymKey *sym_key = PK11_ImportSymKey(slot,
CKM_DH_PKCS_DERIVE,
 PK11_OriginUnwrap,
 CKA_ENCRYPT, key_item,
NULL);

which is of course not valid in FIPS mode.


This should be fine for CAVs testing, as long as it is running the same 
code as it would run if it's in FIPS mode (which it will).


bob




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS set extractable = no

[Robert Relyea]

On 05/18/2015 03:04 PM, Arthur Ramsey wrote:
I have a requirement to disable key export on a key stored in a NSS DB 
in FIPS mode.  I read through the documentation and found mention of 
the ability to do this, but not how.  Where can I find information on 
how to disable key export?  I will be using the NSS module via Java to 
obtain FIPS 140-2 compliance.  I imported the key via p12 format, but 
I could complete the entire process via NSS if needed.


We only support sensitive, not extractable in the NSS FIPS.

If you are talking about database keys, the actual key is stored p12 
encrypted in a database, so there would be no way to prevent someone how 
has both the database and the password for the database from extracting 
the key.


That being said several versions of NSS already has FIPS 140-2. I 
believe FIPS 140-2 allows extracting keys with wrapping keys.


bob


Thanks,
Arthur






smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: placing NSS in fips mode using modutil is forgotten ?

[Robert Relyea]

On 06/10/2015 06:15 AM, Paul Wouters wrote:


Hi,

I'm trying to do various FIPS tests for libreswan. Our testing system
using KVM is a little tricky to selectively boot with fips=1, so I
did some scripting to get everything into faked FIPS mode.

It basically comes down to first running a script that:

- creates /etc/system-fips
- disable selinux (for next step)
- fake /proc/sys/crypto/fips_enabled by
  echo 1  /tmp/fips_enabled
  mount --bind /tmp/fips_enabled /proc/sys/crypto/fips_enabled
- running modutil:
  /usr/bin/modutil -dbdir /etc/ipsec.d -fips true -force
  /usr/bin/modutil -dbdir /etc/ipsec.d -chkfips true
  (which DOES output: (FIPS mode enabled.)
- starting libreswan via systemctl start ipsec.service

libreswan, which has its own checks for /proc/sys/crypto/fips_enabled
and /etc/system-fips confirms it is in FIPS mode.

But somehow, the NSS library is still not in FIPS mode. I suspect the
dance through systemd might cause this? Do some environment variables
get set and lost? Is there a way to export some environment variables
to force NSS harder?
The most likely cause is nss wasn't opened using /etc/ipsec.d as it's 
database. If this is a library, this could be caused by the application 
opening it's own database first, which means the default slot will be 
whatever the application openned. If you check the slot for your 
database, it should still be a FIPS slot.


bob


Paul





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PK11SymKey in FIPS mode from nothing

[Robert Relyea]

On 05/12/2015 10:44 AM, Paul Wouters wrote:

On Tue, 12 May 2015, Robert Relyea wrote:

 So, in FIPS mode, in a standalone test program, what is the correct 
way to

 turn g^ir into PK11SymKey.



  PK11SymKey *sym_key = PK11_ImportSymKey(slot,
CKM_DH_PKCS_DERIVE,
PK11_OriginUnwrap,
  CKA_ENCRYPT, 
key_item,

 NULL);

 which is of course not valid in FIPS mode.


This should be fine for CAVs testing, as long as it is running the 
same code as it would run if it's in FIPS mode (which it will).


I'm not sure you understood. We have two problems.

If we want to run CAVS testing on building packages, and the builder
machine runs in FIPS, we have a problem.

We would like to run these CAVS tests on daemon startup, even in FIPS
mode.
So you are talking about FIPS Power on self tests/ Known answer tests? 
You can do that as follows:


1) derive your test known answer key.
2) use the known answer key to encrypt a some known data.
3) compare the encrypted data with the known encrypted answer.

You can't access the generated key in FIPS mode because that violates 
the softoken FIPS boundary.


For your actual CAVS testing, you actually need the real key data. In 
that case you have to work within the FIPS boundary.
(Of course this all goes away when we push the IKE derive function into 
softoken itself and have softoken run the CAVS and POST, freeing 
libreswan from needing a separate validation.


bob


Paul





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: pk12util: Wrong certificate names in database

[Robert Relyea]

On 07/27/2015 12:54 AM, Trick, Daniel wrote:

Thank you a lot for clarification, Kaspar!

So, by design of NSS, all certificates with the same DN will end up 
with the same nickname. And the very first certificate with a specific 
DN will set the nickname for all other certificates (with that same DN).


Now, I see that this works as long as we have one certificate for 
encryption, one for signing and one for auth. The application (e.g. 
Thunderbird) still picks the correct certificate, probably by looking 
at the key usage flags, although they all have the same name.


But how am I supposed to deal with the situation that the users gets a 
new certificate for the same DN? If there are several certificates 
for, e.g., encryption, all with the same DN - and thus also with the 
same nickname - how do we distinguish?


NSS returns the newest cert valid cert for the given operation.



(I'm asking this, because I also need to be prepared for the case that 
user certificates are refreshed when they expire - or shortly before 
they expire. So, for a limited amount of time, we may need to keep the 
old /and/ the new certificate in the store)


Yes, that's pretty common, including in Thunderbird (where you have a 
lot of old encryption certs).


There are not so good, and not uncommon corner cases to watch out for: 
If you have 2 certs with the same DN, but different rolls where both are 
active at the same time, you can't use nicknames to select the cert. If 
you want to delete a cert, you can't use nickname to uniquely identify 
the cert you want to delete. When you need fine grain control, the 
application should use issuer/serial number to identify the cert (I 
think all the mozilla apps have gone to this now).


bob


Regards,
Daniel


Am 26.07.2015 um 08:38 schrieb Kaspar Brand:

On 20.07.2015 14:05, Trick, Daniel wrote:

I'm facing a new problem regarding pk12util from NSS Tools:

When I import the _first_ certificate of a user into the database with
pk12util, then certificate's name in the NSS database will be:
*NSS Certificate DB: friendly_name_taken_from_p12_file
*
Okay,  but as soon as I import the _second_ certificate (or any further
certificate), it won't be added to the DB with a distinct name. 
Instead,

the entry that was created when importing the _first_ certificate will
appear several times! :-\

[...]

*Is this an intended behaviour of pk12util, and if so, how can I 
achieve
the required result? If it's *not* intended and actually a bug, 
should I

file a bug report now?*
*

Yes, it is by design. All certificates with the same subject DN are
expected to share a common nickname, otherwise you would end up with a
corrupt DB, see e.g. 
https://bugzilla.mozilla.org/show_bug.cgi?id=594297.


Kaspar





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Add New OID to NSS

[Robert Relyea]

On 11/04/2015 11:21 AM, JBarry wrote:

Hi Bob,

Thank you for the helpful reply. I have looked at the files you have
mentioned and am a little confused about something.

For example (secoid.c lines 34-35):
/* USGov algorithm OID space: { 2 16 840 1 101 } */
#define USGOV   0x60, 0x86, 0x48, 0x01, 0x65

In this snippet, the OID appears to be 2.16.840.1.101. However, the hex
translation does not equal the decimal string because 0x60, 0x86, and 0x48
do not translate to 2, 16, 840 respectively, but 0x1 and 0x65 do convert to
1 and 101. Clearly I am missing something here  in how to convert between
the two.

I am also waiting to hear back from my supervisor as to whether or not I can
disclose the OID and its purpose.

Thanks again,
Jim
The oid is encoded according to DER rules for encoding oids. In general 
the first 2 bytes encode to a single byte, and bytes under 128 encode to 
themselves.


Microsoft had a decription here: 
https://msdn.microsoft.com/en-us/library/windows/desktop/bb540809%28v=vs.85%29.aspx
A program which does it can be found here: 
http://www.rtner.de/software/oid.html (I have not verified the program 
myself).


bob




--
View this message in context: 
http://mozilla.6506.n7.nabble.com/Add-New-OID-to-NSS-tp346875p346880.html
Sent from the Mozilla - Cryptography mailing list archive at Nabble.com.





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Add New OID to NSS

[Robert Relyea]

On 11/04/2015 08:57 AM, JBarry wrote:

Hello,

I'll apologize in advance if this question has already been asked/answered
(I did look and found nothing that helped me out) or if the question seems
trivial. I am a college intern currently working with NSS for the first
time, so please forgive me if I state anything incorrectly or in a confusing
manner.
  
So I have created a key/certificate using OpenSSL and am trying to import it

into the NSS database. However, this is failing because we are using a local
algorithm that NSS (and pk12util) does not recognize. I need to add the OID
to NSS in order for it to recognize the algorithm we are using, but I am
unsure of where to do this. I have scoured the code and have looked in a
bunch of files (some of which contain OID "definitions"), but I cannot
figure out how to add the OID to make the import process work.

Any help would be greatly appreciated,
Jim


The oids are in the oid table found in secoid.c, and defines are in 
secoidt.h. The table is a static array of SECOidData called 'oids'.

You'll need to add new entries at the bottom. with the OD() macro.

The parameters of the OD macro are:
   1) CONST_OID (basically an array of bytes) of the encoded oid 
representation. (so '2.16.1.101' is 0x60, 0x86, 0x48, 0x01, 0x65). You 
declare a CONST_OID in the block above the table with  a name 
representing your new oid (this value is private to this function. There 
are already macros for several  common spaces (like PKCS5 or ANSI_X962).
   2) The NSS OIDTag. This is the name NSS applications use to 
reference the tag. You also need to add this to the SECOidTag enum in 
secoidt.h. The oid tag value should equal the index into the oids[] 
table. NSS checks this at runtime.

   3) A string decryption of what the oid represents.
   4) The PKCS #11 mechanism value that this oid maps to. If there 
isn't a PKCS #11 mechanism, then this value should be 
CKM_INVALID_MECHANISM. For pkcs12 there should be a corresponding PKCS 
#11 mechanism.

   5) The Certificate extension value. It should be one of the following:
SUPPORTED_CERT_EXTENSION - this oid is a certificate extension 
that is recognized an parsed by the NSS chain validation code.
FAKE_SUPPORTED_CERT_EXTENSION - treat the extension represented 
by this oid as a recognized extension if NSS_ALLOW_UNSUPPORTED_CRITITCAL 
is set. If NSS_ALLOW_UNSUPPORTED_CRITICAL is not set, then it is treated 
as UNSUPPORTED.
UNSUPPORTED_CERT_EXTENSION - this oid represents an extension 
which is not recognized. certs with this extension that are marked 
critical should fail certificate validation.
 INVALID_CERT_EXTENSION - this oid is not a certificate 
extension oid, don't treat is at one.


This will make the oid recognizable, it does not mean that the oid will 
be properly handled by the underlying code.


What is the actual oid you want to add and what does it represent?

bob






--
View this message in context: 
http://mozilla.6506.n7.nabble.com/Add-New-OID-to-NSS-tp346875.html
Sent from the Mozilla - Cryptography mailing list archive at Nabble.com.





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Can sign but cannot encrypt email using a valid S/MIME certificate

[Robert Relyea]

On 09/04/2015 05:06 AM, Thibault Derrien wrote:


Dear all,

I have obtained numerical certificates of national certification
authority in Czech Republic (ICA).

1/ I have imported the certificate into Mozilla Thunderbird > Account
Settings > Security > Digital Signing.
- It shows Software Security Device:TwinsQS 10/07/2015.
- Digitally sign messages (by default) is ticked.

In Certificates > View Certificates, I obtain "Your certificates". I
click on my certificate, and read:
"General > This certificate has been verified for the following uses:
SSL client certificate,
SSL server certificate,
Email Signer certificate,
Object Signer. "
Your cert doesn't have 'Email Recipient Certificate'. That means your 
certificate probably doesn't have Key Encipherment (see 
Details->Extensions->Certificate Key Usage).


However, Mozilla Thunderbird > Account Settings > Security > Encryption
is greyed.
Clicking on "Select..." leads to error message
"Certificate Manager can't locate a valid certificate that other people
can use to send you encrypted email messages."
There are two types of certificates used for email. One for signing and 
one for encryption. it's possible that a single email can be used for 
both. Your cert apparently only has signing. You will need a separate 
cert for encryption. (or get a new cert with both). Your encryption cert 
should have the same subject as your signing cert (ideally).


2/ If I send a new email to a coworker also working with Thunderbird on
Linux, (or another on Outlook on Windows), he obtains :
Email is signed. Signature is valid.
When your friend reads the signed email, that loads the email cert along 
with our smime configuration into his database, at least in thunderbird. 
In your case, there isn't an encryption cert included.


However, my computational center want to send me a password by using my
certificate to encrypt their email. Problem is that they don't have the
file for this. Which file should I send them ?
Send them a Signed message, that will give them your certificate (again, 
assuming you have an encryption capable cert).

Which file format should
I send ? I have too many formats existing. DER, CER, PFX, P7C, PK7, 
CRT...

- Why Thunderbird cannot import my certificate to encrypt emails ? That
would solve my issue.
- Why is there no option to attach my key into Thunderbird ? It is
present in OpenPGP but I would like to use S/MIME without this OpenPGP.

Thanks a lot for your help!

Best regards,
Thibault







  
--

Upozorneni: Neni-li v teto zprave vyslovne uvedeno jinak, neni tato e-mailova 
zprava navrhem na uzavreni smlouvy ani prijetim pripadneho navrhu na uzavreni 
smlouvy a nezaklada predsmluvni odpovednost FZU AV CR, v. v. i.
Disclaimer: If not expressly stated otherwise, this e-mail message cannot be 
considered as a proposal to conclude a contract, neither the acceptance of a 
proposal to conclude a contract, nor does it create any pre-contractual 
liability on the part of FZU AV CR, v. v. i.






smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Prevent "proxyfying" PKCS#11

[Robert Relyea]

On 09/25/2015 01:36 AM, helpcrypto helpcrypto wrote:

Hi all


I hope you can find a solution for my problem, cause I can't. (And perhaps
it's impossible)


Based on my knowledge of PKCS#11 standard, the spec is exposed to a MITM
attack that steals the PIN when an application invokes C_Login against a
PK#11 library.


While using CryptoAPI it's the system who shows the "PIN dialog" making it
harder to crack/extract the PIN, C_Login function receives the PIN in
plaintext, and "an evil software", like PKCS11SPY, could get access to it.

Sadly, using Pinpads is out of scope/beyond our possibilities.
While dialog pin prompts don't really help all that much (if the 
attacker has your machine, they can pop up their own dialogs, just 
because the PKCS #11 software enforces a login, doesn't mean that the 
cards do. At the bottom the application can always talk directly to the 
card).


If you want dialog pin prompts, you can always just use protected pin 
path tokens, but then your application will only work with protected pin 
path tokens.


If your machine is compromised to the point that the attacker can insert 
PKCS11SPY into your PKCS #11 chain, there's very little you can do.




Of course my app could check pkcs#11 library checksum and other mechanisms
to "ensure" it is the library and not a proxy, but if my application is
opensource (I'll love to), I'm fu*ked.


Open source doesn't make this any worse, your proprietary app can be 
changed to accept the new checksum, or skip the checksum step 
altogether. In order to proxy PKCS #11 this way you need to be able to 
install a PKCS #11 module that does the proxying.


Is there any way to "trust" in the client? Can the server know the exe
being executed is MY exe and an EVIL copy? (A private key embebed can also
be cracked!)


Short answer: No. Long answer: The best you can do is under certain 
conditions the server can know the authentication key is in a token, but 
only if the server is part of the infrastructure that issued the cert 
and key and performed the appropriate checks to verify the key is in the 
token (and only in the token).





Furthermore, our *lovely* card sends APDU for login in plainText, so anyone
could see "1234" easily. And we are not able to establish a secure channel
cause we lack the required keys.
Every card does that. The connection between the computer and the reader 
is considered 'secure'.


bob



Seems what I really need is something like a Javacard applet with an
embebed "server public key", a component certificate and a session keypair
for mutual authentication and cipher communications between server and
client, but we aren't able to load this applet on the Card.


You'd need your own protocol for this. Card management systems usually 
do this with their own protocol where the server talks to the card 
directly through a global platform secure channel. This only works 
because the server is part of the trusted base for the card management 
system (e.i. the server knows the keys that even the user doesn't know 
for his card). Even then, you don't know that the user saw want 
documents he thinks he's signing because in your scenario the client 
computer is fundamentally untrusted. In the case where the computer is 
untrusted you can't get any guarantees. That's why most protocols assume 
that the client is at least trusted by the user of the client.


So, to sum up it seems it won't be possible to do what I need: a server
asking to sign 10 documents and being sure only those are signed.

I understand this is Anders (& CO) argument about "smartcards were not
designed for Web"


In the other hand, do you think is possible to "extend" WebcryptoAPI to
generate/use keys to/from browser or system keystore?
IMHO, how it actually works, sucks.


Regards (and thanks)

PS: Never trust the client...that also sucks.





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Prevent "proxyfying" PKCS#11

[Robert Relyea]

On 09/25/2015 09:13 AM, Erwann Abalea wrote:

Le vendredi 25 septembre 2015 14:39:04 UTC+2, helpcrypto helpcrypto a écrit :

On Fri, Sep 25, 2015 at 11:52 AM, Erwann Abalea  wrote:

[...]

Although it won't solve my problem, this will make possible to kill
signature applets forever, which indeed it's my real objective.

This objective will soon be reached. Java isn't supported anymore in Chrome 45 
and is supposedly to be deprecated in Firefox soon, and ActiveX (whence Java 
also) won't be supported in Edge.
I thought helpcrypto was suggesting using a javacard applet, not java 
that runs on the client. Of course to install a javacard applet you need 
the card keys, which I believe he said he didn't have.


bob




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: AES-256 vs. AES-128

[Robert Relyea]

On 11/30/2015 12:07 PM, Julien Vehent wrote:

On 2015-11-30 12:47, Robert Relyea wrote:
I've always found the 128 bit prioritized over 256 a silly 
recommendation, I support reordering.


Can you expand on why you think it is silly?


The argument went that 128 bit was 'sufficient' and there was a 
performance 'hit' doing 256. Sufficient changed our criteria from 
objective (stronger first, then performance) to subjective (random 
definition for sufficient). At one point DES 56 was considered 'sufficient'.


The case in point, we've subjectively decided 128 bit isn't sufficient. 
That was highly predictable (attacks get better, the subjective line 
will move again).


At Red Hat, we've already reordered this. We were having problems 
connecting to servers who had the following logic: SSL connect to 
client. Check to see if the key strength was sufficient. If not display 
an error message through the SSL connection. The server was assuming if 
a client connected with a 128 cipher, then it must not be able to do a 
256 bit cipher because why would it prioritize 128 bits over 256 bits? 
The server didn't turn off the weaker ciphers because the server wanted 
to give the weaker clients a reasonable error message.




The original thread [1] had a long discussion on this topic. 


Yes, which is why I didn't push it. I gave my reasons for disagreeing. 
They weren't accepted. I saw no reason to get religious about it. Still 
didn't mean I didn't think the decision was silly. I find life goes 
better if you only fight against patently wrong decisions and let silly 
ones go with just giving notice.


bob




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Algorithms supported in NSS 3.17, FIPS mode

[Robert Relyea]

On 12/14/2015 05:04 PM, Paul Wouters wrote:

Don't know about DRBG, but everything else you asked for is supported.

Sent from my iPhone


On Dec 14, 2015, at 18:03, jonetsu  wrote:

Hello,


I am trying to get a list of the algorithms and ciphers supported by NSS 3.17 
in FIPS mode.  Not easy.  Whereas OpenSSL and GnuTLS lists them at run-time, no 
such thing seems to exist for NSS (correct me if I'm wrong).  Is there then a 
document, validation certification, that would list them ?  More to the point, 
I would like to know if AES in CBC mode is supported (128 and 256), AES in GCM 
mode (also 128 and 256), SHA1 and which SHA2, and hash-based DRBG.
DRBG is also supported. NSS only supports hashed based DRBG for it's 
random function (whether in FIPS mode or not).


bob



Any information much appreciated, thanks.





--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: AES-256 vs. AES-128

[Robert Relyea]

On 11/25/2015 02:01 PM, April King wrote:
My colleague Julien Vehent and I are in the process of updating the 
Mozilla Server Side TLS documentation:


https://wiki.mozilla.org/Security/Server_Side_TLS

One of the topics of conversation was whether or not the Modern TLS 
configuration should prefer AES-256 over AES-128.  Recently, there has 
been some doubt cast over the security of AES-128, between posts by 
security researchers like djb, as well as the recent decision by the 
NSA to recommend AES-256 over AES-128, due to its increased resistance 
against quantum cryptography:


http://blog.cr.yp.to/20151120-batchattacks.html
https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml


I've always found the 128 bit prioritized over 256 a silly 
recommendation, I support reordering.


bob


The general consensus was to bring the conversation to the 
dev.tech.crypto group prior to updating the standards either way. 
There hasn't been any claim that AES-128 is actually broken, but the 
idea behind the Modern guidelines is to stay ahead of the 
cryptographic research curve.  One thing to keep in mind is that the 
Modern guidelines are intended for modern systems that don't require 
any kind of backwards compatibility or necessarily need to be friendly 
towards old, underpowered systems (such older smartphones).


For reference, this is the current state of preference order for the 
four major browser manufacturers:
Firefox: AES-128-GCM > AES-256-CBC > AES-256-CBC (doesn't include 
AES-256-GCM in list of cipher suites)
Chrome: AES-128-GCM > AES-256-CBC > AES-128-CBC (also does not request 
AES-256-GCM)

Safari: AES-256-GCM > AES-128-GCM > AES-256-CBC > AES-128-CBC
Edge: AES-256-GCM > AES-128-GCM > AES-256-CBC > AES-128-CBC

Proposal for Modern:
AES-256-GCM > AES-128-GCM > AES-256-CBC > AES-128-CBC

If the general agreement is to move Modern to AES-256, it may also be 
worthwhile considering whether or when we move that recommendation 
down to the Intermediate level, which is intended for general purpose 
websites that don't have a need for backwards compatibility with very 
old clients (such as IE6/Win XP SP2).







smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Replacement for PK11_GetLowLevelKeyIDForCert etc

[Robert Relyea]

On 06/24/2016 06:29 PM, Andrew Cagney wrote:

Hi, according to the NSS documentation, the functions for getting
CKAIDs are deprecated vis:

/**
  * New functions which are already deprecated
  **/
SECItem *
PK11_GetLowLevelKeyIDForCert(PK11SlotInfo *slot,
 CERTCertificate *cert, void *pwarg);
SECItem *
PK11_GetLowLevelKeyIDForPrivateKey(SECKEYPrivateKey *key);

I'm just wondering what I should be using instead?
What are you after? They are deprecated mostly because they provide 
access to low level PKCS #11 values.

 If you are after the actual PKCS #11 CKA_ID attribute then you could use:

PK11_ReadRawAttribute() for the key. Unfortunately useing 
PK11_ReadRawAttribute() for cert doesn't work yet, but could be added.


bob



Andrew

PS: What does CKA actually stand for :-)

CryptoKi Attribute All PKCS #11 attributes start with CKA_ .




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Using NSS in FIPS mode

[Robert Relyea]

On 01/21/2016 07:33 AM, jonetsu wrote:

Hello,

Please let me know if this is not the right place to ask about the
following...

This is the right place.


I am new to NSS and would like to use it in FIPS mode.  I do know
about OpenSSL and GnuTLS, both of them having explicit calls to
enabled FIPS mode.  With NSS, so far I have seen that the modutil
non-programmatical utility is used to set FIPS mode, as in:

% modutil -force -fips true -dbdir 

How does an application assures that NSS is in FIPS mode ?
FIPS is a mode in softoken. Usually when softoken is in FIPS mode, NSS 
itself is said to be in FIPS mode.


The call PK11_IsFIPS() returns true if softoken is in FIPS mode. The 
dance to programatically is to call
SECMOD_DeleteInternalModule(), which toggles the module between FIPS and 
non-FIPS modes.

  Are calls
such as sftk_fipsCheck() and sftk_fipsPowerUpSelfTest() in the
softtoken module (fipstokn.c) available to applications ?

No.


What is the behaviour of NSS if an application tries to use a
non-approved algorithm ?
Currently NSS does not restrict you from using non-approved algorithms. 
Officially going to FIPS mode requires the application to turn off any 
uses of non-FIPS algorithms itself. In the SSL code the 
SSLCipherSuiteInfo includes an isFIPS bit applications can use to 
manually turn off non-FIPS algorithms.


Finally, is there any example code out there that uses NSS in FIPS
mode ?
Firefox has a button to flip to FIPS mode. For the most part the only 
issue applications may have in FIPS mode is if the application tries to 
access key material directly (or if the application doesn't handle 
authentication well). An Example of going into FIPS mode can also be 
found in the nss source tree under the cmd/modutil directory.


bob


Any comments, suggestions appreciated, thanks.





--
View this message in context: 
http://mozilla.6506.n7.nabble.com/Using-NSS-in-FIPS-mode-tp350446.html
Sent from the Mozilla - Cryptography mailing list archive at Nabble.com.





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Using NSS in FIPS mode

[Robert Relyea]

On 01/22/2016 06:42 AM, jonetsu wrote:

Robert Relyea wrote:


The call PK11_IsFIPS() returns true if softoken is in FIPS mode. The
dance to programatically is to call SECMOD_DeleteInternalModule(),
which toggles the module between FIPS and non-FIPS modes.

Thanks.  I will try it.

When are the self-tests run, from an application perspective ?  I presume
they are when FIPS mode is put in effect using modutils. Would that be the
only time they are run ?  For instance, would they be called before
returning from PK11_IsFIPS() ?  Is there a way to force-run those self-tests
from an application ?

That answer is a little different depending on version.

In RHEL 5, 6, and 7:

They are ran when softoken is loaded (whether or not NSS is in FIPS 
mode). If NSS returns PK11_IsFIPS = true, you can know that the post 
tests ran successfully at library load time. Failure of the post tests 
will prevent the softoken from initializing in FIPS mode, which will 
prevent NSS_Initialize (in all of it's flavors from initializing).


Eventually this code will be pushed upstream and will wind up in Fedora.

Currently upstream and they way it used to work in RHEL:

It was ran at C_Initialize time, which happens at NSS_Initialize. If NSS 
isn't in FIPS mode, switching to FIPS mode will cause the code to run 
immediately.


On RHEL 7, NSS looks at the system flag for FIPS mode. If the system is 
in FIPS mode, NSS will force softoken to be in FIPS mode even if it 
would not have been otherwise. If the system is not in FIPS mode, NSS 
softoken can still be placed in FIPS mode with it's traditional switch.


The main difference between FIPS mode and non-FIPS mode for softoken 
actually involves Level 2 issues. CPS are not allowed to leave softoken, 
so calls that extract keys (for instance) will fail. The token also 
requires authentication whenever to do an operation that accesses CPS's 
(like encrypt/decrypt/hmac/sign). So if the browser is in FIPS mode, it 
will authenticate to the database before it does a simple SSL operation, 
for instance, even though you may not be accessing private keys.





Firefox has a button to flip to FIPS mode.

I should have mentioned that the application is in C and is by no way
related to Firefox.
I just meant that Firefox has code you can look at to switch into FIPS 
mode as an example.


Comments much appreciated, cheers.




--
View this message in context: 
http://mozilla.6506.n7.nabble.com/Using-NSS-in-FIPS-mode-tp350446p350498.html
Sent from the Mozilla - Cryptography mailing list archive at Nabble.com.





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: server-side OCSP stapling

[Robert Relyea]

On 03/01/2016 02:19 PM, Martin Thomson wrote:

AIUI,  support for stapling in NSS is pretty primitive. You are expected to
make the OCSP query yourself and use the API to configure the server.


IIRC the API to fetch the ocsp response is mostly application code. NSS 
has a simple http request function that can fetch the request if the 
application doesn't supply one (which doesn't know about proxies, etc.). 
You could override the http fetch function, then validate your cert 
change and squirrel way the OCSP response before you pass it off to NSS. 
That's probably the simplest way of getting it.


I think You just need the blob, not the parsed blob.

bob

On Mar 2, 2016 7:42 AM, "Rob Crittenden"  wrote:


I don't see a way to implement OCSP stapling on the server side.

SSL_SetStapledOCSPResponses() is I think what one would use to set the
response in the SSL session but I don't see a way to get the response
from the OCSP handler. At least, I don't see a way without implementing
my own status checker and overriding statusConfig->statusChecker ala
CERT_EnableOCSPChecking().

Am I missing something?

thanks

rob
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto






smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS_NoDB_Init(".") and FIPS mode

[Robert Relyea]

On 03/18/2016 09:14 AM, Andrew Cagney wrote:

Is it possible to put NSS (softtoken) in FIPS mode (PK11_IsFIPS()) without
a "modutil -fips true" database?

By FIPS mode I guess I really mean confirm that NSS has performed some sort
of FIPS self-check.

An earlier thread mentioned some way of toggling things using
SECMOD_DeleteInternalModule()?
Yes, SECMOD_DeleteInternalModule() is a toggle which switches NSS 
between FIPS and non-FIPS. If you don't have a database open, or the 
database is open readOnly, the change only affects the running program.


bob


Andrew





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: RFC7512 PKCS#11 URI support

[Robert Relyea]

On 04/04/2016 03:19 PM, Ryan Sleevi wrote:

On Mon, Apr 4, 2016 at 12:39 PM, David Woodhouse  wrote:

We usually reserve the term "breaks the API" for when something *used*
to work, and now doesn't. Not when a previously-failing call now
actually does something useful.

No, sorry David, that's not how we've done stuff in NSS.
I think I would push back on this a bit. David change is very close to 
other changes we've made in the NSS API, in fact this very API. This API 
originally only took a nickname. The token: was an extension added in 
such a way that existing applications that knew nothing about token: 
could still function.


It was purposefully done so that applications that simply passed through 
the nickname from the command line or from the user would get access to 
the new functionality.


When it has an observable difference, when it breaks the contract
previously provided, we prefer not to do so.

I would disagree it breaks the contract.

I'm presuming the issue here is that you are screening nicknames to 
prevent certain nicknames from being accessed. That presumably means you 
are restricting nicknames to certain tokens? since pkcs11 is not a valid 
token, it would not be in our allow list.


In general I wouldn't recommend using a nickname filter to restrict 
access to certain certs, I'm pretty sure I can break out of any such 
filter you set up with the existing code.


This code wouldn't affect filters on nicknames for object creation.

I think rather than arguing from first principles (because you aren't 
getting any agreement that the priniciples you are starting from are the 
same ones the rest of us are seeing, let's just have an concrete example 
of a broken case in your existing filtering code where would be fooled 
into allowing something it didn't want to allow once this change is made.


bob




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: RFC7512 PKCS#11 URI support

[Robert Relyea]

On 04/07/2016 03:49 PM, David Woodhouse wrote:

On Thu, 2016-04-07 at 05:01 -0700, Julien Pierre wrote:

The problem really stems from the design of NSS, specifically the
CERTCertificate*, which maps to a unique DER encoded cert, but not to
a single PKCS#11 object in a single token. Since the same cert can
exist in multiple tokens, but there can only be one CERTCertificate*
pointer for all of them, the only way to resolve the issue would be
for the lookup function to return something other than just
CERTCertificate* alone. PK11_ListCerts does that.

Hm, I thought PK11_ListCerts tried to eliminate duplicates too, which
is why it has that crappy O(n²) behaviour? Does it *really* return more
than one of the 'same' certificate? Don't you *still* get a randomly-
chosen one with unpredictable contents of cert->slot?


No, there is only one cert no matter how many tokens that cert exists in.

cert->slot points to either the internal token (if the cert doesn't 
exist in a removable slot), or the first PKCS #11 removable slot. There 
is a call: PK11_GetAllSlotsForCert() which will return a slotlist of all 
the slots that certificate lives in.



Hm, purely for finding the *cert*, why doesn't the token: prefix
resolve that?

The token: prefix is only used as a starting point for the lookup.
But if the same DER cert exists in multiple tokens, then the value of
CERTCertificate->slot pointer is unpredictable.
It may or may not match what was used during the lookup. Same issue
for the nickname field.


It doesn't really work like that Julian. There is only one cert, the 
slot value is the same for all certs no matter how you looked it up. 
There is no guarantee that the token: value will map to the same slot as 
cert->slot.


In practice the number of times you have the same certificate on more 
than just the internal token and one other slot is exceedingly rare. 
That is the only reason the current code works at all.



OK, but you have the cert in your hand; it doesn't matter where it came
from as long as it's the right one. Hell, in OpenConnect I support
modes where the cert is in a file and only the key is in PKCS#11 or
TPM. Who *cares* where the cert came from?

It's only the *key* which really needs to be found in the right place,
since you have to *use* it from there, right?


This is correct. This is exactly how it works in NSS. NSS knows how to 
search all the slots the certificate lives on to find the related key.



Basically, what it comes down to, is that if you use the following
sequence :
cert = PK11_FindCertFromNickname("token:subject")
key PK11_FindKeyByCert(cert);

Your cert and key may not match the "token" in the original lookup
string. cert->slot and key->slot may not match.


There isn't  a PK11_FindKeyByCert. There is a 
PK11_FindPrivateKeyFromCert and it takes a slot from the caller, not 
from cert->slot.



bob



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Programmatically smartcard/token access with NSS

[Robert Relyea]

On 03/17/2016 06:17 AM, Túlio Gomes wrote:

Hello, i need to access a smartcard for signing documents with the private key 
stored inside it.
The idea is to create a c++ component that will be used with a pnacl module 
inside chrome's browser.

So i decided to use NSS, but i'm confused about what steps i need to do for 
load the smartcard, access the private key, sign and verify the document.

I read almost all the existing documentation and didn find any sample to do 
that.

So, here's my code:

int main(int argc, char** argv) {
SECMODModule *module;
SECStatus rv;
static char moduleName[] = "library=libwdpkcs_icp.so 
name=Token-libwdpkcs_icp";

module = SECMOD_LoadUserModule(moduleName, NULL, PR_TRUE);

if(!module) {
fprintf(stderr, "fail to load module");
exit(1);
}

PK11SlotInfo* slot = PK11_GetInternalSlot(); //didnt work. Returns 
nothing (0x0);

You need to initialize NSS itself first.


/*
*  Ok, i load the module. What's next? I need to create a DB or i can 
access the token directly? If so, how can i do this?
*  Probably the next step is to get the slot info. But how?
*/


Once you do this, the token certs are available with any db certs that 
you may already have. Typically in NSS you look up the certs you are 
interested in. 'User' certs are certs with private keys associated with 
them. Once you select a cert, you can lookup the key. The you can use 
that key to sign, decrypt or unwrap. If the cert and key you select are 
in the token, NSS will use it.


You can find an example for decrypting here:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/nss_sample_code/NSS_Sample_Code_sample4

In this example, the cert is found with:
  cert = PK11_FindCertFromNickname("TestCA", NULL);

You can find the cert using on a smartcard with "tokename:certname" as 
the nickname.

If you create a database:
   mkdir ./certs
   certutil -N -d ./certs
use modutil to add your smart card
   modutil -add Token-libwdpkcs_icp -lib libwdpkcs_icp.so -dbdir ./certs
You can then list all the certs on your smart card with
certutil -L -h all -d ./certs
 (you'll be prompted for the pin for your smartcard).

You can also use
 PK11_ListCertsInSlot() to find all the certs on your smart card.
You can use PK11_FindSlotByName() or PK11_FindSlotsByNames to find 
the slot for your smart card.


/usr/include/nss3/pk11pub.h has a list of most of the functions that 
deal with smart cards.



**NOTE*** In the example, you'll need to fix the password function to 
actually prompt for the password. If you don't, you can lock your token 
if it has a fixed numbers of retries.


bob

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/nss_sample_code/NSS_Sample_Code_sample4

SECMOD_DestroyModule(module);
}

Can anyone give me some help?
Thanks in advance.
ps: sorry for my english





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS_NoDB_Init(".") and FIPS mode

[Robert Relyea]

On 03/18/2016 01:55 PM, Wan-Teh Chang wrote:

On Fri, Mar 18, 2016 at 10:49 AM, Robert Relyea <rrel...@redhat.com> wrote:

Yes, SECMOD_DeleteInternalModule() is a toggle which switches NSS between
FIPS and non-FIPS. If you don't have a database open, or the database is
open readOnly, the change only affects the running program.

Hi Bob,

Your answer surprised me. The latest NSS FIPS 140-2 Security Policy at
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2564.pdf
says user passwords are stored in salted form in the key database
(Table 8 on page 26). So I don't understand how NSS can operate in
FIPS mode without an NSS database. I guess without an NSS database the
NSS crypto module will only provide services that don't require user
authentication, such as hashing and random number generation?
The new softokn allows you to run in level 1. If you don't have a 
database, or the database is set without a password, then NSS is running 
in FIPS-140 Level 1 mode and does not require a password.


This allows NSS to run in fips mode based on a system FIPS flag (which 
linux has) without massive breakage. If you need level 2 however, you 
must have a database and you must set the password. NSS will allow you 
to switch from level 1 to level 2, but not vice versa.


bob


Thanks,
Wan-Teh Chang





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [ANNOUNCE] NSS 3.24 Release

[Robert Relyea]

On 05/22/2016 04:26 PM, Paul Wouters wrote:

On Sun, 22 May 2016, Kai Engert wrote:


Subject: [ANNOUNCE] NSS 3.24 Release


* NSS softoken has been updated with the latest NIST guidance (as of 
2015)


What does this relate to? Do you have the specific FIPS publication?
Is this perhaps the GCM IV handling?
Checking library integrity at library load time rather than first init 
time. I don't have the document.:(,


bob


Paul





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Should PK11_Derive() save the failure status?

[Robert Relyea]

On 02/22/2017 10:44 AM, Andrew Cagney wrote:

Hi,

I've got a PK11_Derive() call failing (presumably something silly on
my part), but frustratingly, PORT_GetError() just returns 0.

It seems that all variants of PK11_Derive() don't call:

 PORT_SetError(PK11_MapError(crv));

with the error status from ->C_DeriveKey().  Should they?


Yes, please write a bug on this. The mapping should happen directly 
after the C_DeriveKey() call.


bob

   Or is there
some other way (short of debugging) to get at least a hint has to my
error.

Andrew



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: JSS/NSS locks my smart card after 1 bad pin entry

[Robert Relyea]

On 10/07/2016 06:56 PM, Ernie Kovak wrote:

Hello -

We're using JSS4 and NSS 3.24 with an OpenSC module to interact with a DoD CAC. 
CACs will lock after 3 consecutive bad PIN entries. We're finding that if the 
user enters a bad PIN even once, that hard limit is exceeded and the card is 
locked.
What version of openSC are you using. OpenSC only recently got CAC 
support added to it.


Have you tried coolkey?


I've searched through NSS to see if there's PIN retry logic, but I didn't see 
anything, though I quickly got lost in the code so not sure. I'm a java dev...


NSS itself does not retry bad pins, but it does present the application 
the opportunity to retry the pin. It has a flag so applications that 
cache the pin can know to discard the cached pin on retry. It could be 
an error in the JSS pin handler?


Is anyone else running a configuration like this that's seeing this behavior? 
Is there a configuration item that might limit the retries?

Thanks!
Ernie



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS db nicknames with NSS_InitContext()

[Robert Relyea]

On 10/18/2016 11:16 AM, Rob Crittenden wrote:
It looks like when multiple NSS databases are initialized using 
NSS_InitContext() the nicknames can take multiple forms depending on 
order of initialization. Using the multinit program and three NSS 
certificate databases with identical nicknames I saw the following 
names associated:


(first initialized) Server-Cert
(second initialized) NSS Certificate DB:Server-Cert
(third initialized) NSS Application Token 0005:Server-Cert

Is this expected/dependable behavior?

Short answer: yes.

So the first and second are identical (assuming your built in database 
is named 'NSS Certificate DB'). The name would be different yet in FIPS 
mode, and different if NSS is initialized by the application with it's 
own database name.


What is happening is the actual token name is different. When NSS is 
first initialized, it initialized with it's default token, which doesn't 
need a separate 'token' identifier. If you call InitContext() again with 
the same database, it will 'point' to the already opened database. If 
you point to a different database, you will get a new token with it's 
own name.


It sorta looks like with that third initialization it also has each of 
the previous two nicknames as well.


If you are using the same cert in all three cases (and the token is 
still open), All three nicknames will point to the same cert. It looks 
like one cert that lives in 3 different tokens. (There's a call that 
will give you all the tokens the cert lives in).


It seems like rule of thumb is that using multiple databases with the 
same nicknames is a terrible idea and unpredictable, just looking for 
confirmation.


So because of historical issues, nicknames will often give you 
unpredictable results. I usually recommend other ways to finding your 
cert (like recording the issuer/SN to use).


bob


thanks

rob



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS_Context and FIPS

[Robert Relyea]

On 10/21/2016 07:04 AM, Rob Crittenden wrote:
I'm trying to figure out how to dynamically enable FIPS support for 
NSS Contexts.


I started with multinit.c and initialize FIPS right after calling 
NSS_InitContext() using this:


So you can't change the state of an already open database. NSS will 
switch all new databases that are opened, and idle the old ones 
(basically they are open, but not really accessible).





if (!PK11_IsFIPS()) {
fprintf(stderr, "Initializing FIPS\n");
SECMODModule *mod = SECMOD_GetInternalModule();
if (!mod) {
fprintf(stderr, "No module!?\n");
exit(1);
}
char * internal_name = PR_smprintf("%s",
SECMOD_GetInternalModule()->commonName);

if ((SECMOD_DeleteInternalModule(internal_name) != SECSuccess) ||
 !PK11_IsFIPS()) {
 fprintf(stderr, "Unable to enable FIPS mode on 
certificate database\n");

 exit(1);
}

I'm executing it like this, initializing only db1 and db2 as contexts:


So when you do an initcontext, you're main database is usually not the 
same as the main database when you open NSS, so it won't get 
automatically switched.


Is there a reason you are trying to do a dynamic switch to FIPS mode 
from within a library? (I'd like to know the use case).


Dynamic switching is a pretty careful choreographed dance that 
applications like mozilla can execute with care. It usually involves 
both fips and non-fips tokens opened for a short period until all the 
references can be cleared. Databases opened before the switch will 
almost certainly be inaccessible.


$ ./multinit --verbose --lib1_db db1/ --lib2_db db2 --lib1_command 
list_certs --lib2_command list_certs --lib1_readonly --lib2_readonly 
--order 12zi


This is the output:

$ ./multinit --verbose --lib1_db db1/ --lib2_db db2 --lib1_command 
list_certs --lib2_command list_certs  --lib1_readonly --lib2_readonly 
--order  12zi

* initializing with order "12zi"*
*NSS_Init for lib1*
Checking for FIPS
Initializing FIPS
*Executing nss command "list_certs" for lib1*
cacert CTu,Cu,Cu
*   Slot=NSS FIPS 140-2 Certificate DB*
*   Nickname=cacert*
*   

Re: Fwd: debug PKCS11

[Robert Relyea]

On 11/18/2016 12:49 AM, Alexei Mayanov wrote:

Hello! I'm developing PKCS11 library for my device. This library is based
on pkcs11-proxy (https://github.com/SUNET/pkcs11-proxy). It work good with
different apps but with Firefox I can't login with client certificate on to
the test site. Firefox doesn't present me the list of certificates on the
device. I made log of calls of PKCS11 API functions from my library and
can't determine the reason of problem. And I don't know what is happening
inside NSS that cause the problems. Is it possible to enable some debug
info in NSS library that Firefox uses? Thanks in advance!

Hmm,
Have you installed the PKCS #11 module in firefox?

 if not, go to the advanced preferences
   (about:preferences#advanced) and click the 'security devices'
   button, then click the 'Load' button.

If so, Does it show up in the security devices dialog 
(about:preferences#advanced)?


   if not, it means NSS couldn't load your pkcs #11 module, Usually the
   dlopen failed for some reason, though it could be NSS opened the
   module but had some issues initializing it. If you are getting into
   your C_GetFunctionList() function, then the dlopen worked fine. NSS
   will then call C_Initialize(), and then the normal C_GetSlots, etc.

If so, Does it show that the device is present?

   If your module is loaded, it should show the slots in the security
   devices dialog (If not you module did not give NSS any slots). You
   can click on the slots to see the status of each slot. If there is a
   card plugged in, the status should be present. If not the status
   should be not present. If NSS had an error initializing the slot,,
   it should show a status of disabled. The latter means that NSS
   couldn't get everything it needs for the slot to be useful (like
   being able to create a session). Errors here are usually problems
   with session management in the token.

If so Do you get a password prompt for your device if you bring up the 
cert dialog?


   If not (and your token is present), it means that you probably
   didn't make your token as requiring a password properly, or you told
   NSS you were already logged in (again session management). NOTE:
   this may be OK if you don't require a password to find the keys on
   your token. For most tokens, though, this will cause a problem.

If password handling is OK, do you see any certs from your token in the 
cert dialog?


   Be sure to check all the tabs (particularly 'Your Certificates' and
   'Others'). If no certificates are showing up, then there is probably
   something wrong with your C_FindObject* functions. If the
   certificates are showing up under 'Others' and not 'Your
   Certificates', then there is probably something wrong with your link
   of certificates to keys, or your ability to match private keys.
   certificates which have keys associated with them should have a
   CKA_ID attribute with is matches the CKA_ID of the private key
   associated with the certificate. NSS will lookup the CKA_ID from the
   cert and then search for a private key with that same CKA_ID. If it
   finds that key, it will mark it as a 'user' certificate. Only 'user'
   certificates show up in 'Your Certificates' and only 'Your
   Certifcates' are used in ssl client auth operations.


If all this is working, you probably aren't dealing with an issue of 
your module, but a configuration issue with the server and firefox.


Best regards,
Alex



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS open multiple NSS-Databses at once?

[Robert Relyea]

On 01/10/2017 10:18 AM, Opa114 wrote:

thanks, but these facts i know.
I don't want top let multiple applications open one Database, i want to open 
multiple different Mozilla databases, in the old standard format, with one (my) 
application.

I tried to use the NSS_Init functions. These works with openening one database, 
but when i open a second one the whole application crashes,so that's why i 
asked the question and may be get some working example c++ code?
1) Where are you crashing (it's not expected to work, but I don't expect 
a crash because you called NSS_Init again).


2) To open additional databases you want to use SECMOD_OpenUserDB:

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/PKCS11_Functions#SECMOD_OpenUserDB

You can call that multiple times.
Once the database is opened any of the NSS find functions will find all 
the certs in both databases. The slot returned from SECOMD_OpenUserDB 
can be used in functions that take a slot to narrow the operations just 
to that particular database.


To NSS each database will look basically like a smart card.

When you are through with that database you can use SECMOD_CloseUserDB()

bob


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS open multiple NSS-Databses at once?

[Robert Relyea]

On 01/10/2017 02:07 PM, Opa114 wrote:

Am Dienstag, 10. Januar 2017 22:24:10 UTC+1 schrieb Robert Relyea:

On 01/10/2017 10:18 AM, Opa114 wrote:

thanks, but these facts i know.
I don't want top let multiple applications open one Database, i want to open 
multiple different Mozilla databases, in the old standard format, with one (my) 
application.

I tried to use the NSS_Init functions. These works with openening one database, 
but when i open a second one the whole application crashes,so that's why i 
asked the question and may be get some working example c++ code?

1) Where are you crashing (it's not expected to work, but I don't expect
a crash because you called NSS_Init again).

2) To open additional databases you want to use SECMOD_OpenUserDB:

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/PKCS11_Functions#SECMOD_OpenUserDB

You can call that multiple times.
Once the database is opened any of the NSS find functions will find all
the certs in both databases. The slot returned from SECOMD_OpenUserDB
can be used in functions that take a slot to narrow the operations just
to that particular database.

To NSS each database will look basically like a smart card.

When you are through with that database you can use SECMOD_CloseUserDB()

bob


thanks for reply. Here are first some little code of which did not work, that 
means it crashes:

functionLoadFirefox() {
SECStatus rv = NSS_InitReadWrite(PATH_TO_FF_DB);
... if success load Certificates with PK11_ListCerts(PK11CertListAll, NULL);
NSS_Shutdown();
}

functionLoadThunderbird() {
SECStatus rv = NSS_InitReadWrite(PATH_TO_TB_DB);
... if success load Certificates with PK11_ListCerts(PK11CertListAll, NULL);
NSS_Shutdown();
}

So these are my two functions in which i opened and clos the databases and 
retrieve the certificates.
So the certs you got from the first call is likely preventing 
NSS_Shutdown from completing. The certs hold references to the 
respective slots. Those references prevent NSS_Shutdown from closing 
completely. The will prevent the second NSS_Init from succeeding, so you 
probably crash in your second shutdown. You can detect this happened by 
looking at the return value from NSS_Shutdown().


--> 2) To open additional databases you want to use SECMOD_OpenUserDB
So this means. First i have to call NSS_Init with let's say firefox database ad 
the i have to call SECMOD_OpenUserDB with the thudnerbirddatabse, right? Or 
must i load both with the SECMOD_OpenUserDB?
You can either use NSS_Init with no database and then call 
SECMOD_OpenUserDB() for both, or you can call NSS_Init with one database 
and then call SECMOD_OpenUserDB with the other.


--> Once the database is opened any of the NSS find functions will find all the 
certs in both databases
But i have to know from which databse the certificates are coming from. So i 
need to know that let's say Certificate ABC ist stored inside Firefox Databse 
and Certificate 123 is stored in Thunerbird Database. How can i do that? or is 
this not possible?
The slot the database can be found in the cert->slot entry, but this 
will only give you ONE of the slots the cert lives in. If a cert exists 
in both databases, it will have a single entry on the list and be 
"somewhat" random which slot is listed (If you open one database with 
NSS_Init and the second with SECMOD_OpenUserDB() then the one you opened 
with SECMOD_OpenUserDB() will be the slot that shows up.


To fix this issue, there's a function called PK11_GetAllSlotsForCert() 
which returns a slotList and will return all the slots that hold this 
cert. The slots map one for one to the databases you opened (or any 
smart cards you have loaded). You can control the 'tokenName' of each 
slot with the string arguments you pass to SECMOD_OpenUserDB(), and you 
can get the token name with PK11_GetTokenName() on each slot on the list..


You could also use PK11_ListCertsInSlot() which takes a slot 
(SECMOD_OpenUserDB() will return a slot for you) and lists only those 
certs in that slot.


Be sure to free all these things once you are through with them, or your 
shutdown will fail at the end again.



bob


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSS open multiple NSS-Databses at once?

[Robert Relyea]

On 01/08/2017 05:34 AM, Opa114 wrote:

Hi there,

i have to use NSS in one of my applications and therefor i have to open 
multiple databases (for example Firefox and Thunderbird) at once to read and 
write into these. How can i do this programatically in C++? Some exmaple Code 
would be very helpful because the whole NSS-Stuff is not very well documented.

Thnaks in advice! :)


NSS does have a database format that can allow multiple applications to 
open the same database at the same time, but neither Firefox nor 
Thunderbird has yet moved to that database. It is possible to force them 
to use this database format by setting the NSS_DEFAULT_DB_TYPE to sql. 
Once they are using the same database, you will have to use symbolic 
links so that the NSS databases in the separate firefox and thunderbird 
point to a single database.


https://wiki.mozilla.org/NSS_Shared_DB_Howto explains how to do set up 
the above.


If you have an application, you can open the shared database by passing 
"sql:{shared directory path}" to the configdir parameter of the 
NSS_Initxxx function you are calling to initialize NSS (where {shared 
directory path} is replaced by a path to a common directory you which 
your applications to share. Some recommendations for Linux based 
applications can be found here: 
https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX



bob



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Are NSS bug fix releases still FIPS 140-2 certified?

[Robert Relyea]

On 04/10/2017 02:58 PM, Ernie Kovak wrote:

Kyle Hamilton is right. The authoritative document is the NSS module's security 
policy, which is linked from their validation certificate (see above). That 
policy specifies how the module can be used in order to be FIPS 140-2 compliant.

According to the NIST FIPS 140-2 Implementation Guide 
(http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf) there 
are only a couple things you can do to a module once it's been validated:

The vendor can fix non-security related bugs and update their validation (as 
opposed to a full re-validation of the module), and

Users can build the module from sources for the purpose of porting to new 
platforms IFF the security policy includes specific build procedures. But the 
NSS security policy contains no such build procedures. Look at the OpenSSL 
policy for an example of one that does.

So this is a little in accurate in that:
1) Only the validating vendor can do a 'vendor affirm' on a new plaform. 
Each openSSL vendors that want FIPS validations do their own validation.
2) That vendor can do a 'vendor affirm' without any documented build 
procedures.


So the conclusion below is correct with respect to the Red Hat 
validation, but it's true because Red Hat has not vendor affirmed any 
other platforms. It is not the case that openSSL is any more validated.

That means NSS does not provide FIPS compliance on any platform other than the 
one they tested on. So, not on Windows. Not anywhere other than Red Hat 
Enterprise Linux on a few platforms.







--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How to get a list of SubjectAltNames of a cert in NSS

[Robert Relyea]

On 03/03/2017 09:42 AM, Paul Wouters wrote:

On Fri, 3 Mar 2017, Robert Relyea wrote:


 [offlist]


redirected back to the list, since the item I was concerned about is not
a concern.


 Thanks for the info. I looked at it and have two questions and one
 concern (which is why this is offlist)
I'm not sure what list this was from. I don't remember seeing the 
thread.


dev-tech-crypto@lists.mozilla.org


 - Why not export this NSS function for everyone?


Which function?


Sorry, I was referring to:

cert_VerifySubjectAltName(const CERTCertificate *cert, const char 
*name);


Certainly as named, we would export it, but we could wrap the function 
as CERT_VerifySubjectAltName()

and export that function.




Basically in IKE you can set an ID different from a DN. So if someone
sets ID_FQDN (eg vpn.example.com) then we want to lookup and ensure that
the certificate is really matching that ID. IKE also allows specifying
email addresses and IP's. So we need to look for:

- email= in the DN
- subjectAltName of type DNSname
- subjectAltName of type IP
- subjectAltName of type email address.

It looks that CERT_GetFirstEmailAddress() and CERT_GetNextEmailAddress()
gets me the email= from the DN and all email address in the first
subjectAltName section, but not in subsequent subjectAltName sections.


Yes, NSS only looks at the first subjectAltName section. That section 
can and should hold all the alt names (That's certainly the case with 
SSL certificates).


I think you may be confused with the openSSL API. When openSSL says:

Please make sure the following details are correct before proceeding any 
further.

CommonName: server1.example.com
subjectAltName: DNS:server1.example.com
subjectAltName: DNS:mail.example.com
subjectAltName: DNS:www.example.com
subjectAltName: DNS:www.sub.example.com
subjectAltName: DNS:mx.example.com
subjectAltName: DNS:support.example.com
No additional information will be included on certificates because it can not 
be automatically checked by the system.

It will create a single subjectAltName with all those names in it:

X509v3 Subject Alternative Name:
DNS:server1.example.com, othername:, DNS:mail.example.com, 
othername:, DNS:www.example.com, othername:, DNS
:www.sub.example.com, othername:, DNS:mx.example.com, othername:, DNS:support.example.com, othername:

Are you sure the certificate you have actually has multiple 
subjectAltName sections?




The same is true for cert_VerifySubjectAltName() which seems to only
look at the first subjectAltName section as well.

The certificates I use for testing use this openssl/python code:

-   add_ext(cert, 'subjectAltName', False, dnsname)
+   if cnstr == "east.testing.libreswan.org":
+   dnsname = "%s,%s"%(dnsname , "DNS:east.alias")
+   add_ext(cert, 'subjectAltName', False, "IP: 
192.1.2.23")

+   add_ext(cert, 'subjectAltName', False, dnsname)
+   add_ext(cert, 'subjectAltName', False, "email: 
user1@%s"%cnstr)


So there are 3 subjectAltName sections.


Hmm Are you sure these aren't being colapsed into a single 
subjectAltName section with multiple subjectAltNames in it?


In general NSS tends to be stingy by default on the functions it 
exports,


I completely understand that :)

I believe Kai has already exported several functions upstream for you 
that will go into RHEL 7.


Yes, and we've already updated libreswan to make use of this in upstream
and fedora rawhide! Thanks!


 The code I see in NSS seems to assume there is only one SAN section? I
 checked and it does not create one big list of all the SAN extensions,
 because I don't see my IP address SAN in the above example.


It doesn't. For most of NSS we usually are looking for a specific SAN 
(like a particular DNS name, or an email address.), so it loops 
through them all.


I'm surprised the SAN processing isn't exported since applications 
that override the SSL name check would need it.


You do export CERT_VerifyCertName() which uses this function. So maybe I
was trying to use the wrong function. But it seems this function also
does not process multiple subjectAltName sections.


CERT_VerifyCertName() verifies against either the SAN or the CN (SSL 
processing). it supports multiple subjectAltNames, but they all are 
expected to be in the same section.


bob


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How to get a list of SubjectAltNames of a cert in NSS

[Robert Relyea]

On 03/03/2017 02:48 PM, Robert Relyea wrote:

On 03/03/2017 09:42 AM, Paul Wouters wrote:

On Fri, 3 Mar 2017, Robert Relyea wrote:


 [offlist]


redirected back to the list, since the item I was concerned about is not
a concern.


 Thanks for the info. I looked at it and have two questions and one
 concern (which is why this is offlist)
I'm not sure what list this was from. I don't remember seeing the 
thread.


dev-tech-crypto@lists.mozilla.org


 - Why not export this NSS function for everyone?


Which function?


Sorry, I was referring to:

cert_VerifySubjectAltName(const CERTCertificate *cert, const char 
*name);


Certainly as named, we would export it, but we could wrap the function 
as CERT_VerifySubjectAltName()
and export that function. 


Arg... typing to fast drops negations. this should read

"Certainly as names we would NOT export it, but we could wrap the 
function as CERT_VerifySubjectAltName() and export that function()."


Lower case function names is an indicator the the function is local, at 
least to the NSS directory, if not to the .c file itself. Anything 
exported even within the NSS shared library (yet alone to the 
application) sould have an all cap prefix.


bob

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Linker error from tstclnt

[Robert Relyea]

On 11/22/2017 07:24 AM, Kai Engert wrote:

On 10.11.2017 10:16, muni.pra...@gmail.com wrote:

USE_STATIC_RTL=1

I haven't seen this symbol before, maybe it's no longer supported.

Does it work if you don't define it?


The symbol means build the test binaries with static libraries. That 
hasn't been officially supported by NSS for quite some time (though it 
may accidentally work on some platforms). Only certain low level test 
apps whould use the static run time, and they explicitly set the value 
in their makefiles.


bob


Kai



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Is there some problem with treeherder?

[Robert Relyea]

I've been trying to get an nss-try builds with nss-tools for a couple of 
days now, but it looks like both nss-try and nss are not properly 
running any tests. Is there an outage, or do we need someone to kick the 
try servers?



bob

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [ANNOUNCE] NSS 3.44 Release

[Robert Relyea]

On 05/17/2019 08:54 AM, JC Jones wrote:

On Thursday, May 16, 2019 at 9:28:39 AM UTC-7, Paul Wouters wrote:


Wait, what?

They need work to make them simpler and better support cross compiling
for sure, but getting rid of them would really hamper our use of NSS
on different platforms. How would you support that without Makefiles?

Paul

'build.sh' uses ninja-build and gyp rather than the Makefiles. I know those 
tools don't have total platform coverage yet, but it's getting close.

What platforms are you using that aren't covered? It's almost certainly easier 
to improve those tools than it is to revamp the Makefiles.


Except Makefiles still work and are how RH builds NSS. I'm sympathetic 
to how gyp files makes mozilla's life easier, but we get zero benefit 
from them, so we need a nice long discussion before we 'start to phase 
out' makefiles.


Please don't make these kinds of decisions and announcements without 
some concurrence from us.



bob


J.C.



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

NSS ESR release date.

[Robert Relyea]

Red Hat Planning would like to know the estimate for when the NSS 
targetted for ESR will be released. We are working on the theory it will 
be end of May (balancing time for PKCS #11 3.0 changes versus when ESR 
needs a new NSS). Planning wants me to confirm that with mozilla, 
particularly JC.


Thanks,

bob


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [key4.db] IV size for aes256-CBC

[Robert Relyea]

On 03/27/2020 12:21 PM, Louis Abraham wrote:

Hi Matthew,

Awesome, thanks and sorry for contacting the wrong list!

Since then, I found the answer to the 14 bytes question: 
https://hg.mozilla.org/projects/nss/rev/fc636973ad06392d11597620b602779b4af312f6#l6.49
Basically the DER encoding is used instead for compatibility with a 
bugged implementation.


I tried prepending |b'\x04\x0e'| to DER-encode the IV. However, the 
value I get makes no sense (and even has an incorrect padding 
according to pkcs7 ).



Best,

Louis

The IV length is still 16 bytes, but only 14 are randomly generated. 
It's because the decoding code had a bug in it that requires the IV to 
look like der encoded data, so the header needed to be added, but the 
whole IV was used (including the 2 byte header) when encrypting/decrypting.


The goal of the AES-256 bit code was  to encode AES-256 while allowing 
older versions of NSS to still decrypt the new keys, since versions of 
NSS may share their databases with other NSS applications running on 
other machines.


bob


Le ven. 27 mars 2020 à 19:57, Matthew N. > a écrit :


Hi Louis,

The dev-tech-crypto mailing list I'm redirecting this to should be
able to get you an answer.

Thanks,
MattN


On Fri, Mar 27, 2020 at 8:51 AM Louis Abraham
mailto:louis.abra...@yahoo.fr>> wrote:

Hi,

I'm the main developer of https://github.com/louisabraham/ffpass
We are currently trying to accommodate the (not so) recent
cryptographic changes in key4.db.

If I understand correctly, key4.db contains a table metadata.
The value item2 defines a cryptographic algorithm in the DER
format.

In the latest version of Firefox, this algorithm is PBES2,
using aes256-CBC as the encryption algorithm.

I'm facing a little problem when trying to execute aes256-CBC
because the IV size is only 14 bytes (56 bits) instead of the
64 bits defined in the spec.

Could you please help me to understand?

Best,
Louis



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [key4.db] IV size for aes256-CBC

[Robert Relyea]

On 04/22/2020 01:21 AM, laurent.cl...@gmail.com wrote:

On Monday, March 30, 2020 at 6:28:55 PM UTC+2, Robert Relyea wrote:

On 03/27/2020 12:21 PM, Louis Abraham wrote:

Hi Matthew,

Awesome, thanks and sorry for contacting the wrong list!

Since then, I found the answer to the 14 bytes question:
https://hg.mozilla.org/projects/nss/rev/fc636973ad06392d11597620b602779b4af312f6#l6.49
Basically the DER encoding is used instead for compatibility with a
bugged implementation.

I tried prepending |b'\x04\x0e'| to DER-encode the IV. However, the
value I get makes no sense (and even has an incorrect padding
according to pkcs7 <https://tools.ietf.org/html/rfc2315>).


Best,

Louis


The IV length is still 16 bytes, but only 14 are randomly generated.
It's because the decoding code had a bug in it that requires the IV to
look like der encoded data, so the header needed to be added, but the
whole IV was used (including the 2 byte header) when encrypting/decrypting.

The goal of the AES-256 bit code was  to encode AES-256 while allowing
older versions of NSS to still decrypt the new keys, since versions of
NSS may share their databases with other NSS applications running on
other machines.

bob

Le ven. 27 mars 2020 à 19:57, Matthew N. mailto:ma...@mozilla.com>> a écrit :

 Hi Louis,

 The dev-tech-crypto mailing list I'm redirecting this to should be
 able to get you an answer.

 Thanks,
 MattN


 On Fri, Mar 27, 2020 at 8:51 AM Louis Abraham
 mailto:louis.abra...@yahoo.fr>> wrote:

 Hi,

 I'm the main developer of https://github.com/louisabraham/ffpass
 We are currently trying to accommodate the (not so) recent
 cryptographic changes in key4.db.

 If I understand correctly, key4.db contains a table metadata.
 The value item2 defines a cryptographic algorithm in the DER
 format.

 In the latest version of Firefox, this algorithm is PBES2,
 using aes256-CBC as the encryption algorithm.

 I'm facing a little problem when trying to execute aes256-CBC
 because the IV size is only 14 bytes (56 bits) instead of the
 64 bits defined in the spec.

 Could you please help me to understand?

 Best,
 Louis


Hi Robert,

For PBKDF2, why the iteration value is only 1  by default ?
the recommandation is 1: 
https://cryptosense.com/blog/parameter-choice-for-pbkdf2/

is it the value 1 in this ASN1 data ?

SEQUENCE {
  OBJECTIDENTIFIER 1.2.840.113549.1.5.12 pkcs5 PBKDF2
  SEQUENCE {
OCTETSTRING 
b'f92dde91809b8b00c6607b73f3d0321c80f930aa13f13da5293aede76ee92048'
INTEGER b'01' <- iterations ?
INTEGER b'20'
SEQUENCE {
  OBJECTIDENTIFIER 1.2.840.113549.2.9 hmacWithSHA256
}
  }
}

Laurent,
author of https://github.com/lclevy/firepwd


There's a separate patch the increases is supposed to increase the 
iteration count. I believe it landed after the AES changes.


bob


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Crypto team minutes 202-05-12

[Robert Relyea]

Date: 2020-05-12
Chair: Ivan
Minutes: Bob
Participants: Alex, Standa, Jakub, Bob, Daiki, Toshi, Simo, Tomas, 
Sahana, Hubert, Ondrej, Ivan, Lucie

Excused: Nikos

Chair and minutes keeper update etherpad, after the meeting the minutes 
keeper sends minutes and prepares etherpad for next week - 
https://wiki.brq.redhat.com/SecurityTechnologies/CryptoTeam#Meetingsandminutes


* Meeting administrivia/announcements (5 mins)

[announce this meeting chair/notes keeper]
[decide  next meeting chair/notes keeper Bob -> Daiki -> Hubert ->  
Sahana -> Jakub -> Simo ->  Tomas -> Alexander -> Lucka  -> Standa -> 
Toshi -> Ondrej -> Ivan]


Next meeting chair: Bob
Next meeting minutes: Daiki


* Check of issue queries (10 min)

Report of NEW untriaged items the last two weeks and items with needinfo:
https://url.corp.redhat.com/crypto-team-chairman-reportv6 (6)

RHEL8.3:
 * non-acked: https://url.corp.redhat.com/crypto-rhel83-nonacked-v1 (13)
 * untriaged: https://url.corp.redhat.com/crypto-rhel83-untriaged-v1 (2)
 * unscoped: https://url.corp.redhat.com/crypto-rhel83-unscoped-v2 (8)
 * ON_QA bugs: https://url.corp.redhat.com/crypto-rhel83-onqa-v1 (6)

RHEL7.9:
 * untriaged bugs 
https://url.corp.redhat.com/crypto-rhel79-untriaged-v1 [please triage or 
close; do not postpone (except for ca-certificates and nss*)] (3)



* PTOs (0 min)

Standa: May 15th

* Status report on previous action points (5 min) [note: no discussion 
only status]


AI All: Skim through the Maturity Model document and give feedback.
Done

AI Hubert, Anderson and Jakub: discuss Quantum-resistant SSH Key 
Exchange in a seperate meeting.

done: discussed on irc.

Chess tournament:
Interested: Standa, Hubert, Ivan, Sahana (prefer classical), Simo (I am 
ok with blitz 10min or no time limit), Jakub

done :)

* Check Ready for Acceptance (10 min)

Jira: 
https://projects.engineering.redhat.com/secure/RapidBoard.jspa?rapidView=3019



* Update on running theses and internship (1 min)

Hubert: (timing attacks with tlsfuzzer): new PR I need to review
Hubert: (cipherscan TLS 1.3 support): no update

Interns:
Frantisek: new PR I need to review
Norbert: presentation and demo at monthly meeting



MUNI + Red Hat collaboration on post-quantum crypto + side-channel 
resistance:

https://docs.google.com/document/d/1qQlkawjxXkaz05aseCDXAgGEdZtkcY7MdtxJXsaRQo8/edit#heading=h.5m4tl0gyigmi
no update


* Update on running projects (3 min)

Daiki: QUIC and HTTP/3
https://projects.engineering.redhat.com/browse/CRYPTO-398
no progress


* Deadlines

2020-01-21: RHEL-8.2 bugs require exception or blocker
2020-01-27: RHEL-8.1.0.z Batch 2 -  Errata in REL_PREP
2020-02-11: RPL for 7.9 deadline
2020-02-25: Q4 review SST meeting
2020-02-25: Fedora 32 Beta Freeze
2020-02-29: Q4 Ends
2020-03-26: RHEL-7.9 bugs require exception or blocker
2020-03-30: RHEL 8.1.0.3 all Errata in REL_PREP [openssl]
2020-03-30: RHEL 8.2 all Errata in REL_PREP
2020-03-31: RHEL 8.3 RPL SST deadline
2020-04-24: Mid quarter Review and planning completion
> we are here <-
2020-06-01: Firefox 78 Beta freeze
2020-06-02: OpenSSL 3.0 Beta release (feature freeze)
2020-06-30: Firefox ESR 78.0 release
2020-07-13: RHEL-7.9 all Errata on REL_PREP


* Discussion (25 mins)

Alex: let's vote on results-yesterday project proposal 
(https://projects.engineering.redhat.com/browse/CRYPTO-1198)

Alex wants to know what the process to move forward.
Simo: we just need to vote
Vote: Approved, no objections.
Simo: Be sure to reply to any requests to this Jira card in a timely 
manner. Management may ask time critical questions here.
Standa: You need to explicitly watch a bug, even if you own the card to 
get notifications.


Tomas: In 8.2 custom crypto-policies bring python into the minimal 
rhel-8 container image - should we make the update-crypto-policies a 
subpackage pulled in via "Recommends"?

Tomas: in fedora we use this method.
Simo: why would we worry about this in RHEL.
Tomas: customers may ignore the Recommends and not get 
update-crypto-policies. There may be a work around would be to put the 
tool in, but put a runtime warning.
Simo: Better to not have the tool. Just do the Recommends and customers 
that need the tool can figure out if they bypass recommends.

AI Tomas: Put the crypto-policies bug in the 8.3 errata

Tomas: Heads-up - Thunderbird (which we ship in RHEL) will from version 
78 require Botan crypto library :(

    Simo: why? what is it used for?
    Kai Engert said on nss-dev ML: "For OpenPGP we're using the RNP and 
Botan libraries. [...] We'll NOT bundle GnuPG because of its GPL license."

    Bob: You can build it without it but you wont get PGP.
    Simo: ideally we want this support as a plugin in EPEL.
    Simo: make sure RHEL thunderbird knows about.
    AI: Tomas make sure there is a downstream RHEL bug for Botan issue 
in Thunderbird.


Alex: definition of done for 'fix tests on Fedora': passes in Beaker on 
x86? has a reviewed TCMS run? passes 

Re: Crypto team minutes 202-05-12

[Robert Relyea]

Please ignore this, it went to the wrong list.


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

No Post Quantum this week.

[Robert Relyea]

Bob has a dental appointment and will be out. See you in 2 weeks.

bob

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: No Post Quantum this week.

[Robert Relyea]

On 9/14/20 10:19 AM, Robert Relyea wrote:

Bob has a dental appointment and will be out. See you in 2 weeks.

bob


Went to the wrong list. You can ignore this.

bob

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Default Password callback

[Robert Relyea]

On 10/1/20 5:37 AM, Daniel Gustafsson wrote:

I'm implementing support for NSS into a codebase which already has OpenSSL
support, and when looking at the passphrase callbacks I ran into a question.

Is my understanding correctl that there is no default password callback like
how OpenSSL has a fallback reading from a TTY?  SECU_GetModulePassword and the
supporting functions are clearly private and not exposed, but since the docs
don't spell it out I wanted to doublecheck to make sure I hadn't missed
anything.


That's correct. NSS is often run with windowed systems, so only the 
application knows how to get to the user to prompt for a password.


SECU_GetModulePassword is part of the command line utilities library, 
which you could grab and use in your application.



bob



cheers ./daniel



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Regarding SQLite in NSS 3.44.4

[Robert Relyea]

On 8/7/20 1:27 AM, Rahul S wrote:

Hi Team,

Hope all are doing good!

I would like to get some clarification about the SQLite version in NSS 
3.44.4. From release notes of NSS 3.46, i see that the "Bug 1550636 
- Upgrade SQLite 
in NSS to a 2019 version"


has been fixed .Is the upgraded  SQLite version also available in NSS 
3.44.4?


It's unlikely. On the other hand, not all instances of NSS come with the 
imbedded SQLite library. Most NSS instances use an external library 
(either included in the operating system or included with the 
application using NSS).


On linux, for instance, NSS uses the system SQLite, which is often newer 
than the version shipped with NSS. In Mozilla products, Mozilla includes 
their own copy of sqlite which NSS uses.


In these cases, you won't find a copy of sqlite in NSS, but instead nss 
uses the system copy.



bob




Best Regards,

Rahul.S



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [ANNOUNCE] NSS 3.53 release

[Robert Relyea]

On 6/1/20 5:18 PM, JC Jones wrote:

The NSS team released Network Security Services (NSS) 3.53 on 29 May 2020. NSS 
3.53 will be a long-term support release, supporting Firefox 78 ESR.



Looks like we updated certdata.txt without updating the version number 
in nssckbi.h. This caused some problems because I pulled the 3.52 
certdata.txt, but with 3.53 coming out I verified that version number 
didn't change and didn't pick up the 3.53 change.


We need to make sure we bump the version number when we make changes. 
Just a reminder for the future...


Fortunately our QA tests found this, and I had already pushed our 
version number because I removed a bunch of expired certs (that weren't 
explicitly marked as untrusted). I'll create a bug to remove those from 
the upstream certdata.txt and that will put the versions in sync again.



bob


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [ANNOUNCE] NSS 3.53 release

[Robert Relyea]

On 6/10/20 10:48 PM, Martin Thomson wrote:

Is there an automated check we can run that will help us remember to
do this properly in future?  I really don't like having to remember
this sort of thing.



There isn't, which is why it happened, I think we should have one 
though, where would be the best place to put it? nss/automation?


bob



On Thu, Jun 11, 2020 at 3:52 AM Robert Relyea  wrote:

On 6/1/20 5:18 PM, JC Jones wrote:

The NSS team released Network Security Services (NSS) 3.53 on 29 May 2020. NSS 
3.53 will be a long-term support release, supporting Firefox 78 ESR.


Looks like we updated certdata.txt without updating the version number
in nssckbi.h. This caused some problems because I pulled the 3.52
certdata.txt, but with 3.53 coming out I verified that version number
didn't change and didn't pick up the 3.53 change.

We need to make sure we bump the version number when we make changes.
Just a reminder for the future...

Fortunately our QA tests found this, and I had already pushed our
version number because I removed a bunch of expired certs (that weren't
explicitly marked as untrusted). I'll create a bug to remove those from
the upstream certdata.txt and that will put the versions in sync again.


bob


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto



--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto