[Swan] NSS transition questions

Paul Wouters pwouters at redhat.com
Fri May 24 17:18:22 EEST 2013


On Fri, 24 May 2013, Lennart Sorensen wrote:

>> The reason for this is that we have a lot of custom ASN.1/X.509 parsing
>> code that is old, does not support upcoming and new algorithms and
>> hashes, and has no concept of FIPS restrictions. If we use NSS, then all
>> of that is done for us, and is actively maintained and extended for us
>> to use.
>
> How does FIPS enter into the parsing code?

You are changing the parameters that go into the NSS functions, and not
use NSS native functions with their certifications for your own custom
code. Also, it introduces errors. For instance recently we cleaned up
a conversion from ASN.1 byte stream with a leading signed/unsigned zero
byte to bignum and back, which was introduced to remove that
signed/unsigned zero, because it causes an error for each CRL signature
whose first signature byte also started with a zero byte, as the bignum
conversion removed both leading zero bytes.

ASN.1 parsers are hard. NSS used to have three, now they have two. I'd
like us to have none :)

Paul


More information about the Swan mailing list