Launchpad has imported 32 comments from the remote bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=962760.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
On 2014-01-22T21:17:11+00:00 Cviecco wrote:
When evaluating NC libpkix always includes the CN as a dns name.
Therefore when you have a name constrained subCA that issues another
subCA the nameconstraints check produces a failure.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1358727/comments/0
On 2014-01-22T21:47:39+00:00 Cviecco wrote:
Created attachment 8363934
fix-bug-962760
Reply at:
https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1358727/comments/1
On 2014-01-22T22:45:36+00:00 Ryan-sleevi wrote:
Comment on attachment 8363934
fix-bug-962760
Review of attachment 8363934:
-
Using isCA isn't sufficient, since it's legitimate for a CA cert to be
used as an end-entity/server certificate.
You really want to have the reverse name checker (the one that starts at
the root and builds to the EE cert) pass along whether or not remaining
certs == 0.
http://mxr.mozilla.org/nss/source/lib/libpkix/pkix/checker/pkix_nameconstraintschecker.c#154
is the entry point for that pass (state-certsRemaining)
For the forward building case - which is an optimization strategy -
http://mxr.mozilla.org/nss/source/lib/libpkix/pkix/certsel/pkix_certselector.c#429
- you can simply *always* disable the CN check.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1358727/comments/2
On 2014-01-22T23:10:04+00:00 Cviecco wrote:
thanks for the review.
So it is ok to modify the signature of PKIX_PL_Cert_GetNameConstraints of you
prefer a new funcion?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1358727/comments/3
On 2014-01-23T00:18:21+00:00 Ryan-sleevi wrote:
It's fine to modify any of the PKIX_PL functions - they're all internal
to NSS (that is, the libpkix API is not publicly exposed, beyond the
basic cert_pi* bits)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1358727/comments/4
On 2014-01-23T22:50:19+00:00 Cviecco wrote:
Created attachment 8364695
fix-bug-962760-b
This patch, suggested by rsleevi prevents intermediates from, being
evaluated for being a CN. This solves the case for SSL server.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1358727/comments/5
On 2014-01-24T20:38:58+00:00 Ryan-sleevi wrote:
Comment on attachment 8364695
fix-bug-962760-b
Review of attachment 8364695:
-
Can you add a unit test - eg: to chains.sh - that demonstrates failure
before and success afterwards?
::: security/nss/lib/libpkix/include/pkix_pl_pki.h
@@ +1270,5 @@
* nameConstraints
* Address of CertNameConstraints that need to be satisfied.
+ * includeSubjectCommonName
+ * Whether to include or not the subject common name for the name
+ * constraints evaluation.
PKIX_TRUE if the subject common name should be considered a dNSName when
evaluating name constraints.
@@ +1284,5 @@
PKIX_Error *
PKIX_PL_Cert_CheckNameConstraints(
PKIX_PL_Cert *cert,
PKIX_PL_CertNameConstraints *nameConstraints,
+PKIX_Boolean includeSubjectCommonName,
treatCommonNameAsDNS ?
The reason is that the subject CN should always be subject to
directoryName constraints, it's the dNSName constraint thats special
here.
::: security/nss/lib/libpkix/pkix/certsel/pkix_certselector.c
@@ +425,5 @@
PKIX_COMCERTSELPARAMSGETNAMECONSTRAINTSFAILED);
if (nameConstraints != NULL) {
PKIX_CHECK(PKIX_PL_Cert_CheckNameConstraints
Let's include a comment here explaining why.
/* As only the end-entity certificate should have
* the common name constrained as if it was a dNSName,
* do not constrain the common name when building a
* forward path.
*/
Reply at:
https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1358727/comments/6
On 2014-01-28T00:04:58+00:00 Cviecco wrote:
Created attachment 8366316
fix-bug-962760
Reply at:
https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1358727/comments/7
