[combining two cites to save space]
On 21.06.11 00:48, Anders Rundgren wrote:
We have both come to the conclusion that Firefox et al sucks since just about
all serious users need to deploy plugins in order to use their PKIs.
On 18.06.11 19:59, Anders Rundgren wrote:
[Subject: Update: Brows
On 01.06.11 10:21, Andrey Melashenko wrote:
How can we implement custom (national) asymmetric algorithm for firefox?
Do you mean GOST for TLS 1.2 (rfc draft-chudov-cryptopro-cptls) ?
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-
On 14 May 2011, M.R. wrote:
On 13/05/11 12:17, Konstantin Andreev wrote:
I see a lot of aspects in the NSS code, which would greatly benefit
(readability, maintainability, etc) from a trivial refactoring.
Here are a few trivial examples (NSS):
-- 123 occurrences of code like
| sizeof
I see a lot of aspects in the NSS code, which would greatly benefit
(readability, maintainability, etc) from a trivial refactoring.
Here are a few trivial examples (NSS):
-- 123 occurrences of code like
| sizeof(longUnreadableName)/sizeof(*longUnreadableName)
Much more readable:
Hello, Helge.
Any default should be cautiously placed at the appropriate abstraction level.
In this particular case, the defaults are the responsibility of the layer,
which knows it is working with JavaCard 2.2.2/3.0.1. Looks like NSS is not that
one.
Let assume NSS applies the defaults below
Peder, what you encountered is a [bug 327773]
http://bugzilla.mozilla.org/show_bug.cgi?id=327773
NSS pk11wrap layer has two functions to create private keys in a token:
PK11_ImportEncryptedPrivateKeyInfo and PK11_ImportAndReturnPrivateKey.
But only 1st of them supports EC keys. You may try res
4.11 22:36, Robert Relyea wrote:
On 04/12/2011 04:26 AM, Konstantin Andreev wrote:
AFAIK, NSS HEAD is a future 3.13 branch, but most of development is currently
focused on NSS_3_12_BRANCH.
Could anybody advice, how particular issues/bugs of these two branches are
merged ?
They are unlikely to
AFAIK, NSS HEAD is a future 3.13 branch, but most of development is currently
focused on NSS_3_12_BRANCH.
Could anybody advice, how particular issues/bugs of these two branches are
merged ?
That is, - if particular patch occurs in the 3.12, when will it migrate into
3.13 ? Conversely, may par
On 11.04.11 19:30, Helge Bragstad wrote:
Could anybody provide, or point to some info regarding the support for ECDSA in
TLS client authentication in Firefox as well as for S/MIME in Thunderbird?
(Curves and hash functions being used etc.)
Vanilla NSS builds with ECC support turned on (NSS_E
Thanks, guess I have to implement a similar function in my code then? Bit of a
shame it is not being exported for public consumption. I imagine its usage
would be quite common, no?
Konstantin Andreev wrote:
This is an ancient [bug 294538], six years (sic!) old.
CERT_AddExtensionByOID, as many
This is an ancient [bug 294538], six years (sic!) old.
CERT_AddExtensionByOID, as many other functions, is declared in the public
header (here: cert.h), but is not exported by the library.
Keep well,
Konstantin
james07 wrote:
I wish to call CERT_AddExtensionByOID() in my application. However
On 29.03.11 18:10, Marion Vogt wrote:
I tried to launch Iceweasel in the debug mode and printed backtrace of all
stack frames :
#2 0xb7d85b82 in abort () from /lib/i686/cmov/libc.so.6
#3 0xb24a2e7a in SECITEM_CopyItem_stub (arena=0x0, to=0xabd2a5c8,
from=0xabd42028) at stubs.c:474
Normal
On 23.03.11 23:32, Crypto User wrote:
On Mar 23, 12:05 pm, Honza Bambas wrote:
On 3/22/2011 10:29 PM, Crypto User wrote:> Hi ,
I am trying to create APIS which will provide Hashing functionality to end
user. I am using NSS to provide this on Linux.
I was trying to find the correct APIs in NS
On 22.03.11 12:23, Sergei Evdokimov wrote:
I think, being able to support encryption or having an option that enables or
disables verification of email addresses in certificates would make sense.
Here is a hint for you.
At the lowest level, NSS doesn't track [email]->[certificate] relations,
On 22.03.11 21:00, Robert Relyea wrote:
On 03/22/2011 02:23 AM, silent...@gmail.com wrote:
<...> the requirement is to allow having more than one <...> email provider
AFTER the card was issued.
<...>
Unless there is an authoritative way to bind the cert to a given email address,
there is no w
9 cert, signed by bank CA
Regards,
--
Konstantin Andreev.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
whom we have to be in touch as to NSS features coupled
with GOST' mechanisms, token switching etc and to be on course for patch
upstream of NSS?
Frankly speaking this Q is from colleagues of mine from CryptoPRO.
I know Konstantin Andreev has been working on this. If you not part of
On 08/28/10 02:36, Michael Smith wrote:
Rather than the normal case of a client certificate belonging to the user, and
just added to the certificate store, we want to have a certificate that
nominally belongs to the application, and is secret from the user (strange, but
that's what I'm stuck w
On 08/31/10 05:01, Nelson B Bolyard wrote:
On 2010/08/30 17:32 PDT, Wan-Teh Chang wrote:
I propose that we remove SSL 2.0 support from the NSS trunk (NSS 3.13).
[... skip ...]
It's something I wanted to do for YEARS, but for as long as I was employed to
work on NSS, I was told that continued
On 08/13/10 04:44, Robert Relyea wrote:
On Wed, Aug 11, 2010 at 1:18 PM, Matej Kurpel wrote:
[ ... skip ... ] Later, thunderbird asks for its attributes CKA_TOKEN and
CKA_LABEL but gives zero-sized buffers for both values. ... According to the
specification (if I understood correctly), I sho
On 08/12/10 14:26, Matej Kurpel wrote:
Dňa 12. 8. 2010 11:03, Konstantin Andreev wrote / napísal(a):
On 08/12/10 00:18, Matej Kurpel wrote:
[ ... skip ...]
Later, thunderbird asks for its attributes CKA_TOKEN and CKA_LABEL but gives
zero-sized buffers for both values. This is where my
On 08/12/10 00:18, Matej Kurpel wrote:
[ ... skip ...]
Later, thunderbird asks for its attributes CKA_TOKEN and CKA_LABEL but gives
zero-sized buffers for both values. This is where my problem lies - I don't
know what to return and if I have to fill the values in the template or not.
Accordin
On 08/03/10 19:13, Brian Smith wrote:
Martin Paljak wrote:
At the same time, isn't GCM only present in the latest 2.30 draft?
Yes. And, actually, I think I found a problem with the GCM interface that seems
to make it impossible to use the PKCS#11 interface in a FIPS-140-compliant
manner. In
Robert, thank you for detailed answer.
I decided how to implement parametrization of hash context creation in
freebl`hasht.h`SECHashObject.
I chose to add another constructor at the end of SECHashObject. This decision
keeps backward compatibility, binary and source-level.
--
Konstantin
On 07
other clients except NSS could use freebl. In this
case backward compatibility is a must.
Could you, please, advice, either is true ? Is BLAPI/freebl assumed to be used
outside of NSS ?
--
Konstantin Andreev.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org
ompliance would be if
softoken was FIPS certified together with that hardware RNG. That hardware RNG would be
considered inside of the softoken's perimeter.
Hmm... but why together ? May certification state:
Plugging in any FIPS-certified hardware RNG keeps softoken+RNG
FIPS-compliant ?
Rega
ggregate device ?
Application --(sign_req)--> Mozilla softoken --(C_GenerateRandom)-->
hardware RNG
Best regards,
--
Konstantin Andreev.
On 07/18/10 03:13, Nelson B Bolyard wrote:
On 2010-07-12 02:18 PDT, Konstantin Andreev wrote:
Hello.
I am asking in this newsgroup, because I b
n own random to ECC signature mechanism.
--
Konstantin Andreev
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
return CKR_DATA_LEN_RANGE when CBC/ECB
ciphers are updated with odd length.
I wonder, are any chances for this aspect of NSS softoken to be more PKCS#11
compliant in the near future ?
Best regards,
--
Konstantin Andreev.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://
Not a policy issue I suppose... Some days ago I have found that:
No one block cipher MAC'ing mechanism is working in either current release
or trunc NSS, in either mode.
I've already investigated the issue and about to file a bug this or next day.
--
Konstantin Andreev.
On 06/0
y compromise.
* we shouldn't confuse user. "Securing mail" should just work w/o exposing
these gory details.
You can find relevant discussions in other newsgroups, not this one.
Best regards,
--
Konstantin Andreev.
On 18.02.10 14:06, Michael Ströder wrote:
I'm using Seamonkey 2
o invest a resources into the design
and development of such kind of library.
Best regards,
--
Konstantin Andreev
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
my 5 cents.
Recently I made a proposal: let "Basic ECC" pose a restriction on "softoken"
only, but not on NSS as a whole.
Best regards,
--
Konstantin Andreev
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
on 1.2.28.2,
tag NSS_3_11_1_RTM in mozilla CVS.
Attached.
--
Konstantin Andreev.
/*
* * BEGIN LICENSE BLOCK *
* Version: MPL 1.1/GPL 2.0/LGPL 2.1
*
* The contents of this file are subject to the Mozilla Public License Version
* 1.1 (the "License"); you may not use this f
for Dogtag. I CC'ed you on the NSS RFE.
https://bugzilla.mozilla.org/show_bug.cgi?id=502139
This enhancement will be useless until Mozilla/"MailNews Core" attends these
capabilities. Given that TB security enhancements are stalled for years, I wouldn't rely
on this.
Best regard
if no one else does.
On 2009-Dec-18, at 10:51 PM, Konstantin Andreev wrote:
I have noticed, the following method is used in the ECC sign/verify routines to
derive 'e' integer from a digest:
( begin cite )
/* In the definition of EC signing, digests are truncated
* t
.
For most curves they are the identical, not not for all. This looks like a bug
for me.
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Hello, Nelson.
Thank you again for detailed description. This is a valuable piece of
information.
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
On Fri, 18 Dec 2009, Nelson B Bolyard wrote:
On 2009-12-17 13:39 PST, Konstantin Andreev wrote:
On Tue, 17 Dec 2009, Nelson B
Hello, Nelson.
Thank you for your response.
On Tue, 17 Dec 2009, Nelson B Bolyard wrote:
On 2009-12-16 03:01 PST, Konstantin Andreev wrote:
I see NSS code uses SECITEM_AllocItem() and PORT_Arena{,Z}Alloc() memory
allocation routines almost interchangeably.
Yes, almost.
I see that
outine (SECITEM_AllocItem or
PORT_Arena{,Z}Alloc) should I use for my particular code ?
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
ty/nss/lib/pk11wrap/pk11obj.c&rev=1.21&mark=536-538#510].
Are there strong reasons for this incompatibility, and should this be changed
to conformant behavior ?
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.or
capabilities lists included in messages received from the recipient, as well as
out-of-band information such as private agreements, user preferences, legal
restrictions, and so on.
It could be a great enhancement if Thunderbird could allow to user-override the
automated cipher selection.
Best re
need only crypto-primitives (like digesting, encryption,
signing/verification), you ought better use NSS PKCS#11 module (softoken),
without loading the whole NSS stack.
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
--
dev-tech-crypto mailing list
dev-tech-crypto
ithm is
also ECC-dependent, and I must decide, which parts of GOST-specific code should be
compiled conditionally, and which shouldn't.
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
d attentive until stock FF and TB will
migrate to sqlite NSS backend.
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Hello, Robert.
On Wed, 28 Oct 2009, Robert Relyea wrote:
On 10/28/2009 02:25 AM, Konstantin Andreev wrote:
It looks somewhat strange how default (so-called legacydb) database allows
upper layer (softoken) to manipulate key's attributes.
Yes, the mapping between what the database could
age format for GOST keys, incompatible with PKCS#8
PrivateKeyInfo. This is much more patching of legacydb code.
Could you advice, please ?
Unfortunately the latter <...>
Based on investigation above, I suppose, I can just use public key from
RecordKey (available at LGObjectCache.dbKey)
es of DSA, ECC, DH, etc. keys.
Could you, please, advice, how this code was designed, and how legacydb
*should* grant access to key's attributes ?
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.m
priv.key lookup from lg_GetPublicKey()
-- invent my own storage format for GOST keys, incompatible with PKCS#8
PrivateKeyInfo. This is much more patching of legacydb code.
Could you advice, please ?
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
--
dev-tech-c
On Tue, 07 Oct 2009, Robert Relyea wrote:
On 10/06/2009 01:14 AM, Konstantin Andreev wrote:
On Mon, 05 Oct 2009, Robert Relyea wrote:
On 10/05/2009 09:27 AM, Konstantin Andreev wrote:
Could you, please, advice, how should I handle CKA_NETSCAPE_DB for GOST private
keys ?
GOST private key
On Wed, 07 Oct 2009, Wan-Teh Chang wrote:
On Wed, Oct 7, 2009 at 4:09 AM, Konstantin Andreev wrote:
I've checked this. SEC_ASN1_ANY saves tag-length prefix, but ignores tag
number, thus matches anything.
If SEC_ASN1_ANY doesn't work for you, the only solution I have is to re-e
On Tue, 06 Oct 2009, Wan-Teh Chang wrote:
On Tue, Oct 6, 2009 at 3:04 AM, Konstantin Andreev wrote:
One more question about decoding DER structures.
Some PKCS#11 mechanisms (namely, CKM_GOSTR3410 ) accept DER-encoded parameters,
which include DER tag-length prefix.
I dissect these
I save DER tag-length in item safely ?
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Hello, Nelson.
On Mon, 10 Oct 2009, Nelson B Bolyard wrote:
On 2009-10-05 02:20 PDT, Konstantin Andreev wrote:
I need to decode some DER-encoded ASN1 CHOICE, but I can't manage this in a
reasonable way.
FYI, the documentation on NSS's ASN.1 encoder and its two decoders i
Hello, Robert.
On Mon, 10 Oct 2009, Robert Relyea wrote:
On 10/05/2009 09:27 AM, Konstantin Andreev wrote:
In the source code of the "softoken" library I see various conditional
manipulations with CKA_NETSCAPE_DB attribute of private keys.
Since I am adding a new (GOST) type of p
;t found enough information about the intended use of
CKA_NETSCAPE_DB in neither MDC nor bugzilla.
Could you, please, advice, how should I handle CKA_NETSCAPE_DB for GOST private
keys ?
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
--
dev-tech-crypto mailing list
ld you, please, advice, how can I decode CHOICE more reasonable than shown
above ?
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Thank you for explanation.
Best regards,
Konstantin Andreev
Wan-Teh Chang wrote:
On Thu, Oct 1, 2009 at 8:49 AM, Konstantin Andreev wrote:
I have a couple of related questions.
1) If I am adding a function into the "util" library, should I care about placing a
wrapper in the &
"softokn" is using *_Util. Turning USE_UTIL_DIRECTLY off will cause dependency of
"softokn" from "nss" lib.
I have read bug 286642 discussion, but it doesn't make things clearer.
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
--
dev-tech
g/projects/security/pki/nss/nss-guidelines.html.
Thank you, Kaspar. That is what I was looking for.
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
This acronym (BL) provokes my curiosity. After some reading of the NSS sources
I still have no idea what it means. I believe this is something inherited from
netscape.
Can anybody bate my curiosity ?
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
--
dev-tech-crypto mailing
Hello.
On Mon, Sep 28, Wan-Teh Chang wrote:
On Mon, Sep 28, 2009 at 3:26 AM, Konstantin Andreev wrote:
I need to share some potion of code between softoken and nss libraries (to be
exact, I need to parse GOST-specific der-encoded data).
What is the best way to manage this ? I suppose I need
source tree is best to store such shared source ? Please, direct me.
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
wrong in disabling ECC signing only at softoken level ? This
will allow using of stock NSS builds with 3rd party ECC-enabled PKCS#11 tokens.
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC.
Here are some relevant discussions:
* Only require NSS_ENABLE_ECC to allow signing data
Thank you for explanation, Robert. Things get clear.
Best regards,
--
Konstantin Andreev.
Robert Relyea wrote:
[ ... SKIP ... ]
The function signature
*hash*_End( , , unsigned *digestLen, unsigned maxDigestLen )
[ ... SKIP ... ]
My point is you can implement this API is you want. it will
65 matches
Mail list logo
