NSS PKINIT requires nsCertType extension?

[Matt Rogers]

When building with --with-pkinit-crypto-impl=nss and running the test
suite, I found that PKINIT related tests fail on certificate
verification (either client or KDC certificate depending on the test)
with SEC_ERROR_INADEQUATE_CERT_TYPE : "Certificate type not approved
for application." It turns out NSS is expecting the Netscape
certificate type extension (nsCertType = client/server in
openssl.cnf), and adding it to the test certificates made the tests
pass. Is this expected, or documented anywhere? I've not seen
nsCertType required for SSLClient and SSLServer usage profiles before,
so I'm not sure why it is expected here. My version of NSS is 3.27 by
the way.

Regards,
Matt
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Greg Hudson]

Post by Matt Rogers
It turns out NSS is expecting the Netscape
certificate type extension (nsCertType = client/server in
openssl.cnf), and adding it to the test certificates made the tests
pass. Is this expected, or documented anywhere?

I remember NSS having some behavior differences which made NSS PKINIT
not a drop-in for the OpenSSL implementation, but I don't remember if
this was one Nalin had discussed. I went back and looked at the
conversation on krbdev in September and October 2011 when we merged it,
but there wasn't any discussion of behavior differences there.

I've actually been meaning to ask if we can remove the NSS PKINIT
implementation, since it was motivated by
https://fedoraproject.org/wiki/FedoraCryptoConsolidation
which is now defunct. What led you to try it out?
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Matt Rogers]

Post by Greg Hudson

Post by Matt Rogers
It turns out NSS is expecting the Netscape
certificate type extension (nsCertType = client/server in
openssl.cnf), and adding it to the test certificates made the tests
pass. Is this expected, or documented anywhere?

I remember NSS having some behavior differences which made NSS PKINIT
not a drop-in for the OpenSSL implementation, but I don't remember if
this was one Nalin had discussed. I went back and looked at the
conversation on krbdev in September and October 2011 when we merged it,
but there wasn't any discussion of behavior differences there.
I've actually been meaning to ask if we can remove the NSS PKINIT
implementation, since it was motivated by
https://fedoraproject.org/wiki/FedoraCryptoConsolidation
which is now defunct. What led you to try it out?

If it was only used by the crypto consolidation effort then perhaps we
can remove it (I will ask around). The cert authorization plugin
framework needed new functions in the PKINIT crypto backend, which I
wrote for the OpenSSL variant, so I was giving it a shot before I went
about writing NSS versions. But I can hold off on those for now if the
NSS support is in limbo.
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Greg Hudson]

Post by Matt Rogers

Post by Greg Hudson
I remember NSS having some behavior differences which made NSS PKINIT
not a drop-in for the OpenSSL implementation, but I don't remember if
this was one Nalin had discussed. I went back and looked at the
conversation on krbdev in September and October 2011 when we merged it,
but there wasn't any discussion of behavior differences there.

I found the discussion I was thinking of. It was in private mail so I
won't quote it, but the summary is that NSS doesn't seem to allow the
use of server certificates that aren't SSL certs (which I think matches
the problem you encountered). To me, that's a pretty fatal flaw in NSS
as a general-purpose X.509 library and in the NSS PKINIT support.

Post by Matt Rogers
If it was only used by the crypto consolidation effort then perhaps we
can remove it (I will ask around). The cert authorization plugin
framework needed new functions in the PKINIT crypto backend, which I
wrote for the OpenSSL variant, so I was giving it a shot before I went
about writing NSS versions. But I can hold off on those for now if the
NSS support is in limbo.

Sounds good.

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev