Here is an attempt based on RFC 3280. It seems that the designers of the EKU extension did not foresee any user-signatures except for e-mail. In a revised RFC 3280 I believe the "id-kp-emailProtection" text could be a bit more generalized. Adding a new OID would only make things worse.
No KU or EKU ----------------- An "all-round" certificate => included KU only --------- nonRepudiation => included digitalSignature Now it gets trickier. If there is a "matching" certificate with nonRepudiation set, the digitalSignature- only certificate should presumably NOT be included. Question: what is "matching" certificate? EKU only (very suspect cert) ---------- id-kp-emailProtection => included KU + EKU ------------ id-kp-emailProtection + KU rules => included or maybe ignoring EKU and use KU rules would be better since e-mailProtection is a misnomer? In case there is no working algorithm, We will have to add a request flag where you can specify "nonConforming" or similar. thanx Anders Rundgren ----- Original Message ----- From: "Jean-Marc Desperrier" <[EMAIL PROTECTED]> Newsgroups: mozilla.dev.tech.crypto To: <dev-tech-crypto@lists.mozilla.org> Sent: Tuesday, April 11, 2006 21:09 Subject: Re: certificate requirements for crypto.signText 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 _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
