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);

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.

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.

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.

 - While browsing through some code for this, I noticed:

         if (!!(nameList = CERT_DecodeAltNameExtension(tmpArena,
 &subAltName))) {
             CERTGeneralName *current = nameList;

 I'm a little confused about the double exclamation mark? I hope it is
 something clever and not a typo?
It looks correct but funky. The if clearly should trigger if nameList is non-zero. It looks to me like a bad attempt to silence a compiler warning (I personally prefer coding (xxx = func) != NULL). I suspect the original code was:
   if (nameList = CERT_DecodeAltNameExtension(tmpArea,&subAltName))  {
Which triggered the normal compiler warning to protect agains things like: if (nameList = NULL) instead of if (nameList == NULL).

Okay, that is what i thought, but i just wanted to be sure "!!" was not
a bad typo.

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

Reply via email to