Re: CERT_VerifyCertificate question
David Stutzman wrote: > Here's some certutil -L output for the cert I am playing with here: > Signed Extensions: > Name: Certificate Key Usage > Critical: True > Usages: Digital Signature > Non-Repudiation > > Name: Certificate Type > Critical: True > Data: That says the cert is valid for SSL, but not S/MIME or object signing. It sounds like you're inventing a new network appliation/protocol for this, so perhaps none of those categories directly applies to you. It's up to your application to ask for the usage that is relevant it it. > I tested the certificate with the usages above passing in both > certificateUsageEmailSigner and certificateUsageObjectSigner to > CERT_VerifyCertificate and got a -8101 (SEC_ERROR_INADEQUATE_CERT_TYPE) > both times. That's exactly as predicted, given the Certificate Type extension above. > Is it ok to ignore cert usage and just look at the raw key usages myself > and require that digital signature and non-repudiation be present or am > I just beating the dead horse with the stick here and really should be > using either an email signing cert or an object signing cert? You're not likely to get CAs to issue a cert for a new type of usage that you propose. So IMO your best bet is to decide which of the above usages most closely matches what you're doing, and then ask CERT_VerifyCert* to verify for that usage. For your personal testing and development purposes, you could easily just test for SSL client usage, since that's what you have. Personally, I'd say that what you're doing sounds more like email usage than SSL, because you're generating durable signatures, which email does and SSL does not. But for your immediate test purposes, SSL certs should be adequate. > Again, I > just need to sign an arbitrary blob of input data that is passed in and > pass it back to the caller and it's not being used for email. Think of these usages more abstractly. Email usage generates signatures that are attached to the data, and that (may) last as long as the data to which they are attached. SSL generates signatures that are used at the beginning of an SSL connection and are then immediately discarded. The data that passes through the authenticated channel is not itself signed, and when the channel is over and done, there remains no durable signature. Which of those applications sounds more like yours? Figure that out, and then Pick a cert of that type. -- Nelson B ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CERT_VerifyCertificate question
David Stutzman wrote: Julien Pierre wrote: What purpose are you using the digital signatures for in your application ? That may help determine the right usage to check . A blob of data will be signed and sent out over a network to another system running the same application and the signature will need to be verified on the other end. It has nothing to do with S/MIME and email. That's why I wasn't sure if "email signing" was the right usage to check. Object signing is more like code signing, right? Here's some certutil -L output for the cert I am playing with here: Signed Extensions: Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Name: Certificate Type Critical: True Data: I tested the certificate with the usages above passing in both certificateUsageEmailSigner and certificateUsageObjectSigner to CERT_VerifyCertificate and got a -8101 (SEC_ERROR_INADEQUATE_CERT_TYPE) both times. Is it ok to ignore cert usage and just look at the raw key usages myself and require that digital signature and non-repudiation be present or am I just beating the dead horse with the stick here and really should be using either an email signing cert or an object signing cert? Again, I just need to sign an arbitrary blob of input data that is passed in and pass it back to the caller and it's not being used for email. Dave ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CERT_VerifyCertificate question
Julien Pierre wrote: What purpose are you using the digital signatures for in your application ? That may help determine the right usage to check . A blob of data will be signed and sent out over a network to another system running the same application and the signature will need to be verified on the other end. It has nothing to do with S/MIME and email. That's why I wasn't sure if "email signing" was the right usage to check. Object signing is more like code signing, right? Thanks for insight on the return usage parameter. In my particular case, I am only checking for the one usage so I can safely ignore the return value. Dave ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CERT_VerifyCertificate question
David, David Stutzman wrote: I'm looking at the functions CERT_VerifyCertificate and CERT_VerifyCertificateNow and see it has 2 parameters of type SECCertificateUsage, one required and one returned. What is the purpose of the returned one? SECCertificateUsage is a bit-field. If you requested several usages to be checked, the returned one will contain the usages for which the cert actually verified . If you only request one, then I believe the output argument is optional (ie. you can pass NULL). I checked the certutil code and the same variable is being passed into the verify function and the return is never checked. (ValidateCert on line 750 of certutil.c, "usage" declared on 756, passed into the verify method on 816 and never looked at again in the method.) certutil only checks one usage at a time, so it doesn't need to check the output argument. The SECStatus return from CERT_VerifyCertificate is sufficient . I'm generating and verifying digital signatures in my application. Do I need to slurp out the key usages from the certificate and make sure digital signature and non-repudiation are present before I do the verify or is passing in the requiredusages of "certificateUsageEmailSigner" to CERT_VerifyCertificate good enough? Does NSS care that the signing going on has nothing to do with email? I figured object signing wasn't really appropriate. I'm using NSS 3.11.2. NSS won't know what you are trying to do with the cert. If you pass certificateUsageEmailSigner to CERT_VerifyCertificate, NSS will check that the cert is appropriate for e-mail signing - including key usage/extended key usage extension . What purpose are you using the digital signatures for in your application ? That may help determine the right usage to check . ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CERT_VerifyCertificate question
David, David Stutzman wrote: I'm looking at the functions CERT_VerifyCertificate and CERT_VerifyCertificateNow and see it has 2 parameters of type SECCertificateUsage, one required and one returned. What is the purpose of the returned one? SECCertificateUsage is a bit-field. If you requested several usages to be checked, the returned one will contain the usages for which the cert actually verified . If you only request one, then I believe the output argument is optional (ie. you can pass NULL). I checked the certutil code and the same variable is being passed into the verify function and the return is never checked. (ValidateCert on line 750 of certutil.c, "usage" declared on 756, passed into the verify method on 816 and never looked at again in the method.) certutil only checks one usage at a time, so it doesn't need to check the output argument. The SECStatus return from CERT_VerifyCertificate is sufficient . I'm generating and verifying digital signatures in my application. Do I need to slurp out the key usages from the certificate and make sure digital signature and non-repudiation are present before I do the verify or is passing in the requiredusages of "certificateUsageEmailSigner" to CERT_VerifyCertificate good enough? Does NSS care that the signing going on has nothing to do with email? I figured object signing wasn't really appropriate. I'm using NSS 3.11.2. NSS won't know what you are trying to do with the cert. If you pass certificateUsageEmailSigner to CERT_VerifyCertificate, NSS will check that the cert is appropriate for e-mail signing - including key usage/extended key usage extension . What purpose are you using the digital signatures for in your application ? That may help determine the right usage to check . ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
CERT_VerifyCertificate question
I'm looking at the functions CERT_VerifyCertificate and CERT_VerifyCertificateNow and see it has 2 parameters of type SECCertificateUsage, one required and one returned. What is the purpose of the returned one? I checked the certutil code and the same variable is being passed into the verify function and the return is never checked. (ValidateCert on line 750 of certutil.c, "usage" declared on 756, passed into the verify method on 816 and never looked at again in the method.) I'm generating and verifying digital signatures in my application. Do I need to slurp out the key usages from the certificate and make sure digital signature and non-repudiation are present before I do the verify or is passing in the requiredusages of "certificateUsageEmailSigner" to CERT_VerifyCertificate good enough? Does NSS care that the signing going on has nothing to do with email? I figured object signing wasn't really appropriate. I'm using NSS 3.11.2. Thanks, Dave ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
