Nelson B wrote:
Jean-Marc Desperrier wrote:
The trouble is that certUsageEmailSigner in it's current implementation
does indeed look for other things than non-repudiation. It checks that
the certificate is valid to sign mail, ie if it has an Extended key
usage it must include id-kp-emailProtection and the presence or not of
an email address interferes also. So some certificate that are perfectly
valid to sign data do not get certUsageEmailSigner
certUsageEmailSigner is merely an enumerated value.
In what function are you saying that this value has the behaviors you
describe?
CERT_KeyUsageAndTypeForCertUsage transcodes that value to a
requiredKeyUsage *and* a requiredCertType of NS_CERT_TYPE_EMAIL :
http://lxr.mozilla.org/security/ident?i=CERT_KeyUsageAndTypeForCertUsage
What I'm talking about comes from that requiredCertType that will be
compared to cert->nsCertType;
nsCertType is set by cert_GetCertType.
http://lxr.mozilla.org/security/ident?i=cert_GetCertType
The restrictions I talked about are inside the code for cert_GetCertType
with funny things like this excerpt :
569 /*
570 * for this release, we will allow SSL certs with an email address
571 * to be used for email
572 */
573 if ( ( nsCertType & NS_CERT_TYPE_SSL_CLIENT ) &&
574 cert->emailAddr && cert->emailAddr[0]) {
575 nsCertType |= NS_CERT_TYPE_EMAIL;
576 }
Blame won't tell exactly what this release was because it's earlier than
the date the code went public in 2000-03-31.
Note that I'm all for NSS being really tolerant in what it thinks is an
acceptable certificate when selected with certUsageEmailSigner, or else
we'll really need another, more tolerant, flag.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
