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: 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

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: 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/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

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: 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

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: [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

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

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: [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

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: 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

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 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: 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: 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: 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/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/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: 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_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: 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: 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: 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: [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: 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: 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: 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: 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 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: 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: 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: 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: 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/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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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: libnsssysinit

[Robert Relyea]

On 12/08/2014 05:05 AM, David Woodhouse wrote:

On Mon, 2014-12-08 at 10:15 +, Martinsson Patrik wrote:

So, to summarize,
$ sudo update-alternatives --install /usr/lib64/libnssckbi.so
libnssckbi.so.x86_64 /usr/lib64/p11-kit-proxy.so 1000

$ cat /etc/pki/nssdb/pkcs11.txt
library=/usr/lib64/p11-kit-proxy.so
name=p11-kit-proxy
NSS=trustOrder=100

You shouldn't need that bit. It was only pam_pkcs11 which wasn't loading
the smartcard modules via the nssdb, and it wants to load OpenSC
*explicitly* anyway. And besides, *nothing* should be
using /etc/pki/nssdb since we can ditch the Shared System Database
nonsense. Just let use pam_pkcs11 use its default /etc/pam_pkcs11/nssdb
instead.


Nothing in the above paragraph is true.

openning
1)sql:/etc/pki/nssdb is *STILL* the recommended action for applications 
(whether or not nssysinit is installed), and
2) what ever the recommendation, pam_pkcs11 still used /etc/pki/nssdb 
(by default, always), not /etc/pams_pkcs11/nssdb. (It never has used).





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: 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: libnsssysinit

[Robert Relyea]

On 12/04/2014 03:31 AM, David Woodhouse wrote:




You say that this shouldn't be necessary (and probably a bug), just to
clarify things for me, do you mean that,

1 ) adding the libnssckbi.so to shouldn't be necessary since it should
already be there from the beginning, and that the bug is that the
library is missing from the default setup, or

That one. libnssckbi.so is what provides the default trust roots. It's
*always* supposed to be loaded in an NSS system. You shouldn't need to
add it manually. I don't.
Huh? that is not true. libnssckbi.so is loaded by nssysinit, or by the 
application or by someone explicitly loading it into the 
pkcs11.txt/secmod.db. It is not loaded automatically by every nss 
application.


I believe the p11-kit does some magic to get it loaded for mozilla and 
the root store. Kai worked with stef to get that working, kai do you 
recall how that hooks in?


bob


(Note that you also shouldn't need to add your CAs to the actual sqlite
database in /etc/pki/nssdb either, since they should be coming from your
libnssckbi.so which is actually p11-kit.)



Now the libp11-proxy,


I worked around it by symlinking /usr/lib64/libnssckbi.so to
p11-kit-proxy.so instead of p11-kit-trust.so, which gives me the trust
roots *and* the other loaded modules. That one probably ought to be
the default.

Ok, I did the same thing. Using the alternatives system.


Firefox only asks me to log into my p11-kit-provided hardware tokens

when I go to a web site which wants a certificate, which is fair
enough.

Yes, same behavior here, I was mistaken when I stated that it actually
asked for pins to GNOME keyring and the Secret Store.
Firefox behaves in my opinion as expected, and I don't need to manually
mess with the users nssdb - the default will just work as I expect
(trusting my CA and ask for PIN to hardware token when requested).

Did you have to manually add libnssckbi to Firefox too? Remember, that
uses its own database and not sql:/etc/pki/nssdb.


Evolution does ask for a PIN for GNOME keyring and the Secret Store.
Stef suggests that's because Evolution doesn't handle
CKF_PROTECTED_AUTHENTICATION_PATH. I filed this bug for that:
https://bugzilla.gnome.org/show_bug.cgi?id=741059

Cool, then we have the same behavior and a possible reason for why it
behaves like it does. The same thing goes for chrome, I'll file a
bug-report to those ppl referring to this bug.

Chrome uses sql:$HOME/.pki/nssdb and not sql:/etc/pki/nssdb. Did you add
libnssckbi.so to *that* one?

(Evolution will use sql:/etc/pki/nssdb *if* it's enabled, and
sql:$HOME/.pki/nssdb if not. A piece of horridness fundamental to the
design of the NSS Shared System Database.)


breaks pam_pkcs11. Using the above config, pkcs11_inspect throws the
following,
...
DEBUG:pkcs11_lib.c:272: loading Module explictly,
moduleSpec=library=/usr/lib64/pkcs11/opensc-pkcs11.so
name=SmartCard module=/usr/lib64/pkcs11/opensc-pkcs11.so
DEBUG:pkcs11_lib.c:276: Failed to load SmartCard software (null)
ERROR:pkcs11_inspect.c:73:
load_pkcs11_module(/usr/lib64/pkcs11/opensc-pkcs11.so) failed:
Not really sure why this happens, but changing the lines,

I suspect this is because it's trying to explicitly load
opensc-pkcs11.so when it was *already* loaded. I wonder if works better
if you point it at p11-kit-proxy.so instead. Not sure if that can cope
better with multiple initialisations, if such a thing is even possible.

Further discussion of that might be more appropriately targeted to the
OpenSC mailing list, since pam_pkcs11 is theirs too.

In the meantime, given the bug that libnssckbi.so doesn't seem to show
up for you unless explicitly requested, a potential workaround might be
to point pam_pksc11 at a NSS DB which *doesn't* request it (it can
request p11-kit-trust.so instead).







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: libnsssysinit

[Robert Relyea]

On 12/04/2014 02:00 PM, David Woodhouse wrote:

On Thu, 2014-12-04 at 10:33 -0800, Robert Relyea wrote:

That one. libnssckbi.so is what provides the default trust roots. It's
*always* supposed to be loaded in an NSS system. You shouldn't need to
add it manually. I don't.

Huh? that is not true. libnssckbi.so is loaded by nssysinit, or by the
application or by someone explicitly loading it into the
pkcs11.txt/secmod.db. It is not loaded automatically by every nss
application.

OK... but applications such as firefox which actually want trust to work
should be loading it, right?
firefox loads libnssckbi.so only if not other 'Root Certs Module' has 
been loaded. the pk11-kit module is a Root Certs Module, so if it's been 
loaded, then libnssckbi.so isn't.


Yes, there are some applications which use NSS only for private crypto
purposes and don't need the trust roots, but Patrik seemed to be
suggesting that in RHEL, even Firefox wasn't loading libnssckbi.so until
he manually added it to pkcs11.txt/secmod.db.


I believe the p11-kit does some magic to get it loaded for mozilla and
the root store. Kai worked with stef to get that working, kai do you
recall how that hooks in?

I thought we really were just replacing libnssckbi.so with our own.
Which is fine as long as it's actually being loaded.
Sort of, It's not the same name, it's a different module, but it has the 
same attributes.


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: Reducing NSS's allocation rate

[Robert Relyea]

On 11/11/2014 12:32 PM, Ryan Sleevi wrote:

On Tue, November 11, 2014 10:26 am, Nicholas Nethercote wrote:

  On Mon, Nov 10, 2014 at 7:06 PM, Ryan Sleevi
  ryan-mozdevtechcry...@sleevi.com wrote:

Not to be a pain and discourage someone from hacking on NSS

  My patches are in the following bugs:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1094650
  https://bugzilla.mozilla.org/show_bug.cgi?id=1095307
  https://bugzilla.mozilla.org/show_bug.cgi?id=1096741

  I'm happy to hear specific criticisms.

  Nick
  --

Not trying to be a pain, but I don't think that's fair to position like
that. I'd rather the first question be answered - each one of your patches
adds more branches and more complexity.


OK, looking at that patches, I would challege that assertion. The patch 
in  https://bugzilla.mozilla.org/show_bug.cgi?id=1094650 actually 
simplifies the code. I do agree we need to make complexity versus reward 
calculations, but most of these changes don't raise the complexity bar 
very high, if at all.

That part is indisputable, even if
it may be seen as small.

Sorry, I just disputed it;).

  However, what measures do we have to ensure that
this is meaningfully improving any objective measure of performance (other
than allocation churn, which allocators are exceptionally capable of
handling)?
I agree that these changes should be targeted based on instrumentation. 
I believe Nicholas has provided this in the bug.

  How do we ensure this doesn't regress?
I think that depends on the change.  Certainly 
https://bugzilla.mozilla.org/show_bug.cgi?id=1095307 is simple enough, 
that the combination of review and normal testing should give us 
confidence in the patch's correctness.



I'd say the same forhttps://bugzilla.mozilla.org/show_bug.cgi?id=1094650  .
The patch in bug  https://bugzilla.mozilla.org/show_bug.cgi?id=1096741  seems 
more risky, as it delays allocation. So it would require more testing and and a 
more dillegent review, and may actually cross the complexity/benefit bar for 
me. (also, the code in question is code meant to avoid cache attacks, we want 
to make sure we don't reintroduce a new back channel attack).


Otherwise, we're adding
complexity without any benefits. And I don't think there are - or at
least, I haven't seen, other than reduces allocations.
For me the bar is pretty low, particularly since I've seen patches that 
actually simplify the code.  The 'use static until some threshold, the 
malloc' is a pretty well established meme in NSS already, and is 
particularly safe if we can see it's entire use over a single function.


The bigger issue is are we getting proper bang for the buck.  Here we 
have an NSS user who is admittedly tuning for his particular workload, 
but doing performance tuning. It's targeted by hitting the largest 
offenders using instrumented tools to figure that out given the client's 
workload, then knocking out the low hanging fruit. I think that's pretty 
classic optimization strategy.


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 modutil: Adding PKCS#11 module with PIN to nssdb

[Robert Relyea]

On 11/06/2014 03:12 PM, Mike Gerow wrote:

Apologies if a dupe of this shows up. I had posted my last question
without _properly_ subscribing to list and so it is stuck in some kind
of moderator queue.

I'm trying to add the opencryptoki PKCS#11 module to Chrome/Firefox's
nssdb, and it seems to have worked properly:

$ modutil -dbdir sql:$HOME/.pki/nssdb -list

Interesting that you got firefox to point to here...


Listing of PKCS #11 Modules
---
   1. NSS Internal PKCS #11 Module
slots: 2 slots attached
status: loaded

slot: NSS Internal Cryptographic Services
token: NSS Generic Crypto Services

slot: NSS User Private Key and Certificate Services
token: NSS Certificate DB

   2. TPM
library name: /usr/lib/x86_64-linux-gnu/opencryptoki/libopencryptoki.so.0
slots: 1 slot attached
status: loaded

slot: OpenCryptoki Software Backend
token: IBM OS PKCS#11
---

The only issue is that when the application uses the module for the
first time it requests a PIN from the user. I'm actually more
interested in the privilege separation that a PKCS#11 module provides
so I have this PIN set to a simple value that I don't really consider
a secret.
Firefox doesn't cache pins for tokens anywhere. I don't think Chrome 
does either. It's a tricky thing that can easily cause problems if it 
goes wrong. If, for instance, you had a removable token and replaced 
that removable token with a different token. If the pin caching code 
isn't implemented correctly, you could hammer the token with retry 
attempts without the user every noticing, until they try to use the 
token for real.


I know some server products some pin caching so that you can use 
unattended operations, and the code records the token name so there is 
at least some attempt to prevent token smashage.


Upshot is there probably isn't a way to do what you want, and providing 
one could be a slightly longer rope than we'd like to pass on to the users.


bob


Is it possible to add the PIN for the module to the nssdb as well so
that I can prevent the user from being asked for it?





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 modutil: Adding PKCS#11 module with PIN to nssdb

[Robert Relyea]

On 11/06/2014 04:08 PM, Mike Gerow wrote:

Thanks for the quick reply! I can see how caching the PIN would have
its issues, but I'm not interested in having NSS ask for the PIN once
and save it, but in configuring it to just use a provided PIN in the
first place.
Still has the same issue, if you configure a pin, but don't tie it to a 
token (rather than a slot), you could have that pin applied to the wrong 
device. The functionality you described above is what servers do (the 
user configures the password for a set of tokens beforehand, not 
automatic pin caching.


As I think about this more, though, I guess the solution might lie on
the PKCS#11 module side instead of in NSS, in that the token shouldn't
have its CKF_LOGIN_REQUIRED flag set (and of course be configured so
as not to require C_Login to be called before doing cryptographic
operations).
You are correct. If you don't have CKF_LOGIN_REQUIRED set, NSS won't 
prompt for the password.
That's how NSS keeps from getting password prompts when doing raw SSL 
(the internal crypto services slot is separate from the database slot 
and doesn't require a password). In FIPS mode you will get password 
prompts when doing raw SSL.


bob


But now my problem is that I have to convince opencryptoki to do
something it probably doesn't want to :-). Oh well, thanks again for
cluing me in.




No problem



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: When will TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite be available?

[Robert Relyea]

On 09/28/2014 03:09 PM, Eric Rescorla wrote:

Eventually, but it's not a very high priority. Is there some reason you
can't use AES-128?
Actually the issue is ths SHA384. We need to implement the new PKCS #11 
spec to TLS key derive in softoken first.


bob


-Ekr

On Mon, Sep 22, 2014 at 4:49 PM, MJBUSCH mikebu...@gmail.com wrote:


When will TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite be
available?

I am looking to support websites that are built with this crypto. Only IE
is supported.

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: issues with NSS 3.12.4

[Robert Relyea]

On 09/25/2014 04:22 AM, Sunil Raj wrote:

Hi, Even I am facing the same issue. Were u able to find the problem?


Java is trying to do something that isn't allowed in FIPS mode. It's 
trying to import a key in the clear. It should instead generate the key 
inside the token rather than import it.


bob




--
View this message in context: 
http://mozilla.6506.n7.nabble.com/issues-with-NSS-3-12-4-tp308894p323597.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: Adding local cryptographic algorithms to NSS library.

[Robert Relyea]

On 08/04/2014 05:43 AM, Andrey Askerko wrote:

I want to add  support of local cryptography algorithm into firefox. And I want 
to ask some questions:
1) I must modify only NSS module, or some firefox functions/definitions too?
2) Where I can find some manual, how I can add algorithm into NSS and which 
files I must modify?

regards.  Andrey.

How do you want to use the cryptographic algorithms?

NSS can accept new algorithms through a PKCS #11 module (no need to 
modify the built-in softoken) dynamically, but we have not put in any 
features to allow, say, new SSL ciphers without modifying NSS itself. 
However if you are trying to access the algorithms through the new 
webcrypto interface, it may be possible to access without modifications. 
I don't know how the webcrypto interface is implemented in PSM. The big 
question is how is the webcrypto cipher specification mapped to PKCS #11 
mechanism.


For access using CMS/Smime, you simply need to dynamically add a new 
oid, but since you are talking about firefox, I presume you aren't 
interested in CMS.


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: modutil add softokn3.dll error

[Robert Relyea]

On 07/21/2014 05:48 AM, ramahmoo wrote:

Hi,

I am trying to add the newly built softtoken dll using the following command

modutil -add Softoken -mechanisms RSA:DSA:RC4:DES -libfile
C:\nss-3.16.1\dist\WIN954.0_OPT.OBJ\lib\softokn3.dll -dbdir c:\nssdb

But i am getting the following error

ERROR: Failed to add module Softoken. Probable cause : Unknown PKCS #11
error
.

No clue what is wrong


Softoken needs additional parameters to work as a PKCS #11 module. If 
you are trying to run more than one softoken, then I also suggest 
renaming your new softoken.



bob




--
View this message in context: 
http://mozilla.6506.n7.nabble.com/modutil-add-softokn3-dll-error-tp319737.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: SSLKEYLOGFILE always enabled

[Robert Relyea]

On 07/16/2014 07:31 AM, Jonathan Schulze-Hewett wrote:

Does having this enabled violate the FIPS 140 requirements on exposing key 
materials in the clear?


No, because the key logging fails if you are in FIPS mode (It used the 
PK11_ExtractKeyValue() to get the key, which will return an error in 
FIPS mode.


In general, it's pretty difficult for anything in the SSL layer to 
actually foil FIPS because FIPS is implemented in softoken itself.


bob


Sincerely,
Jonathan


-Original Message-
From: dev-tech-crypto 
[mailto:dev-tech-crypto-bounces+schulze-hewett=infoseccorp@lists.mozilla.org]
 On Behalf Of Ryan Sleevi
Sent: Tuesday, July 15, 2014 6:12 PM
To: mozilla's crypto code discussion list
Subject: Re: SSLKEYLOGFILE always enabled

On Tue, July 15, 2014 1:11 pm, Tom Ritter wrote:

  Is having it in by default useful enough to outweigh the risk?

  When the Dual_EC_DRBG news stories were blowing it, it was revealed
  that you could switch to it by just changing the Windows Registry.
  It's a Windows-supported backdoor - no malicious code needs to stay
  running on your system - just flip that bit, and delete yourself.
  After that, you're all set.

  Similarly, having this feature provided by default seems like it
  provides a very easy, supported way to extract sensitive key data to
  the filesystem or some other covert channel - without invalidating
  package signatures, hashes of libraries or binaries, etc.

  Don't get me wrong, it's invaluable to be able to use it for
  debugging, but I question to need to have it enabled by default...

  -tom

Either you control your machine, or you do not. Either the OS provides
robust controls, or it does not.

If an attacker has physical access to your machine and can set this, or if
an attacker can control your operating environment such that the
environment variable is set, it's all over. This is no different than
malware hijacking your browser of choice and hooking the API calls - which
we do see for both Firefox and Chrome.

Now, we can talk about grades of attacks, and finer nuances, but for a
debug bit that has to be set client side, it really seems a no-op, and for
which common sense would suggest is not a reasonable threat model.






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: How to export private key in RSA format from NSS

[Robert Relyea]

On 07/15/2014 08:05 PM, Chuck Lee wrote:


Yes, but it doesn't work because it also calls 
PK11_ExportPrivKeyInfo() to get the RSA private key info.


Now I am trying to decrypt key exported by 
PK11_ExportEncryptedPrivKeyInfo() with method 
SEC_OID_PKCS12_V2_PBE_WITH_SHA1_AND_40_BIT_RC4 directly, which seems 
to be the most simple method to decrypt.


Hmm, 1) are you sure you used that method to export the key? It's not a 
very strong algorithm, the PKCS #12 files use it to wrap the 
certificate, not the key itself. 2) If you want to decrypt, you need to 
use that method to generate a PBE key and use it to export.


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 Custom Crypto Module

[Robert Relyea]

On 07/10/2014 01:53 PM, ramahmoo wrote:

Thanks,i would ready the documentation.

Can i extend/modify the NSS internal pkcs#11 source (softokn3.dll source) to
achieve my requirement?
It's probably not a good idea to try to create your own softokn3.dll to 
replace the mozilla one, you will be forever chacing the upstream 
version (Any new ciphers supported in firefox will wind up in 
softoken3.dll).


You could use the softoken source to build our own PKCS #11 module, 
though I would recommend using ckfw instead.


There are tools to help install your own PKCS #11 modules, and you don't 
have to update them everytime NSS updates.

look at:

In NSS itself, there's modutil:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/tools/NSS_Tools_modutil
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Reference/NSS_tools_:_modutil
http://lxr.mozilla.org/nss/source/cmd/modutil/

From the coolkey project, there's pk11install:
http://svn.fedorahosted.org/svn/coolkey/trunk/src/install/
This tools has code that searches for all your mozilla profiles and 
installs your module in them. Once installed, new version of Firefox 
will automatically inherit your PKCS #11 module.

Or it is meant only internal usage. If it can be
used as starting point then which methods should i override?
I'd suggest starting with capi or builtins as a better example of what 
you need to build a pkcs #11 module.


bob






--
View this message in context: 
http://mozilla.6506.n7.nabble.com/NSS-Custom-Crypto-Module-tp319226p319284.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: Other ECC Curves

[Robert Relyea]

On 06/10/2014 09:47 AM, Kurt Roeckx wrote:
 On Mon, Jun 09, 2014 at 04:27:56PM -0700, Rick Andrews wrote:
 AFAIK, Symantec and other CAs have added ECC roots to Mozilla's root store 
 using NIST curves. Are any other ECC curves supported by Mozilla, in case 
 one wanted to use a different curve? Is the list of supported algorithms and 
 key sizes published somewhere?
 As far as I know NSS currently only supports P256, P384 and P521.

More exactly NSS can support the initial TLS suite of curves, but almost
all users (including mozilla and redhat) of NSS just compile the above 3
NIST curves.


 I would like to add brainpool to that, which should be easy.

 I would also like to see Ed25519, but there is no standard on how
 to do that yet.

Adding support for any curve within NSS should be relatively
straightforward. Convincing particular entities to ship with other
curves enable is another matter.

bob


 Kurt





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: ECC, FIPS Mode, and PKCS#11 devices

[Robert Relyea]

On 05/30/2014 07:47 AM, Jonathan Schulze-Hewett wrote:
 To whom it may concern,

 I have a PKCS#11 device that supports ECC operations. In particular 
 C_GetMechanismList includes the following items:

 CKM_ECDH1_DERIVE
 CKM_ECDH1_COFACTOR_DERIVE
 CKM_EC_KEY_PAIR_GEN
 CKM_ECDSA

 The module is added to Firefox using nsIPKCS11::addModule with 0 for both the 
 cryptoMechanismFlags and the cipherFlags.

 If I put Firefox into FIPS mode it uses my PKCS#11 module to perform ECC 
 computations during TLS negotiation where ecdhe is being preferred by the 
 server. In particular, it will call C_GenerateKeyPair (to generate an ECC key 
 pair), C_DeriveKey (to derive a shared secret), C_GetAttributeValue (to 
 obtain the shared secret), C_CreateObject (to add an RSA public key for some 
 reason), and C_WrapKey (to wrap the secret key with the recently added RSA 
 key).

 Fundamentally I think this should work, but Firefox tends to hang after 
 C_WrapKey returns. That's something that I'm continuing to examine. Anyway, 
 the crux of the problem with respect to this mailing list is that I don't 
 think Firefox should be using the token to perform these operations as I set 
 flags in addModule to 0. 

 Any guidance on this issue you can provide is most welcome.

 Thanks in advance,
 Jonathan

Hi Jonathan,

Fundamentally, I think you are right. There were some bugs where ECC
wasn't using the prefered flags properly. Which version of Firefox?

The other possible issue may be the curves. Which curves do you support
, and which are you negotiating in the TLS operation?

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: Chrome: From NSS to OpenSSL

[Robert Relyea]

On 04/08/2014 06:31 AM, Alan Braggins wrote:
 On 08/04/14 13:11, Jean-Marc Desperrier wrote:
 Ryan Sleevi a écrit :
 reliance on PKCS#11 means that there are non-trivial overheads when
 doing something as simple as hashing with SHA-1. For something
 that is
 such a simple transformation, multiple locks must be acquired and the
 entire NSS internals may*block*  if using NSS on multiple threads, in
 order to prevent any issues with PKCS#11's threading design.

 I don't believe that PKCS#11's threading design mandates that.
 Implementation easily can have that problem, and NSS sure does, but I
 think it would be possible to design a PKCS#11 implementation than let's
 you do hashing without requiring locks.
 Or maybe, it's more because of PKCS#11 session management rules that you
 hardly can avoid them.

 If you do all your hashing in one session, then the rules require
 you to use locks. The obvious answer is don't do that then, but
 PKCS#11 libraries for dumb devices are allowed to only support a
 limited number of sessions and force you to juggle C_GetOperationState/
 SetOperationState.

 But if https://developer.mozilla.org/en/docs/PKCS11_FAQ is accurate,
 it will only fall back on the single session solution if the device
 requires it.

 And for hashing without secret keys (plain digest, not HMAC, no
 C_DigestKey calls), there's never any reason to use a limited device
 for that operation.

To be clear, for any token that supports multiple sessions, NSS only
grabs an uncontended session lock. NSS does that not because of PKCS #11
semanatics, but because applications sometimes gets the threading wrong.
If you are contending on that lock it's because the application messed
up and tried to do two operations on the same context at the same time.
The lock isn't grabbed because it's needed by NSS, only because
applications get this kind of thing wrong a lot. Same with the NSS locks
in SSL.

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: Cryptoki interface to decrypt mail with thunderbird

[Robert Relyea]

On 03/18/2014 04:29 AM, Leon Brits wrote:
 Robert,

 Thanks for your help. This discussion has helped me to find the error in our 
 padding implementation for symmetric ciphers using OpenSSL which defaults to 
 always pad.

 Encryption and decryption via thunderbird now works just fine.

go ahead and right a bug against NSS not calling Final in the error path
for S/MIME as well.

Your semantic is correct for CKM_XXX_CBC_PAD mechanism. NSS only uses
those, however to do private key wrapping.

bob

 Thanks
 LJB





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: Cryptoki interface to decrypt mail with thunderbird

[Robert Relyea]

On 03/13/2014 05:12 AM, Leon Brits wrote:
 Robert,

 Attached is a log of the backtrace when I try to use Thunderbird to decrypt 
 an email. As you can see in the log it reaches C_DecryptUpdate(), but then 
 asserts at cmscipher.c:452.

I don't see the attachment? did you forget or did the mailing list strip it?

 Now we use OpenSSL to perform these cryptographic operations and if you give 
 its DecryptUpdate() function exactly (N * blocksize) of data then it will 
 keep 1 block back waiting for either a DecryptUpdates() with more data or a 
 DecryptFinal() at which stage it will return the plaintext of that last block.
cmscipher does call DecryptUpdate, but for the symmetric portion, not
the asymmetric portion. We were talking about key unwrapping/decrypt in
RSA. This is clearly an symmetric operation (DES3 or AES or something).

Looks like you are trying use a PAD mechanism when NSS requested a CBC
mechanism. In the CBC mechanism NSS will always ask for even number of
blocks and expect to get back all the blocks. In the PAD mechanism, the
PKCS #11 module needs to hold back one block in order to handle padding
correctly.

 So what I think is happening here is that you call DecryptUpdate() with data 
 which fall on the blocksize boundary and OpenSSL buffer the last blocksize of 
 data and you expect everything back and therefore asserts. My question then 
 is why do you call DecryptUpdate() here. A Decrypt() would solve my problem.
Can't call decrypt here, because I probably have more blocks coming.
This is encrypting the email message, so it's streaming.


The fundamental issue here is you are probably trying to do more than
you need to if you just want a signing/decryption token. You don't need
to implement the symmetric algorithms, so if you just implement decrypt
(rather than unwrap), NSS will use it's internal implementation to do
the symmetric operations.

If you are trying to build a full replacement (because you are managing
the keys in your token or something, then you need to return all the
blocks requested when doing a CBC operation (rather then a CBC_PAD
operation).

bob

 Thanks for your time!
 Regards,
 LJB









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: initializing the standalone nss soft token (libsoftokn3.so)

[Robert Relyea]

On 03/10/2014 08:50 PM, Dave wrote:
 I'm having trouble initializing the nss soft token when linking against it 
 directly.  The function _NSSUTIL_EvaluateConfigDir (utilpars.c) is 
 segfaulting when passing the following initialization arguments to 
 C_Initialize:

   CK_CHAR * configString = (unsigned char *)
   configdir='/tmp/' certPrefix='prefix1' keyPrefix='prefix2' 
 secmod='secmod.db' flags='readonly,forceopen' ;
   CK_C_INITIALIZE_ARGS ck_init_args;
   ck_init_args.CreateMutex = NULL;
   ck_init_args.DestroyMutex = NULL;
   ck_init_args.LockMutex = NULL;
   ck_init_args.UnlockMutex = NULL;
   ck_init_args.flags = CKF_OS_LOCKING_OK;
   ck_init_args.LibraryParameters=configString;
   ck_init_args.pReserved=NULL;

 I'm building against the ubuntu version: 2:3.15.4-1ubuntu6 on an x86_64 
 machine.

 What is the correct formatting of the LibraryParameters string passed via 
 CK_C_INITIALIZE_ARGS to C_Initialize? 

ck_init_args.LibraryParameters=configString;

should be

ck_init_args.LibraryParameters=configString;






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 algorithm performance

[Robert Relyea]

On 03/04/2014 03:54 PM, Julien Pierre wrote:
 Did anyone ever write a script that measures the performance of all
 the low-level algorithms in freebl, and collects the data in a way
 that's easy to compare ? This would probably be using bltest.
 This is for the purpose of evaluating different compilers/optimization
 options.
 If so, sharing would be much appreciated.

Nelson did. They are under the nss/tests/ciphers. It uses bltest. I
believe it was turned off because bltest couldn't handle the corner case
of leading zeros in RSA operations, which lead to periodic failures of
the tests, but you can still run performance.sh yourself. I used it to
test the performance of the AES-NI code when it was added.

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: SSL objects and NSS code communicating with PKCS#11 module

[Robert Relyea]

On 03/05/2014 01:21 AM, Raad Bahmani wrote:
 Hello Robert,

 thank your for your answer !

 
 3) Which algorithm is used for login with SSL ?
 I'm not sure what you mean by 'login with SSL'. Do you mean create an
 SSL handshake? do you  mean client auth? do you mean login to the token
 to use SSL?
 you are right, my question is vaguely formulated !
 I guess it would be: client authentication

 This is the scenario:

 1) A user opens a web-page where he can log in using his SSL certificate.
 2) He clicks on a link which says: Log-In with SSL Certificate.
 3) Firefox handles this request by calling functions of my PKCS#11 module.

 Where do I find the code which calls the functions of my module?

You don't need to implement the SSL key exchange algorithms for this,
you simply need to implement signing.

Your best bet is: https://developer.mozilla.org/en-US/docs/PKCS11_Implement
Your token profile is 'Signing tokens'

When you see requests for attributes or objects that aren't part of the
PKCS #11 spec, you should respond as the PKCS #11 spec directs for
unknown attributes and objects. NOTE: if you have a list of mixed
attributes, PKCS #11 requires you to fill in all the attributes you do
understand and mark the ones you don't with length of -1.

These additional attributes are not necessary to be able to create
client auth connections.



 
 C_FindObjects with:
 session-handle: 100
 ulMaxObjectCount: 1
 What did you return here? This is a very basic Find object call looking
 for an object that you probably don't support, You should return no
 object here.
 As I mentioned, my module *simulates* a smart-card, so always a dummy
 ID/Handle is returned when for example a session is required to be
 created or when the  C_FindObjects  is called.

 If a dummy object-handle is not returned the firefox keeps calling the
 C_Find* functions as you can see bellow.

Once your token is loaded, firefox will ask it for all sorts of objects.
If you don't know the object, you should always return 'no such object'.
If you pretend to return an object you don't know about, things will not
end well...

In simulating a smart card, do you claim to be a hardware device? If so
NSS will just ask you at token insertion of a full range of objects
ahead of time and then never bother you (assuming you have only a small
number of certs/crls/etc).

What I see below is exactly what I expect (NSS asking you, do you know
this cert? do you have the CRL for this CA, etc.). You should expect to
see these calls continually if you are functioning correctly.

bob





 msg 29: C_GetSlotInfo
 msg 30: C_FindObjectsInit with:
 msg 31: session-handle: 100l
 msg 32: ulCount: 4l
 msg 33: template 
 msg 34: --
 msg 35: Attr0 Type L: 1l
 msg 36: Attr0 Type X: 1l
 msg 37: Attr0 Value L: 1l
 msg 38: Attr0 Value X: 1
 msg 39: Attr0 ulValueLen: 1l
 msg 40: --
 msg 41: Attr1 Type L: 0l
 msg 42: Attr1 Type X: 0l
 msg 43: Attr1 Value L: 1l
 msg 44: Attr1 Value X: 1
 msg 45: Attr1 ulValueLen: 8l
 msg 46: --
 msg 47: Attr2 Type L: 129l
 msg 48: Attr2 Type X: 129l
 msg 49: Attr2 Value L: 831291696l
 msg 50: Attr2 Value X: 318c8130
 msg 51: Attr2 ulValueLen: 143l
 msg 52: --
 msg 53: Attr3 Type L: 130l
 msg 54: Attr3 Type X: 130l
 msg 55: Attr3 Value L: 235733762l
 msg 56: Attr3 Value X: e0d0302
 msg 57: Attr3 ulValueLen: 5l
 msg 58: C_FindObjects with:
 msg 59: session-handle: 100l
 msg 60: ulMaxObjectCount: 1l
 msg 61: C_FindObjectsFinal (100l)
 msg 62: C_FindObjectsInit with:
 msg 63: session-handle: 100l
 msg 64: ulCount: 4l
 msg 65: template 
 msg 66: --
 msg 67: Attr0 Type L: 1l
 msg 68: Attr0 Type X: 1l
 msg 69: Attr0 Value L: 1l
 msg 70: Attr0 Value X: 1
 msg 71: Attr0 ulValueLen: 1l
 msg 72: --
 msg 73: Attr1 Type L: 0l
 msg 74: Attr1 Type X: 0l
 msg 75: Attr1 Value L: 1l
 msg 76: Attr1 Value X: 1
 msg 77: Attr1 ulValueLen: 8l
 msg 78: --
 msg 79: Attr2 Type L: 129l
 msg 80: Attr2 Type X: 129l
 msg 81: Attr2 Value L: 831291696l
 msg 82: Attr2 Value X: 318c8130
 msg 83: Attr2 ulValueLen: 143l
 msg 84: --
 msg 85: Attr3 Type L: 130l
 msg 86: Attr3 Type X: 130l
 msg 87: Attr3 Value L: 15470093l
 msg 88: Attr3 Value X: ec0e0d
 msg 89: Attr3 ulValueLen: 3l
 msg 90: C_FindObjects with:
 msg 91: session-handle: 100l
 msg 92: ulMaxObjectCount: 1l
 msg 93: C_FindObjectsFinal (100l)
 msg 94: C_FindObjectsInit with:
 msg 95: session-handle: 100l
 msg 96: ulCount: 4l
 msg 97: template 
 msg 98: --
 msg 99: Attr0 Type L: 1l
 msg 100: Attr0 Type X: 1l
 msg 101: Attr0 Value L: 1l
 msg 102: Attr0 Value X: 1
 msg 103: Attr0 ulValueLen: 1l
 msg 104: --
 msg 105: Attr1 Type L: 0l
 msg 

Re: SSL objects and NSS code communicating with PKCS#11 module

[Robert Relyea]

On 03/03/2014 04:31 AM, Raad Bahmani wrote:
 Hello together,

 I need to implement a PKCS11-library which simulates a smart-card and
 responds to login attempts with SSL certificates.

 I have found out that SSL needs the following mechanisms, so the
 C_GetMechanismList of my library specifies them as supported.

 - CKM_SSL3_PRE_MASTER_KEY_GEN
 - CKM_SSL3_MASTER_KEY_DERIVE
 - CKM_SSL3_KEY_AND_MAC_DERIVE
 - CKM_SSL3_MD5_MAC
 - CKM_SSL3_SHA1_MAC

 When trying to login using SSL the following functions are called before
 the firefox crashes ! :/

 These are my questions:

 1) What are these objects: ce534354, ce534353,  b316030,
 102, 318c8130, e0d0302
It's not clear without context. These look like they could either be
object ID's or Attribute ID's.
The ones starting with ce5343xx are NSS specific attributes or objects.
Your library can reject or ignore them (depending on context. 102 looks
like a regular PKCS #11 addribute or id (depending on context). The
others look like memory addresses, so there's nothing I can really tell
about them. NSS never used those as PKCS #11 id's
 2) Where can I find (in cross-reference ) the source code of firefox/NSS
 which communicates with my library ?
The NSS specific id's are defined in lib/util/pkcs11n.h
 3) Which algorithm is used for login with SSL ?
I'm not sure what you mean by 'login with SSL'. Do you mean create an
SSL handshake? do you  mean client auth? do you mean login to the token
to use SSL?

 Thank you in advance.
 - Raad




 +---
 C_GetFunctionList
 +---
 C_Initialize
 +---
 C_GetInfo
 +---
 C_GetSlotList
 +---
 C_GetSlotList
 +---
 C_GetSlotInfo
 +---
 C_GetTokenInfo
 +---
 C_GetMechanismList
 +---
 C_OpenSession with:
 lag: 4l
 slotId: 22l
 +---
 C_FindObjectsInit with:
 session-handle: 100
 ulCount: 1
 Attr0 Value: ce534354
 +---
 C_FindObjects with:
 session-handle: 100
 +---
 C_FindObjectsFinal
 +---
 C_GetSlotInfo
 +---
 C_FindObjectsInit with:
 session-handle: 100
 ulCount: 4

 template 
 Attr0 Type: 1
 Attr0 Value: 1
 Attr0 ulValueLen: 1
 --
 Attr1 Type: 0l
 Attr1 Value: ce534353
 Attr1 ulValueLen: 8
 --
 Attr2 Type: 129l
 Attr2 Value: b316030
 Attr2 ulValueLen: 98l
 --
 Attr3 Type: 130l
 Attr3 Value: 102
 Attr3 ulValueLen: 3l
 +---
 C_FindObjects with:
 session-handle: 100
 ulMaxObjectCount: 1

What did you return here? This is a very basic Find object call looking
for an object that you probably don't support, You should return no
object here.
 +---
 C_FindObjectsFinal
 +---
 C_FindObjectsInit with:
 session-handle: 100l
 ulCount: 4l
  template:
  Attr0 Type: 1l
 Attr0 Value X: 1
 Attr0 ulValueLen: 1l
 --
 Attr1 Type: 0l
 Attr1 Value: 1
 Attr1 ulValueLen: 8l
 --
 Attr2 Type: 129l
 Attr2 Value: 318c8130
 Attr2 ulValueLen: 143l
 --
 Attr3 Type L: 130l
 Attr3 Value: e0d0302
 Attr3 ulValueLen: 5l

Here the objects are all standard PKCS #11 objects. You seemed to be
confused about the attribute values. Please look at the PKCS #11 spec
for what those values are. They are all there (note your tool is
printing them as long decimal integers, but they are listed in the spec
as hex values).
 +---
 C_FindObjects with:
 session-handle: 100l
 ulMaxObjectCount: 1l
 +---
 C_FindObjectsFinal
It looks like you found an object and returned it as handle 71l
 +---
 C_GetAttributeValue with:
 session-handle: 100l
 hObject: 71l
 ulCount: 2l

 template:
 Attr0 Type X: 1l
You are missing something here, our template should have 2 objects in it




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: SHA-256 support

[Robert Relyea]

On 11/19/2013 02:50 AM, Rob Stradling wrote:
 On 11/18/2013 07:00 AM, Gervase Markham wrote:
 Hi everyone,

 Following Microsoft's announcement re: SHA-1, some CAs are asking
 browser and OS vendors about the ubiquity of SHA-256 support. It would
 be a help to them if we could say:

 - Which version of NSS first supported SHA-256

 Gerv, SHA-256 isn't the only algorithm of interest here.

 The latest Windows Root Certificate Program requirements [1] permit
 CAs to use SHA-256, SHA-384 and SHA-512.  Unsurprisingly, these 3
 functions from the SHA-2 family are what the Windows CryptoAPI
 actually supports (since XP SP3).



My evaluation on when we supported SHA-2 covers all 3 hash functions.


 On 19/11/13 02:20, Robert Relyea wrote:
 I think it's safe to say if your NSS ap is newer than a decade old, you
 have SHA-2 support. The one caveat is that SHA-224 support was added
 much later, but SHA-256, SHA-384, and SHA-512 have all been supported
 for a while.

 SHA-224 isn't supported by CryptoAPI, and CAs aren't permitted (by
 [1]) to use it anyway.  Ditto for the SHA-512/224, SHA-512/256 and
 SHA-512/t functions that were added to the SHA-2 specification [2]
 last year.

We don't support the truncated* SHA-512 functions (other than
SHA-384). SHA-224 is a truncated* SHA-256.


* truncated hashes also have their own initialization vector, so
SHA-224(x) != trunc(SHA-256(x)) even though SHA-224 uses the same base
algorithm.


 [1]
 http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx

 [2] http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf





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: SHA-256 support

[Robert Relyea]

On 11/19/2013 10:40 AM, Wan-Teh Chang wrote:
 Bob's answer is accurate.

 Note that CAs are more interested in SHA-2 based signature support
 rather than plain SHA-2 support. So another way to track down the NSS
 version is to look at the CVS history of the secvfy.c file:

 http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/security/nss/lib/cryptohi/secvfy.crev=HEADmark=1.30

 The relevant revisions are:

 1.7 nelsonb%netscape.com2002-12-11 22:05 Support SHA256, SHA384, and
 SHA512 hashes in NSS.

 1.14 wtchang%redhat.com2005-08-12 16:50 Bugzilla Bug 296410: enlarge
 the buffer size for message digest so that we can generate and verify
 signatures that use SHA-512.

 1.17 rrelyea%redhat.com2006-02-07 22:14 Bug 320583 Support for
 SHA256/384/512 with ECC signing

 So it is safe to say that by mid 2006 (NSS 3.11.1, released on
 2006-05-05) the support of SHA-2 based signatures in NSS was already
 stable and complete, covering both RSA and ECDSA signatures. 
This would map to*:
  Firefox  2.0.0.1
  Thunderbird 1.5.0.10
  Mozilla 1.9a1
  Seamonkey 1.0.8

 Another
 evidence of mature support is the FIPS 140-2 validation of NSS 3.11.4
 (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2007.htm#814).

 A very conservative response would be NSS 3.11.4
 (http://www-archive.mozilla.org/projects/security/pki/nss/nss-3.11.4/nss-3.11.4-release-notes.html)
 and later.

This yields the same list (it looks like mozilla picked up 3.11.5 as the
first nss 3.11 build it shipped).


* Source, the cvs log for nss.h, the one file known to change for every
release (because it has the NSS version numbers).

 Wan-Teh




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: SHA-256 support

[Robert Relyea]

On 11/18/2013 07:00 AM, Gervase Markham wrote:
 Hi everyone,

 Following Microsoft's announcement re: SHA-1, some CAs are asking
 browser and OS vendors about the ubiquity of SHA-256 support. It would
 be a help to them if we could say:

 - Which version of NSS first supported SHA-256
I quick look at the cvs logs shows that it was supported at least by nss
3.7. (There's an NSS_3_7_RTM tag for revision 1.4 for sha512.c, which
has sha512, sha384, and sha256 support).
 - Which versions of Mozilla/Firefox/SeaMonkey/Thunderbird that translates to
The cvs logs include tags for various
Mozilla/Firefox/Thunderbird/Seamonkey releases (the code predates
mozilla's move to hg).

The earliest mozilla release was Mozilla 1.3.
The earliest thunderbird release was 0.2 (essentially every thunderbird
release).
The earliest firefox release was 0.8 (essentially every release of firefox).
The earliest seamonkey was 1.0 (again, essentially every release of
seamonkey).


 They can use the NSS version number info to work out the answer for
 other NSS-using applications.
Yes, though the upshot is if your nss-based ap isn't Netscape or AOL
branded, it almost certainly has SHA-2 support. (heck even AOL branded
things like photon has the SHA-2 support).

 Is anyone from the NSS team able to easily provide that info? I could go
 repo and Bugzilla-mining, but I'd be worried about making a mistake.

SHA-256/SHA-512 code has been in for a very long time. Nelson checked in
the initial revision around Nov 2002, and the first NSS release (3.7)
was sometime between Nov 2002 and Mar 2003. The change predates the mass
tri-license work done in 2004 (I see gerv's tri-license changes in the
logs).

I think it's safe to say if your NSS ap is newer than a decade old, you
have SHA-2 support. The one caveat is that SHA-224 support was added
much later, but SHA-256, SHA-384, and SHA-512 have all been supported
for a while.

 Gerv




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: oddball, old cipher suite in firefox client hello

[Robert Relyea]

On 11/01/2013 01:43 AM, Brian Smith wrote:
 On Fri, Nov 1, 2013 at 1:28 AM, Jeff Hodges j...@somethingsimilar.com wrote:
   /* New non-experimental openly spec'ed versions of those cipher suites. */
   #define SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA 0xfeff
   #define SSL_RSA_FIPS_WITH_DES_CBC_SHA   0xfefe

 Does anyone know what spec this cipher suite came from? And, perhaps, why
 it's still a good idea to be in the client hello? This last question I ask
 very gently and out of curiosity.
 See 
 http://www-archive.mozilla.org/projects/security/pki/nss/ssl/fips-ssl-ciphersuites.html

 Based on reading that, these cipher suites seem to be be a way to
 backport the TLS 1.0 PRF to SSL 3.0 after NIST decided that the SSL
 3.0 PRF was unacceptable, back when TLS 1.0 was still new and shiny. I
 agree it makes sense to remove it from Firefox's ClientHello and we
 already have plans for that. See
 https://briansmith.org/browser-ciphersuites-01.html.
Brian's exactly right. These ciphers were added to allow FIPS validation
of an NSS engine that could only do SSL3, not TLS 1.0. With TLS 1.0,
these ciphers are no longer needed, and quite rightly should be removed
from the ff client hello.

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: Removind dead code from NSS

[Robert Relyea]

On 10/04/2013 06:52 PM, Ludovic Hirlimann wrote:
 Hi,

 AFAIK NSS still contains code for SSL2 , but no product uses it. SSL2
 has been turned off at least 2 years ago. By removing SSL2 code we get :

   Smaller librarie
   faster compile time + test time

 What do you guys think ?

 Ludo
That's something we would like to do, but we do have downstreams that
can't remove it yet.
We could make it a compile option so it can be compiled out (which will
get most of the benefits most of the time).

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: Removind dead code from NSS

[Robert Relyea]

On 10/07/2013 11:19 AM, Ryan Sleevi wrote:
 On Mon, October 7, 2013 11:07 am, Robert Relyea wrote:
  On 10/04/2013 06:52 PM, Ludovic Hirlimann wrote:
 Hi,

 AFAIK NSS still contains code for SSL2 , but no product uses it. SSL2
 has been turned off at least 2 years ago. By removing SSL2 code we get :

 Smaller librarie
 faster compile time + test time

 What do you guys think ?

 Ludo
  That's something we would like to do, but we do have downstreams that
  can't remove it yet.
  We could make it a compile option so it can be compiled out (which will
  get most of the benefits most of the time).

  bob

  --
  dev-tech-crypto mailing list
  dev-tech-crypto@lists.mozilla.org
  https://lists.mozilla.org/listinfo/dev-tech-crypto
 Adding compile-time flags (and the accompanying #define soup) can almost
 end up worse - it prevents graceful cleanup/refactoring work that would
 also come with dead code removal.
refactoring isn't one of the features we could support until the code is
removed (at least easily)... nor was it one of the things Ludo was
looking for (at least in the mail). Though the SSL 2 code is not as
intertwined as some of the other features. I think it's basically the
gather and caching code that is really the only code that is affected by
ssl2. There doesn't seem to be any code in ssl3con.c and sslcon.c is
strictly SSL2 (well there's some code that calls ssl3 if you are using
the compatible hello, but you don't need that code if you are strictly
ssl3/tls).

 Bob, could you provide more information about these downstreams using it?
 1) Are they staying up to date with NSS? eg: If they're stuck on NSS
 3.12.x, what should it matter about removing it in 3.16?

It's Red Hat. We are staying up to date with NSS. Unfortunately I also
have to support features in that version of the OS. So when we change
defaults upstream, the don't necessarily get changed in NSS itself.

 2) If so, is the reason for doing so security patches/updates?

Mozilla requires NSS rebases as new version of Mozilla are released.

 3) If so, why would they have SSL 2.0 enabled and yet still be following
 security updates? They're at odds with eachother.

This is the way enterprise support works. Enterprise customers work on
decade long support cycles.  We've had these discussions before, which
is why we have started working on making sure that we aren't locked in
for another 10 years at Red Hat.

Our customers are really sensitive to these kinds of changes 'mid
release'. It's the fact the NSS upstream has supported these that even
allows us to do things like update the browser.


 I'd like to see us be able to come up with clear exit criteria for
 removing this feature. I can appreciate It's being used, but can you
 provide more details about why and how, so that we can have a more
 productive discussion about what it would mean and take to remove this
 code?

We understand that we want to remove several pieces of code from NSS.
That is why we have disabled the ability to even enable SSL2 in RHEL-7.

Actually the bar is quite a bit lower than in the past. In the past we
could never really rip any code out.

bob

 Cheers,
 Ryan





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: Removing SSL 2.0 from NSS (was Re: Removing dead code from NSS)

[Robert Relyea]

On 10/07/2013 12:01 PM, Kurt Roeckx wrote:
 On Mon, Oct 07, 2013 at 11:17:46AM -0700, Brian Smith wrote:
 On Fri, Oct 4, 2013 at 6:52 PM, Ludovic Hirlimann
 ludovic+n...@mozilla.com wrote:
 Hi,

 AFAIK NSS still contains code for SSL2 , but no product uses it. SSL2
 has been turned off at least 2 years ago. By removing SSL2 code we get :

 Smaller librarie
 faster compile time + test time

 What do you guys think ?
 Hi Ludovic,

 I do think it is time to remove SSL 2.0 support from libssl.
 I'm all for removing SSL 2.0 support.

 OpenSSL still supports SSL 2.0, but the default cipher list
 doesn't include any ciphers that can be used with SSL 2.0 and
 so thus disabling the use of SSL 2.0 by default.  I assume the
 same goes for NSS.

SSL2 has been turned off by default for a while. You can't support SSL
3/TLS extensions with it on.

 In Debian I decided to build openssl since 1.0.0 without SSL 2.0
 support, I didn't receive any negative feedback from that.  At
 that point it didn't support TLS 1.1 or 1.2 yet since that only
 got added in 1.0.1.  But the 1.0.0 version wasn't part of any
 release.


 Kurt





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: Removing SSL 2.0 from NSS (was Re: Removing dead code from NSS)

[Robert Relyea]

On 10/07/2013 12:44 PM, Wan-Teh Chang wrote:
 On Mon, Oct 7, 2013 at 11:17 AM, Brian Smith br...@briansmith.org wrote:
 I think it is likely that some vendors of NSS-based products with very
 conservative backward-compatibility guarantees, like Oracle and maybe
 Red Hat, may need to continue supporting SSL 2.0 in their products due
 to promises that they've made. If so, either we should create a branch
 for these organizations to maintain, or we should create a branch of
 libssl without SSL 2.0.
 The burden of maintaining the branch should fall on the people who
 still need SSL 2.0, so we should remove SSL 2.0 from the trunk. It is
 not that hard for a competent NSS developer to support an NSS 3.15
 branch for another three years.
Please don't completely screw us over here. I would prefer to be able to
track NSS updates, particularly since they are pulled in by mozilla. (we
completely rebase nss whenever we have to pick up new mozilla releases
that need it).

That being said, I think we could split the ssl 2.0 code out stand
along. The only issue is ssl2 hello-ssl3, which would probably mean
figuring out some why to make that transition that puts the burden on
the ssl2 code.

 Note: we will keep the ability on the server side to handle a
 ClientHello in the SSL 2.0 format.

 Removing SSL 2.0 is an important step to clean up the SSL library
 because it blocks some other cleanups, such as the handling of
 handshakes and receive (gather) buffers.

Ideally so ideally we could completely fork the SSL2 code to use it's
own gather buffers.

Right now I'm trying to see if I can get management to let us drop SSL2
support in some upcoming RHEL 6 release. I've already dropped it in
RHEL7, and I think we may be at the point in RHEL-5 where we may not be
updating NSS except for some extreme fixes. One thing that could help is
to make sure the next mozilla CSB release supports SSL2 that will give
RHEL 6 some more runway...

Bob


 Wan-Teh




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: Removal of generateCRMFRequest

[Robert Relyea]

On 09/28/2013 12:17 PM, Brian Smith wrote:
 On Sat, Sep 28, 2013 at 7:52 AM, Sean Leonard dev+mozi...@seantek.com wrote:
 On 9/27/2013 5:51 PM, Robert Relyea wrote:
 I don't have a problem with going for an industry standard way of doing
 all of these things, but it's certainly pretty presumptuous to remove these
 features without supplying the industry standard replacements and time for
 them to filter through the internet. bob
 Why isn't keygen good enough?

 AFAICT, based on this discussion and others, smart card events are not
 a must-have feature for any website. They are a nice-to-have, at best.
 At worst, they are the wrong model altogether. Either way,
 clearcutting them to make our sandboxing project easier and faster to
 complete still seems to make sense for me. I understand that that
 isn't the most friendly strategy towards the websites that are using
 that feature, but it is extremely unfriendly (at best) of us toward
 hundreds of millions of people to be giving them a browser without a
 sandbox. Sandboxing is a must-have-ASAP feature.

 In addition, it would be a great shame to remove this set of APIs from
 Firefox because the Mozilla platform itself uses them for chrome-privileged
 purposes. If you search smartcard-insert, for example:
 http://mxr.mozilla.org/mozilla-central/search?string=smartcard-insert
 Our
 Firefox extension makes use of these events (in addition to the other APIs)
 so that would directly impact us as well.
 Good point. We can still keep them around in chrome-privileged
 contexts because chrome-context stuff lives in the parent process and
 so would not be affected by sandboxing. So, if we preserved the
 chrome-context stuff, would your extensions still work?

 It is one thing to remove the blink tag, which most users have found
 annoying or harmful (epilepsy). Removing crypto functionality in contrast
 impacts critical security functionality for many users.
 Again, smartcard events don't seem like critical functionality
They are to several customers, who have been limping along despite their
lack of support.
  and
 keygen exists.
So CRMF exists to handle missing function in keygen (namely key
archival). If you have a way of doing that in the current keygen, then
it's probably not a problem to remove CRMF.
  signText is the only API I can see where there is no
 replacement and that would be difficult to go without. But, it is also
 problematic because of its UI; I don't think its UI is sufficiently
 clear and bulletproof that it is really effective at conveying exactly
 what is being signed--especially when you consider
 internationalization and localization issues.
signText is probably the least used of the three you are talking about
removing.

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: Removal of generateCRMFRequest

[Robert Relyea]

On 09/27/2013 05:01 PM, Ryan Sleevi wrote:
 On Fri, September 27, 2013 4:09 pm, Eddy Nigg wrote:
  On 09/28/2013 01:59 AM, From Ryan Sleevi:
 If your site requires a client certificate, and you know that a client
 certificate is stored in a smart card, then you also know that when
 using
 Firefox, and the smart card is removed, Firefox will invalidate that
 SSL/TLS session.
  Not really - except in case you require the cert authentication on every
  exchange between the client and server. I don't believe that many do
  this as it makes it incredible slow and some browser will prompt for the
  certificate over an over again.
 But Firefox (and Chrome, IE, Safari, and Opera) won't.

 I'm not sure FIrefox supporting some non-Web Platform feature on the basis
 that some other browser makes it hard, especially when the number of
 browsers that support the feature beyond Firefox is 0.
Ryan is correct. What FF does not do is reload the page when the smart
card is removed. The most common use of smart card events is forcing the
reloading the page.

NOTE: there is still an issue that Firefox doesn't provide a way for the
web page to flush it's own cache. If you've made a connection without a
cert, there's no way to say try again with the cert. This doesn't affect
removal, but it does affect insertion.

 When the user removes their smart card, the SSL/TLS session is
 invalidated, and the
 user is 'logged out'.
  Kind of, he'll get the infamous ssl_error_handshake_failure_alert error
  that nobody knows what it is, but that's not how such web apps are
  usually implemented. They do the client authentication dance once and
  continue with a application controlled session.

Actually FF does a full handshake, what kind of error you get depends on
what bits the server said. If you pass request not require, then the
handshake completes with the server getting no cert for the connection.
 And such webapps could presumably use iframes or XHRs with a background
 refresh to a login domain, and when such a fetch fail, know the smart card
 was removed, and thus treat it as the same. All without non-standard
 features being exposed.
You still don't get the page refresh when the smart card is removed.

I don't have a problem with going for an industry standard way of doing
all of these things, but it's certainly pretty presumptuous to remove
these features without supplying the industry standard replacements and
time for them to filter through the internet.

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: Need to use the main NSS module as a PKCS#11 module in IBM Notes

[Robert Relyea]

On 09/11/2013 05:52 PM, Kyle Hamilton wrote:
 Elio,

 Thanks for responding.

 IBM Notes reports that the path is invalid.  Is there a requirement that
 softokn3.chk be in the current working directory?

 -Kyle H
 softokn3.chk should be in the same directory as softoken. Softoken
asked the OS where it was loaded from and then looks for the .chk file
in the same directory.

NOTE: it's only needed when in FIPS mode.
NOTE2: While it's possible to use softoken directly in your library,
it's recommended that you actually use the NSS interfaces. NSS does not
export a PKCS #11 interface, it uses it to get access to crypto.
Softoken was written to support the NSS need for crypto and keys, and as
such does not always have a compliant PKCS #11 interface. Direct access
to to softoken from applications is a best effort sort of thing. Some
apps (like Java) have special code that knows about softoken and works
around it's vagaries. Fixes to softoken issues that don't effective NSS
use of softoken is prioritized relatively low.

bob


 On Tue, Sep 10, 2013 at 9:24 PM, Elio Maldonado Batiz 
 elio.maldonado.ba...@gmail.com wrote:

 Hi Kyle,

 nss3.dll is a not PKCS #11 module as it has no crypto, softokn3.ddl (.so)
 and freebl3.sll (.so) do. softoken is nss's own internal PKCS #11
 cryptographic module which nss loads just like any other pkcs #11 module,
 software or hardware based.

 Good starter documents are
 https://developer.mozilla.org/en-US/docs/NSS_reference and
 https://developer.mozilla.org/en-US/docs/NSS#Background_Information
 and https://developer.mozilla.org/en-US/docs/NSS/NSS_API_GUIDELINES has a
 layering diagram

 -Elio


 On Sat, Aug 24, 2013 at 6:02 PM, Kyle Hamilton aerow...@gmail.com wrote:

 Hi,

 I'm finding myself in a situation where I need to use the certificates
 and
 keys stored in my standard NSS profile in other applications.

 My initial, naïve idea was that NSS itself is a PKCS#11 module.
 Unfortunately, this appears to be not the case.  When trying to find the
 right DLL to load into IBM Notes I found that nssckbi.dll is recognized
 as
 a valid PKCS#11 module, but nss3.dll is not.  (Neither are nssdbm3 or
 nssutil.)

 Is there any plan to export the NSS softoken functionality as an actual
 full PKCS#11 token?  Or is it intended never to actually operate as such?

 -Kyle H
 --
 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





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: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Robert Relyea]

On 08/26/2013 02:24 PM, Brian Smith wrote:
 On Thu, Aug 22, 2013 at 11:21 AM, Robert Relyea rrel...@redhat.com wrote:

 So looking at this list, I think we have a major inconsistency.

 We put Ephemeral over non-ephemeral, but we put 128 over 256.

 While I'm OK with Ephemeral (PFS) over non-ephermal (non-pfs), I think
 in doing so we are taking a much more significant performance hit we get
 back by putting 128 over 256.

 It is not exactly true that PFS always has more of a negative performance
 impact than AES-128 vs AES-256. In Chromium, PFS ciphersuites will be
 faster than non-PFS cipher suites because Chromium requires PFS
 ciphersuites to be used for False Start. Also, I have an idea for how we
 can make PFS cipher suites + False Start work much more commonly on the
 web, that won't work for RSA key exchange. So, ultimately, I expect PFS
 cipher suites to be a performance win over non-PFS cipher suites.

So at this point I want to point out that:

1) I don't disagree with PFS before the other ciphers, I just wanted to
point out that they are not clearly as big a win for security as is
normally touted.
2)  It does have a significant downside speed wise. I was responsible
for measuring this once from the server perspective (we were trying to
convince people to use ECC. I could only get wins over RSA at the 2048
bit range with ECDH (224bit) not ECDHE... and that was ECDHE where we
used a single private key generated at server startup). Note that we are
using 256 bit ECC at the low end.

Those figures are old, so it would be good to try to get new ones from
the client perspective (not how many connections a server can use). I'm
not as worried about the order for servers as servers can manage their
performance by only supporting the fast algorithms.


 But, raw performance isn't the only issue. We expect that PFS cipher suites
 *can* have significantly better security properties (see below) if the
 server puts in the effort to make the encryption keys actually ephemeral,
 and we expect that they are generally no worse they are no worse regarding
 security (barring disastrous implementation errors).

 Conversely, it isn't clear that AES-256 offers any significant security
 advantage over AES-128, though it is clearly slower, even on my
 AES-NI-equipped Core i7 processor. First, AES-128 has held up pretty well
 so that it might just be good enough in general.
So as I pointed out, we should list performance measurements as to the
difference in cost. If you can see the difference, simply include those
numbers.
  Secondly, as I already
 pointed out in my proposal, some research has shown that AES-256 doesn't
 seem to offer much more security than what we understand AES-128 to offer.
My bad, I missed that point. Sorry.
 See http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html and
 https://cryptolux.org/FAQ_on_the_attacks. Thirdly, when non-constant-time
 implementations are used, AES-256 seems to offer more opportunity for
 timing attacks than AES-128 does, due to more rounds and larger inputs.
This is argument does have teeth, probably more than the performance
(depending on the actual performance).

When using performance as a criteria at all, it should be quantified.
For clients 3x slower doesn't mean anything if it's 3x 100 microseconds,
but if its 3x 1s it makes a big difference. We should measure both on
big platforms and small ones.

So in summary. 128 is actually considered as secure as 256 (based on
recent attacks) or better (based on timing attacks), so performance
isn't the primary criteria.

If we were to shop this list around to other browsers, it would probably
be good to get the performance numbers. Particularly ECDHE 256 versus
RSA 2048 on an arm (If that doesn't show a significant cost, we can
safely say performance of the key exchange is negligible).

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: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Robert Relyea]

On 08/23/2013 02:03 AM, Gervase Markham wrote:
 On 22/08/13 19:21, Robert Relyea wrote:
 The attack profile protection of PFS versus non-PFS is basically two points:
 1) some government agency could force a server to give up it's private
 keys and decrypt all the traffic sent to that server. But we already
 know that government agencies with such power simply ask for the the
 data on the server.
 2) some well funded attacker could spend the resources to attack the
 server's private key and get all the traffic sent to it. However, we
 don't actually check to see that the server is giving us a unique key in
 the ephemeral case. A way to cut some of the server cost of DHE/ECDHE is
 to generate a single them key as use it for all connections. We have
 know way of knowing the server is doing this, which brings back this
 particular attack.
 3) Someone who has captured some or all of the traffic could use a 0-day
 to get into the server and pinch the private key.

 This sort of thing is much more likely if the victim is a person of
 noteworthiness and the attacker is a government (perhaps that person's
 government), but is not the government of the jurisdiction where the
 server is based.
This has the same characteristics as 1. Once in the server, it's more
likely the attacker will fetch the data at rest than try to decrypt
recorded SSL connection.  Once the private key is pinched, future
connections are vulnerable even if they are PFS.

 As for 2), there are lots of ways a server can sabotage a
 seemingly-encrypted connection if it chooses. Why is this one special?

Most ways the server could sabotage the connection are detectable to the
client. I'm also pointing out that PFS is not a panacea. It's often
touted as such, but it's relatively easy to defeat.

To be clear, I'm not against PFS, and I don't disagree that it should be
placed forward, what I am pointing out is that any argument based on
performance to put 128 over 256 is completely ignoring the fact that PFS
is at least 3 times as expensive as the equivalent non-PFS algorithms
for only marginal theoretic security enhancement.

I think we need to be consistent in our choices here (of course as a
security guy, I'm quite happy with security over performance as 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: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Robert Relyea]

On 08/19/2013 11:06 AM, Kurt Roeckx wrote:
 On 08/09/2013 04:30 AM, Brian Smith wrote:
 Please see https://briansmith.org/browser-ciphersuites-01.html

 First, this is a proposal to change the set of sequence of ciphersuites
 that Firefox offers.

 So I think there are a whole bunch of things where we have 2 options,
 and it's not always clear which is more important.  We have:
 - PFS or not
 - ECC or not
 - RSA or DSA
 - GCM or CBC
 - keysize (128 vs 256)
 - cipher itself
 - The used MAC

 As far as I understand things, most of those don't have a big impact
 on security, but do on the speed.
It's not that simple. Which individual algorithm is faster is often
platform and key size dependent. The traditional ordering has been
security first, then performance among equivalent. Things like Camellia
and SEED were placed high assuming that server support for them would be
rare, so the would be negotiated on those servers that needed them.

 I think it makes sense to have PFS when the other side supports it, so
 that part of the order looks good to me.  We clearly want (EC)DHE when
 possible.  DH should probably be avoided.

So, to be clear about ECDHE and DHE, the server *CAN* provide perfect
forward secrecy, but it doesn't have to. The ephemeral key could
simple be another permanent key (or one of several thousands). It's
important to note that a properly implemented DHE/ECDHE is 3 times
slower than DH or ECDH (The latter does a signature, key gen, and key
derive (each doing one group operation), the former simply does a
derive). This cost is born by the server.

 I understand that ECC might be more secure and is faster, so you want
 to prefer ECC.  But currently there aren't many servers that have ECDHE
 yet, so we should be careful what the order is in case it's not
 available and try to use DHE in that case.  The current list didn't do
 that but this one does.

This is ECC marketing. When we did the measurements (10 years ago), RSA
was significantly faster on modern 64-bit machines than ECC at the 1024
bit level, and a push at the 2048 bit level (this is measuring SSL
connection performance). That is assuming ECDH. ECDHE is 3 times slower
than ECDHE. RSA gets a one for one performance boost every time you
increase the speed of the modular multiply. where as ECC only gets 20%
or so of that.

The ECC win is that ECC is more secure at lower key sizes, and it's
security profile is linear. RSA's security profile is exponential:
Example of typical equivalences:

Symmetric 80  ECC 160   RSA 1024
Symmetric 128ECC 256   RSA 2048
Symmetric 192ECC 384   RSA 4096
Symmetric 256ECC 512* RSA 8K  (The actual prime
ECC curve is 521 simply because 2^521-1 is prime)

ECC is faster than RSA at low key sizes on restricted hardware (once ECC
is optimized, that is). On faster hardware RSA holds it's own into the
2K range.

to double your security, RSA needs to go up about 4x. Also doubling your
key size increase the cost to do the RSA operation by 4x. ECC is linear
in both cases. So if RSA is 16x faster than RSA at one strength level,
doubling it would make them equivalent.

The upshot is that ECC will always eventually win the performance race
at the top end, but for any given hardware and key strength, RSA may
actually be faster.


 I'm not sure which of RSA and DSA is better, but clearly people use
 RSA more.
DSA is signature only, so it's DHE/DSA versus DHE/RSA versus RSA. Both
algorithms are have different speed characteristics. In RSA signing is
more expensive verification, but still cheaper than DSA signing (unless
you precalculate several k/r/k^-1 values, which hardware may do, but
most software does not bother with). For verification RSA is
significantly faster (why, you may ask, since the math for both is
exactly the same:  S =H^priv mod N, H = S^pub mod N? It's because we can
choose the value of the public key and greatly reduce our work to
calculate X^pub mod N). DSA verification is actually slower than DSA
signing, involving 2 group operations (modular exp in the case of DSA),
and invert and 3 multiplies.

Of core RSA is much faster than any of the DHE/DSA, DHE/RSA for both the
client and the server. It's also faster than DH_ for the same key sizes
(RSA private key ops can use the Chinese remainder theorem to reduce
it's work by 4x, verses DH of the same key size).

 I understand that GCM is faster, but the implementations might have
 side channel attacks.  So I'm not sure if GCM or CBC is better, but
 we should probably prefer GCM or CBC.
Again, GCM is not necessarily faster than CBC, though GCM doesn't have
to do the hash. Certainly on a 64 bit intel machines with hardware
assist, it's likely to be. GCM isn't vunerable to BEAST attacks.

 I understand that for a 2048 bit public key a 128 bit symmetric key
 should be good enough, but for a 4096 you should have a larger key.  I
 see that about 2% is using keys of 4096 bit.

It's a question of where your weakest link is. 2048 

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Robert Relyea]

On 08/16/2013 03:05 PM, Wan-Teh Chang wrote:
 On Fri, Aug 16, 2013 at 11:13 AM, Camilo Viecco cvie...@mozilla.com wrote:
 Hello Brian

 I think this proposal has 3 sections.
 1. Unifing SSL behavior on browsers.
 2. Altering the criteria for cipher suite selection in Firefox (actually
 NSS)
 3. removing certain cipher suites from the default firefox ciphersuite.

 On 1:
 I dont see the point, but I am not against.

 On 2:
 The proposal is not clear. I want an algorithmic definition. For example in
 nss we can see in sslenum.c :
 -strong ciphers before weaker
 - national ciphers before international
 - faster ciphers before slow ciphers.

 But your proposal it not clear. Here is my reverse engineering of the
 criteria to get to your list:

 1. Message Authentication: MD5 last.
 rationale: security
 2. Key exchange (round1): PFS before non-PFS suites
rationale: privacy, goal stop supporting non-PFS suites.
 3. Bulk encoding (round1): aes(all variations) before national ciphers
 before 3des before rc4 before des before export ciphers before null.
   rationale: security, aes is the most studied cipher both in implementation
 and theory. RC4 has shown
 weakness.
reationale2 performance: 3des is slow and does not provide much security
 over the other ciphers.
 4. Authentication (round1) : DSS last
rationale: it is not really used, want to deprecate.

 5. Key Exchange (round2): ECDH before DHE.
rationale: ECDH allows negotiation form client.
 6. Bulk encoding (round 2): 128 AES before 256 AES
rationale: performance and minimal security gains.
 7. Message Authentication: authenticated encryption (GCM) before SHA before
 SHA256 before sha384
a. AEAD before HMAC : performance
b. sha ordering: performance
 8. Authentication: RSA before ECDSA
 a. RSA before ECDSA : performance
 b. DSA last: not in use

 This criteria gets to your ordering proposal. What do you think of
 re-framing your list in a criteria like this? (note national ciphers could
 go in step 6 instead of step 3).
 Camilo, I think you reverse-engineered Brian's criteria correctly.

 The new criteria seem fine. I would prefer ECDSA over RSA for authentication.
So looking at this list, I think we have a major inconsistency.

We put Ephemeral over non-ephemeral, but we put 128 over 256.

While I'm OK with Ephemeral (PFS) over non-ephermal (non-pfs), I think
in doing so we are taking a much more significant performance hit we get
back by putting 128 over 256.

The attack profile protection of PFS versus non-PFS is basically two points:
1) some government agency could force a server to give up it's private
keys and decrypt all the traffic sent to that server. But we already
know that government agencies with such power simply ask for the the
data on the server.
2) some well funded attacker could spend the resources to attack the
server's private key and get all the traffic sent to it. However, we
don't actually check to see that the server is giving us a unique key in
the ephemeral case. A way to cut some of the server cost of DHE/ECDHE is
to generate a single them key as use it for all connections. We have
know way of knowing the server is doing this, which brings back this
particular attack.

I still think PFS algorithms are useful and agree with preferring them,
but compared to 128 versus 256 it seems like the cost/security tradeoffs
are actually less for the PFS algorithms.

If we are making performance tradeoffs, we really should measure the
real cost rather than just randomly say one is too expensive.
 Not adding:
 TLS_(EC?)DHE_RSA_WITH_AES_(128|256)_CBC_SHA256
 Disagree I dont think a potential performance issue should prevent us from
 deploying that suite as there could be sha1 attacks that we dont know of. If
 we have enough space in the handshake I see no problem in including them.
 Removal seems like a premature optimization.
 The way HMAC-SHA1 uses SHA1 is much more complicated than the way
 public key signatures use SHA1. This is why SHA1 collision attacks
 usually don't affect the security of HMAC-SHA1.
Agreed SHA256 HMAC, like PFS, is really marketing. SHA1 is weak right
now for signatures because of collision, but HMAC depends on pre-image
resistance, which even MD-5 is still strong against.

At some point marketing wins, as well as the security principle attacks
only get better. As Brian points out, however, AEAD cipher suites solve
both problems.


bob

 Wan-Teh




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: Fwd: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements

[Robert Relyea]

On 08/15/2013 03:21 AM, Gervase Markham wrote:

On 15/08/13 01:19, Robert Relyea wrote:

On 08/09/2013 02:57 AM, Gervase Markham wrote:

Can an NSS hacker please tell me, in the fashion of the attempt by the
IE representative below, what types of certificate NSS accepts for
making SSL connections? What features must the cert or chain have or not
have?

Or, if this is a PSM question, tell me that :-)

Gerv

I think you already have the answer, but here's the basic:

The code to determine the type a cert is in in certdb.c called
cert_ComputeCertType().

For those following along:
http://dxr.mozilla.org/mozilla-central/source/security/nss/lib/certdb/certdb.c#l489


It's rather complex to allow historical issued
certificates to function:

If the cert has neither an extended key usage or  a netscape cert
extension, then the cert is considered legacy and OK for use for
everything except code signing (Email/SSL client/SSL Server).

Do we have any idea of the compatibility impact of changing that
behaviour so that we do not accept such certs for authenticating SSL
servers?


That's an instrumentation issue. It was true back in 1995/6 when the 
code was added I don't know how true it is today. My guess is the 
biggest compatibility issue is self-issued certs, not CA issued certs... 
but then again most of those are self-signed...


We should also check the use of the NS Cert Type extension. My guess is 
in the real world, if it exists, it's data is mirrored by basic 
constraints and extended key usage.



If the cert as either an extended key usage or a netscape cert
extension, then the cert must have the SSL_Server type set. Exception,
if it has the extended key usage and the Govt_approved, it is assumed to
also have SSL_Server. The code has some comment that COMMODO needs this
behavior until 2020.

If the cert has both an extended key usage and a netscape cert
extension, only one of these need to indicate that it's an SSL_Server cert.

Also, the cert can't be a CA cert (SSL Server+CA maps to a CA that can
issue SSL_Server certs, not an SSL_Server cert).

So the logic of that code block, as I read it, is:

SSL_Server   == !(NS_Type_Extension || EKU_Extension)// 608-621
 || NS_Type_SSL_Server// 516
 || !BC_isCA  (
   EKU_Server_Auth// 553-562
   || NS_Govt_Approved// 563-576
 )


SSL_Client   == !(NS_Type_Extension || EKU_Extension)// 608-621
 || NS_Type_SSL_Client// 516
 || EKU_SSL_Client_Auth   // 577-586


SSL_CA   == NS_SSL_CA// 516
 || BC_isCA  (
   !(NS_Type_Extension || EKU_Extension)  // 608-621
   || NS_Type_Email_CA// 531-537
   || EKU_SSL_Server_Auth // 553-562
   || NS_Govt_Approved// 563-576
   || EKU_SSL_Client_Auth // 577-586
 )


Email== NS_Type_Email// 516
 || !(NS_Type_Extension || EKU_Extension) // 608-621
 || (NS_Type_SSL_Client  Has_Email_Address) // 523-530
 || (EKU_Email_Protect  !BC_isCA)   // 538-552
The reason for line 523 is because S/MIME usage predates 
EKU_Email_Protection,  so SSL_Client certs were used.



Email_CA == NS_Type_Email_CA // 516
 || BC_isCA  (
   !(NS_Type_Extension || EKU_Extension)  // 608-621
   || EKU_Email_Protect   // 538-552
 )


Code_Sign== NS_Type_Object_Signing   // 516
 || (EKU_Code_Sign  !BC_isCA)   // 587-596


Code_Sign_CA == NS_Type_Object_Signing_CA// 516
 || (EKU_Code_Sign  BC_isCA)// 587-596


Time_Stamp   == EKU_Time_Stamp   // 597-601
Technically this is EXT_KEY_USAGE_TIME_STAMP || EKU_TIME_STAMP. NOTE 
that the Netscape Cert Type extension can set any bit in NSCertType, 
including bits that didn't exist at the time the cert was issued. (OR 
even combinations of bits you couldn't get otherwise, like both 
SSL_SERVER and SSL_SERVER_CA.



OCSP_Resp== OID_OCSP_Responder   // 602-606
 || is_Any_CA_Type 
!(NS_Type_Extension || EKU_Extension) // 608-621


Questions:

* Line 608ff: why does this part of the code use two ways of determining
whether a cert is a CA cert?
Certs that have neither a NS_Cert extention nor an EKU Extension are 
most likely a primitive certificate (primitive in it's use of the 
standards). CA certs are particularly likely

Re: Fwd: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements

[Robert Relyea]

Time_Stamp   == EKU_Time_Stamp   // 597-601


Technically this is EXT_KEY_USAGE_TIME_STAMP || EKU_TIME_STAMP.

What is the difference between these two? Looking at the wording, they
seem identical - EKU stands for EXT_KEY_USAGE...


One is the bit set in the Netscape Certificate extension and the other 
is the oid in the EKU extension.


The point is that the Netscape Cert type extension can set any bit in 
our certType.



It seems the conditions under which a cert
is given EXT_KEY_USAGE_STATUS_RESPONDER are wider than those for the
other types...

I'm not sure what you mean by this.

I mean that (for certs with no NS extension and no EKU) the cert is
given type EXT_KEY_USAGE_STATUS_RESPONDER if CERT_IsCACert() returns
true. This is a more expansive check than merely seeing if
basicConstraint.isCA is true - which is what is checked for the other
cert types. I am talking about lines 610-618.
Right if you don't have a NS cert type or EKU extension, then you likely 
have a primitive cert, which requires a whole lot more futzing to tell 
if it's a CA cert or not (basically the extra futzing is did someone 
tell us this is a CA cert in the certdb, which  in general happens with 
root certs primarily).

two. It's been several decades since we have the general constraints and
the NS Cert extension is basically redundant in face of that, so I think
it would be good to look at deprecating the support for parsing NS Cert
extensions altogether. (It may even be safer to do this than to drop
support for certs with neither extension).

Feel free to file a bug :-)
It depends on how critical it is to parsing BR certs. Is it important to 
know a CA is only treated as a CA if it has basic constraints (barring 
the database override). I was offering that it might be possible to 
remove it, but I don't have a pressing need to remove it.;).


Gerv






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: moznss with openldap - error -8018:Unknown PKCS #11 error

[Robert Relyea]

On 08/07/2013 10:38 PM, Augustin Wolf wrote:

Hi List,
I have a Centos 6.4, fresh install, and I'm trying to configure
OpenLDAP with moznss. For now, self signed certificate is sufficient
for my needs. But when I try to search using secure connection (-Z
option), I got error:

ldap_start_tls: Connect error (-11)
 additional info: TLS error -5938:Encountered end of file
In openLdap logs:
connection_read(14): checking for input on id=1000
TLS: certdb config: configDir='/etc/openldap/certs/'
tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly
TLS: cannot open certdb '/etc/openldap/certs/', error -8018:Unknown
PKCS #11 error.
TLS: skipping 'cert8.db' - filename does not have expected format
(certificate hash with numeric suffix)
TLS: skipping 'key3.db' - filename does not have expected format
(certificate hash with numeric suffix)
TLS: skipping 'secmod.db' - filename does not have expected format
(certificate hash with numeric suffix)
TLS: error: the certificate 'LDAPServer' could not be found in the
database - error -8187:security library: invalid arguments..
TLS: could not read certificate file LDAPServer - error -5950:File not found.
TLS: error: could not initialize moznss security context - error
-5950:File not found
TLS: can't create ssl handle.
connection_read(14): TLS accept failure error=-1 id=1000, closing
connection_close: conn=1000 sd=14

I cannot resign from using moznss, as it is in default with openldap
package in CentOS 6.4. I created TLS certificates like this:

[root@ldap ~]# openssl req -new -x509 -extensions v3_ca -keyout
/etc/pki/CA/private/CAss.key -out /etc/pki/CA/certs/CAss.pem -days 200
#got rid of certificate password:
[root@ldap ~]# openssl rsa -in /etc/pki/CA/private/CAss.key -out
/etc/pki/CA/private/CAssNOpass.key
#created pkcs12 key+cert
[root@ldap ~]# openssl pkcs12 -export -inkey
/etc/pki/CA/private/CAssNOpass.key -in /etc/pki/CA/certs/CAss.pem -out
/etc/pki/ldap.example.com.p12 -nodes -name 'LDAPServer'
#import p12 certificate to openldap keybase:
[root@ldap ~]# pk12util -i /etc/pki/ldap.example.com.p12 -d /etc/openldap/certs
#import CA, as CA to certificate keybase:
[root@ldap ~]# certutil -A -d /etc/openldap/certs -n LDAPServer -t
CT,, -i /etc/pki/CA/certs/CAss.pem
# verify:
[root@ldap ~]# certutil -d /etc/openldap/certs -L
Certificate Nickname Trust Attributes
  SSL,S/MIME,JAR/XPI
LDAPServer   CTu,u,u
# keybase has ldap permission, and ldap is able to read from it:
[root@ldap ~]# chown root:ldap /etc/openldap/certs/*
[root@ldap ~]# chmod 0640 /etc/openldap/certs/*
#openldap uses this keystore:
[root@ldap ~]# cat /etc/openldap/slapd.conf |grep -i tls
TLSCipherSuite HIGH:MEDIUM:+SSLv3
TLSCACertificatePath /etc/openldap/certs
TLSCertificateFile LDAPServer
TLSVerifyClient allow

What I did wrong?


In general, self-signed certificates are a bad idea, but the real 
problem is probably related to your databases.


The error message says you are trying to open the databases, but 
failing. It looks like your permissions are right, but I'm a little 
confused by your reverence to moz-nss. Do you mean nss in general? is 
certutil and openldap using the same version of nss?


bob

Best regards,
Augustin





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: Fwd: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements

[Robert Relyea]

On 08/09/2013 02:57 AM, Gervase Markham wrote:

Can an NSS hacker please tell me, in the fashion of the attempt by the
IE representative below, what types of certificate NSS accepts for
making SSL connections? What features must the cert or chain have or not
have?

Or, if this is a PSM question, tell me that :-)

Gerv


I think you already have the answer, but here's the basic:

The code to determine the type a cert is in in certdb.c called 
cert_ComputeCertType(). It's rather complex to allow historical issued 
certificates to function:


If the cert has neither an extended key usage or  a netscape cert 
extension, then the cert is considered legacy and OK for use for 
everything except code signing (Email/SSL client/SSL Server).


If the cert as either an extended key usage or a netscape cert 
extension, then the cert must have the SSL_Server type set. Exception, 
if it has the extended key usage and the Govt_approved, it is assumed to 
also have SSL_Server. The code has some comment that COMMODO needs this 
behavior until 2020.


If the cert has both an extended key usage and a netscape cert 
extension, only one of these need to indicate that it's an SSL_Server cert.


Also, the cert can't be a CA cert (SSL Server+CA maps to a CA that can 
issue SSL_Server certs, not an SSL_Server cert).



We do not parse 'AnyEKU' (though it's reasonable for us to do so).

bob


 Original Message 
Subject: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline
requirements
Date: Thu, 8 Aug 2013 17:10:36 +
From: Kelvin Yiu kelv...@exchange.microsoft.com
To: jeremy.row...@digicert.com jeremy.row...@digicert.com, 'Gervase
Markham' g...@mozilla.org
CC: 'CABFPub' pub...@cabforum.org

One way to make progress is perhaps for browsers to summarize the
certificate profile (e.g. required fields and extensions) that their
browsers accept as SSL, code signing, or any other public certificates
they accept. For example, I believe IE expects SSL certificates require
at least the following: (I will need to do some research to confirm)

1. Either no EKU extension, anyEKU, or the server auth EKU in all
certificates in the chain. IE may still accept the old SGC olds as well
2. Valid DNS name in either the CN field in the subject name, or one or
more dNSNames or IPv4 address in the SubjectAltName extension
3. Root CA must be enabled for server auth

For code signing certificates:

1. Either no EKU extension, anyEKU, or the code signing auth EKU in all
certificates in the chain.
2. Root CA must be enabled for code signing
3. Subject name must have either CN, or O, (and maybe OU) field.

Hence, OV SSL certificates that do not have an EKU extension (or include
the anyEKU OID) are valid for both SSL and code signing. Arguably it is
probably not the intention of the CA to issue SSL certificates that can
be also used for code signing.

At a high level from the MS perspective, I want all CAs that issue
certificates that would be interpreted as SSL, code signing, or whatever
other usages allowed by the root program) to be in scope of the
discussion. The high level principle here is to prevent or at least
minimize unintended certificate usages that opens up security
vulnerabilities.

So if while PIV certificates may include the anyEKU but do not contain
any valid DNS name, browsers may reject it for SSL so they can be
considered out of scope.

I agree the much harder problem to resolve is whether to include CAs
with no EKUs that are capable of issuing SSL certificates, but I don't
have a good answer yet.

Kelvin



-Original Message-
From: public-boun...@cabforum.org [mailto:public-boun...@cabforum.org]
On Behalf Of Jeremy Rowley
Sent: Thursday, August 8, 2013 9:04 AM
To: 'Gervase Markham'
Cc: 'CABFPub'
Subject: Re: [cabfpub] Ballot 108: Clarifying the scope of the baseline
requirements

Yes - I am officially withdrawing the ballot pending further consideration.

I'm not sure how to overcome these obstacles since:
1) PIV-I in the US space requires the anyEKU
2) Qualified Certs may require no EKU
3) Certificates without an EKU or the anyEKU may be used as SSL certificates
4) All SSL certificates should be covered by the BRs
5) Qualified and PIV-I Certs cannot be covered by the BRs since they
lack a FQDN
6) SSL Certificates without an FQDN are considered local host and
explicitly covered by the BRs

I think the best option might be to simply acknowledge the inconsistency
and change the definition as follows:

All root certificates included in a browser's trust store, all
subordinate CA certificates signed by one of these root certificates,
and all end-entity certificates that either lack any Extended Key Usage
extension or contain an Extended Key Usage extension that contain (i)
either an Internal Server Name or a FQDN and (ii) one of the following:
- Server Authentication (1.3.6.1.5.5.7.3.1)
- anyExtendedKeyUsage (2.5.29.37.0)
- Netscape Server Gated Cryptography (2.16.840.1.113730.4.1)
- Microsoft Server Gated 

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Robert Relyea]

On 08/09/2013 10:12 AM, Brian Smith wrote:

On Fri, Aug 9, 2013 at 3:27 AM, Gervase Markham g...@mozilla.org wrote:


* Can you provide some background or references on exactly how
ciphersuite construction and choice works? Can I invent e.g.
TLS_DHE_ECDSA_WITH_AES_128_MD5 or some other random combination of
elements? Can any combination be encoded in the ClientHello? Does the
server support specific sets, or will it support my combination if it
supports all the component pieces?


No, each combination is hard-coded into its own distinct code point that is
registered with IANA:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4.
This is a design choice based on the fact that many crypto modules don't
let you mix/match algorithms at will, and because you often can't/shouldn't
move keys between crypto modules.


Minor tweak. The design point has nothing to do with crypto modules. It 
had to do with analyzing combinations of algorithms. In 1994/5 when 
SSL-3 was being designed there were 2 camps: 1) select 
Asymmetric/Symmetric/Macing algorithms separately and 2) cipher suites. 
The security argument fell to cipher suites under the theory that it 
simplified your analysis of whether the algorithm is secure or not. At 
the time no one was thinking of doing operations in tokens, even at this 
point in time, I know of no crypto modules that actually implement 
cipher suites as a suite.



That info is really only of historical interest and doesn't affect the 
rest of Brian's argument (particularly since he's correct in the only 
part of the paragraph Gerv cares about --- that SSL uses suites, not 
arbitrarily mixed combinations of algorithms).




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