From helm at fionn.es.net Wed Sep 12 04:29:09 2012 From: helm at fionn.es.net (Mike Helm) Date: Tue, 11 Sep 2012 21:29:09 -0700 Subject: [Pki-users] setting DNSName in subjectAltName extension In-Reply-To: Your message of "Wed, 15 Aug 2012 08:16:07 PDT." <201208151516.q7FFG7Df025046@fionn.es.net> Message-ID: <201209120429.q8C4T9Qj004137@fionn.es.net> Mike Helm writes: > Marc Sauton writes: > > > I need to set DNSName in server subjectAltname extensions, but > > > having difficulty getting the server's name into this field. > > > something like this should work fine: > > policyset.encryptionCertSet.8.default.params.subjAltExtPattern_1=$request.SAN1$ > > I tried exactly this (see above). I think it is probably wrong, because they We solved this by finding out how to define a variable that can be used for filtering. How exactly this was found out I don't know - my colleague (cc'd) discovered it & mentioned it to me. this process might be described in the admin book somewhere, but I missed it. Here's an extract from a profile .cfg file: input.i3.name=Generic Input input.i3.params.gi_display_name0=HostName 1 ... input.i3.params.gi_param_enable0=true ... input.i3.params.gi_param_name0=csrDNSName1 ... input.i3.params.gi_param_name1=csrDNSName2 input.i3.params.gi_param_name2=csrDNSName3 ... input.params.gi_display_name0=HostName 1 ... input.params.gi_param_enable0=true ... input.params.gi_param_name0=csrDNSName1 ... policyset.serverCertSet.9.default.params.subjAltExtPattern_1=$request.requestor_email$ policyset.serverCertSet.9.default.params.subjAltExtPattern_0=$request.csrDNSName1$ ... policyset.serverCertSet.9.default.params.subjAltExtType_1=RFC822Name policyset.serverCertSet.9.default.params.subjAltExtType_0=DNSName ... From Jamil.Nimeh at viasat.com Sat Sep 15 22:32:08 2012 From: Jamil.Nimeh at viasat.com (Nimeh, Jamil) Date: Sat, 15 Sep 2012 22:32:08 +0000 Subject: [Pki-users] Output plugin for binary cert/PKCS#7 response? Message-ID: <6A95FA630FB5124C886BAD159CDBA1F016D5C798@wdc1exchmbxp05.hq.corp.viasat.com> Hello Dogtag gurus, I am currently experimenting with using sslget to submit PKCS#10s on a custom cert profile. Everything seems to be working well, but I always get back a big web page with the certificate or PKCS#10 buried in some javascript code. I've been doing grep/sed judo to get it out, but I was wondering if there was a way to get the response from the webserver to consist solely of the PKCS#7 or X.509 certificate in binary form? Is it something that is handled through an output plugin? Thank you, Jamil Nimeh -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jamil.Nimeh at viasat.com Sun Sep 16 09:03:56 2012 From: Jamil.Nimeh at viasat.com (Nimeh, Jamil) Date: Sun, 16 Sep 2012 09:03:56 +0000 Subject: [Pki-users] Output plugin for binary cert/PKCS#7 response? In-Reply-To: <6A95FA630FB5124C886BAD159CDBA1F016D5C798@wdc1exchmbxp05.hq.corp.viasat.com> References: <6A95FA630FB5124C886BAD159CDBA1F016D5C798@wdc1exchmbxp05.hq.corp.viasat.com> Message-ID: <6A95FA630FB5124C886BAD159CDBA1F016D5C7B2@wdc1exchmbxp05.hq.corp.viasat.com> Hi guys, I may have found my own answer to this one. I didn't see earlier that I could add the "xmlOutput=true" name-value pair into the query string on the request issued by sslget. Once I did that I could use perl's XML::Simple parser to get the pkcs7 response out and that seems like an approach that will work for me. At least so far. Thanks, Jamil ________________________________ From: pki-users-bounces at redhat.com [pki-users-bounces at redhat.com] on behalf of Nimeh, Jamil [Jamil.Nimeh at viasat.com] Sent: Saturday, September 15, 2012 3:32 PM To: pki-users at redhat.com Subject: [Pki-users] Output plugin for binary cert/PKCS#7 response? Hello Dogtag gurus, I am currently experimenting with using sslget to submit PKCS#10s on a custom cert profile. Everything seems to be working well, but I always get back a big web page with the certificate or PKCS#10 buried in some javascript code. I've been doing grep/sed judo to get it out, but I was wondering if there was a way to get the response from the webserver to consist solely of the PKCS#7 or X.509 certificate in binary form? Is it something that is handled through an output plugin? Thank you, Jamil Nimeh -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jamil.Nimeh at viasat.com Wed Sep 19 07:44:40 2012 From: Jamil.Nimeh at viasat.com (Nimeh, Jamil) Date: Wed, 19 Sep 2012 07:44:40 +0000 Subject: [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server Message-ID: <6A95FA630FB5124C886BAD159CDBA1F016D5CA54@wdc1exchmbxp05.hq.corp.viasat.com> Hello Dogtag Gurus, I have been trying to issue CMC revocation messages signed with SHA-256, but the server fails to validate the message in the CMCAuth java policy module. If I leave all fields the same but change the signature algorithm to SHA-1 then everything seems to work fine. I suspect this is another side-effect of the root-cause for bug 824624. It seems like in certain cases with JSS 4.2.6 when PKCS#7 messages are created using any of the SHA-2 variants, the OIDs get messed up. This happened with SCEP responses from the CA (the bug referenced above) and I had it happen with the CMC revoke modifications I made. The latter issue was fixed by pulling down JSS 4.3 and loading that jar in the classpath for the modified CMCRevoke tool. However, on the server side I ended up seeing verification failures. I'm running pki-common-9.0.20, jss 4.2.6, and NSS 3.13.4. At one point I had heard that Dogtag 9.0.X wasn't 100% safe to run with JSS 4.3 or later. Is that still the case with the latest 9.0 packages? Has anyone had any success generating these CMC messages using SHA-2 hash algs and getting Dogtag to accept them? Thanks, Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Wed Sep 19 18:19:09 2012 From: cfu at redhat.com (Christina Fu) Date: Wed, 19 Sep 2012 11:19:09 -0700 Subject: [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server In-Reply-To: <6A95FA630FB5124C886BAD159CDBA1F016D5CA54@wdc1exchmbxp05.hq.corp.viasat.com> References: <6A95FA630FB5124C886BAD159CDBA1F016D5CA54@wdc1exchmbxp05.hq.corp.viasat.com> Message-ID: <505A0C9D.1000709@redhat.com> Hi Jamil, We made an effort to support SHA2 where we can but might have missed a few places. I'll look into this and hopefully be able to get back to you in a few days. thanks, Christina On 09/19/2012 12:44 AM, Nimeh, Jamil wrote: > > Hello Dogtag Gurus, > > I have been trying to issue CMC revocation messages signed with > SHA-256, but the server fails to validate the message in the CMCAuth > java policy module. If I leave all fields the same but change the > signature algorithm to SHA-1 then everything seems to work fine. > > I suspect this is another side-effect of the root-cause for bug > 824624. It seems like in certain cases with JSS 4.2.6 when PKCS#7 > messages are created using any of the SHA-2 variants, the OIDs get > messed up. This happened with SCEP responses from the CA (the bug > referenced above) and I had it happen with the CMC revoke > modifications I made. The latter issue was fixed by pulling down JSS > 4.3 and loading that jar in the classpath for the modified CMCRevoke > tool. However, on the server side I ended up seeing verification > failures. > > I'm running pki-common-9.0.20, jss 4.2.6, and NSS 3.13.4. At one > point I had heard that Dogtag 9.0.X wasn't 100% safe to run with JSS > 4.3 or later. Is that still the case with the latest 9.0 packages? > > > Has anyone had any success generating these CMC messages using SHA-2 > hash algs and getting Dogtag to accept them? > > > Thanks, > > Jamil > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Wed Sep 26 03:46:17 2012 From: cfu at redhat.com (Christina Fu) Date: Tue, 25 Sep 2012 20:46:17 -0700 Subject: [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server In-Reply-To: <505A0C9D.1000709@redhat.com> References: <6A95FA630FB5124C886BAD159CDBA1F016D5CA54@wdc1exchmbxp05.hq.corp.viasat.com> <505A0C9D.1000709@redhat.com> Message-ID: <50627A89.9080407@redhat.com> Hi Jamil, I tried to reproduce your issue, but I seemed to be able to generate CMC revocation request with SHA-256 digest. I have to admit that my main development machine is RHEL and I work on RHCS8.1 tree. I changed all "SHA1" to "SHA256" in CMCRevoke.java (with the exception with DSA), compiled, and it just worked. Did you do anything different? I could see in dumpasn1 where SHA245 is in place: C-Sequence (13) Object Identifier (9) 1 2 840 113549 1 1 11 (PKCS #1 SHA-256 With RSA Encryption) NULL (0) Christina On 09/19/2012 11:19 AM, Christina Fu wrote: > Hi Jamil, > > We made an effort to support SHA2 where we can but might have missed a > few places. I'll look into this and hopefully be able to get back to > you in a few days. > > thanks, > Christina > > On 09/19/2012 12:44 AM, Nimeh, Jamil wrote: >> >> Hello Dogtag Gurus, >> >> I have been trying to issue CMC revocation messages signed with >> SHA-256, but the server fails to validate the message in the CMCAuth >> java policy module. If I leave all fields the same but change the >> signature algorithm to SHA-1 then everything seems to work fine. >> >> I suspect this is another side-effect of the root-cause for bug >> 824624. It seems like in certain cases with JSS 4.2.6 when PKCS#7 >> messages are created using any of the SHA-2 variants, the OIDs get >> messed up. This happened with SCEP responses from the CA (the bug >> referenced above) and I had it happen with the CMC revoke >> modifications I made. The latter issue was fixed by pulling down JSS >> 4.3 and loading that jar in the classpath for the modified CMCRevoke >> tool. However, on the server side I ended up seeing verification >> failures. >> >> I'm running pki-common-9.0.20, jss 4.2.6, and NSS 3.13.4. At one >> point I had heard that Dogtag 9.0.X wasn't 100% safe to run with JSS >> 4.3 or later. Is that still the case with the latest 9.0 packages? >> >> >> Has anyone had any success generating these CMC messages using SHA-2 >> hash algs and getting Dogtag to accept them? >> >> >> Thanks, >> >> Jamil >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Wed Sep 26 03:48:27 2012 From: cfu at redhat.com (Christina Fu) Date: Tue, 25 Sep 2012 20:48:27 -0700 Subject: [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server In-Reply-To: <50627A89.9080407@redhat.com> References: <6A95FA630FB5124C886BAD159CDBA1F016D5CA54@wdc1exchmbxp05.hq.corp.viasat.com> <505A0C9D.1000709@redhat.com> <50627A89.9080407@redhat.com> Message-ID: <50627B0B.30500@redhat.com> oh, and I forgot to mention that I submitted the revocation request through EE CMC revocation (on an RHCS 8.1 CA instance) and the certificate was promptly revoked. Christina On 09/25/2012 08:46 PM, Christina Fu wrote: > Hi Jamil, > > I tried to reproduce your issue, but I seemed to be able to generate > CMC revocation request with SHA-256 digest. I have to admit that my > main development machine is RHEL and I work on RHCS8.1 tree. > > I changed all "SHA1" to "SHA256" in CMCRevoke.java (with the exception > with DSA), compiled, and it just worked. Did you do anything different? > > I could see in dumpasn1 where SHA245 is in place: > C-Sequence (13) > Object Identifier (9) > 1 2 840 113549 1 1 11 (PKCS #1 SHA-256 With RSA Encryption) > NULL (0) > Christina > > On 09/19/2012 11:19 AM, Christina Fu wrote: >> Hi Jamil, >> >> We made an effort to support SHA2 where we can but might have missed >> a few places. I'll look into this and hopefully be able to get back >> to you in a few days. >> >> thanks, >> Christina >> >> On 09/19/2012 12:44 AM, Nimeh, Jamil wrote: >>> >>> Hello Dogtag Gurus, >>> >>> I have been trying to issue CMC revocation messages signed with >>> SHA-256, but the server fails to validate the message in the CMCAuth >>> java policy module. If I leave all fields the same but change the >>> signature algorithm to SHA-1 then everything seems to work fine. >>> >>> I suspect this is another side-effect of the root-cause for bug >>> 824624. It seems like in certain cases with JSS 4.2.6 when PKCS#7 >>> messages are created using any of the SHA-2 variants, the OIDs get >>> messed up. This happened with SCEP responses from the CA (the bug >>> referenced above) and I had it happen with the CMC revoke >>> modifications I made. The latter issue was fixed by pulling down >>> JSS 4.3 and loading that jar in the classpath for the modified >>> CMCRevoke tool. However, on the server side I ended up seeing >>> verification failures. >>> >>> I'm running pki-common-9.0.20, jss 4.2.6, and NSS 3.13.4. At one >>> point I had heard that Dogtag 9.0.X wasn't 100% safe to run with JSS >>> 4.3 or later. Is that still the case with the latest 9.0 packages? >>> >>> >>> Has anyone had any success generating these CMC messages using SHA-2 >>> hash algs and getting Dogtag to accept them? >>> >>> >>> Thanks, >>> >>> Jamil >>> >>> >>> _______________________________________________ >>> Pki-users mailing list >>> Pki-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-users >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jamil.Nimeh at viasat.com Wed Sep 26 06:10:55 2012 From: Jamil.Nimeh at viasat.com (Nimeh, Jamil) Date: Wed, 26 Sep 2012 06:10:55 +0000 Subject: [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server In-Reply-To: <50627A89.9080407@redhat.com> References: <6A95FA630FB5124C886BAD159CDBA1F016D5CA54@wdc1exchmbxp05.hq.corp.viasat.com> <505A0C9D.1000709@redhat.com>,<50627A89.9080407@redhat.com> Message-ID: <6A95FA630FB5124C886BAD159CDBA1F016D5E063@wdc1exchmbxp05.hq.corp.viasat.com> Hi Christina, thank you very much for getting back to me. I haven't seen the problem with the PKCS#1 SHA-256 with RSA OID. That seems to work across the board with JSS and Dogtag (otherwise I could never sign a cert with SHA-256, I suppose). I'd be curious to know what version of JSS is on your RHEL/RHCS8.1 machine, and perhaps what NSS version. On my Fedora box it's JSS 4.2.6 and NSS 3.13.4. Maybe something different between the bits we're running? I've run into the issue when a PKCS#7 or CMS signedData message is created. In those cases, the SHA-256 OID would normally be asserted in two locations: 1. In the DigestAlgorithmIdentifiers segment of the SignedData object (see RFC 5652 5.1): CMS/PKCS#7 objects have it properly asserted here. 2. In the DigestAlgorithmIdentifier portion of the SignerInfo (see RFC 5652 5.3): This is where the OID gets messed up with SHA-2 algs. Since there is only one signer, the DigestAlgorithmIdentifiers section at the beginning would have only one OID, the SHA-256 one, and that OID should be repeated again in the SignerInfo. What happens though is that the SignerInfo's DigestAlgorithmIdentifier will show up with an OID of 2.16.840.1.101.3.4.1 when it should be 2.16.840.1.101.3.4.2.1. This appears to happen with JSS 4.2.6, but not with JSS 4.3. But 4.2.6 is what comes down when the dogtag packages are pulled with yum, so I wasn't sure if I could pop in a newer JSS safely. Tomorrow I'll take my doctored up CMCRevoke and cook up two messages, one where I load the 4.2.6 JSS and one where I do 4.3 and I'll send you the DER encodings so you can see what I'm talking about. I don't recall, but I think the bug report for 824624 might have sample SCEP CertRep messages from the CA, which show the issue using PKCS#7. Once again, thank you very much for taking the time to look at this. --Jamil ________________________________ From: pki-users-bounces at redhat.com [pki-users-bounces at redhat.com] on behalf of Christina Fu [cfu at redhat.com] Sent: Tuesday, September 25, 2012 8:46 PM To: pki-users at redhat.com Subject: Re: [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server Hi Jamil, I tried to reproduce your issue, but I seemed to be able to generate CMC revocation request with SHA-256 digest. I have to admit that my main development machine is RHEL and I work on RHCS8.1 tree. I changed all "SHA1" to "SHA256" in CMCRevoke.java (with the exception with DSA), compiled, and it just worked. Did you do anything different? I could see in dumpasn1 where SHA245 is in place: C-Sequence (13) Object Identifier (9) 1 2 840 113549 1 1 11 (PKCS #1 SHA-256 With RSA Encryption) NULL (0) Christina On 09/19/2012 11:19 AM, Christina Fu wrote: Hi Jamil, We made an effort to support SHA2 where we can but might have missed a few places. I'll look into this and hopefully be able to get back to you in a few days. thanks, Christina On 09/19/2012 12:44 AM, Nimeh, Jamil wrote: Hello Dogtag Gurus, I have been trying to issue CMC revocation messages signed with SHA-256, but the server fails to validate the message in the CMCAuth java policy module. If I leave all fields the same but change the signature algorithm to SHA-1 then everything seems to work fine. I suspect this is another side-effect of the root-cause for bug 824624. It seems like in certain cases with JSS 4.2.6 when PKCS#7 messages are created using any of the SHA-2 variants, the OIDs get messed up. This happened with SCEP responses from the CA (the bug referenced above) and I had it happen with the CMC revoke modifications I made. The latter issue was fixed by pulling down JSS 4.3 and loading that jar in the classpath for the modified CMCRevoke tool. However, on the server side I ended up seeing verification failures. I'm running pki-common-9.0.20, jss 4.2.6, and NSS 3.13.4. At one point I had heard that Dogtag 9.0.X wasn't 100% safe to run with JSS 4.3 or later. Is that still the case with the latest 9.0 packages? Has anyone had any success generating these CMC messages using SHA-2 hash algs and getting Dogtag to accept them? Thanks, Jamil _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From techpkiuser at gmail.com Thu Sep 27 08:24:40 2012 From: techpkiuser at gmail.com (pki tech) Date: Thu, 27 Sep 2012 13:54:40 +0530 Subject: [Pki-users] DogTag CS for CentOS or later Fedora Versions Message-ID: Hi all, Im planning to go for a Large scale CA implementation with Current DogTag release 9.0 on Fedora 15. But the main worry that i have is the Fedora Support Cycle, which makes an doubt on the security of the Systems at the long run. Are there anyone who has successfully deployed a complete CA, OCSP and RA based solution on CentOS platform? If so I can continue my implementations with CentOS. What I found while googling was there are package issues while deploying DogTag over CentOS. Although the main site says DogTag 9.0 is tested for up to only Fedora 15, I found rpms for the subsystems pki-ca, pki-ocsp and pki-ra in other Fedora repositories for example Fedora 16. So will it be possible to have a stable PKI infrastructure over Fedora 16 with DogTag 9.0 (DogTag 10 is still in alpha stage) In the meantime I'm locally testing all the functionalities of DogTag 9.0 over Fedora 16 and CentOS. Will update as I progress. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Thu Sep 27 13:33:26 2012 From: jdennis at redhat.com (John Dennis) Date: Thu, 27 Sep 2012 09:33:26 -0400 Subject: [Pki-users] DogTag CS for CentOS or later Fedora Versions In-Reply-To: References: Message-ID: <506455A6.5020109@redhat.com> On 09/27/2012 04:24 AM, pki tech wrote: > Hi all, > > Im planning to go for a Large scale CA implementation with Current > DogTag release 9.0 on Fedora 15. But the main worry that i have is the > Fedora Support Cycle, which makes an doubt on the security of the > Systems at the long run. > > Are there anyone who has successfully deployed a complete CA, OCSP and > RA based solution on CentOS platform? If so I can continue my > implementations with CentOS. What I found while googling was there are > package issues while deploying DogTag over CentOS. > > Although the main site says DogTag 9.0 is tested for up to only Fedora > 15, I found rpms for the subsystems pki-ca, pki-ocsp and pki-ra in other > Fedora repositories for example Fedora 16. So will it be possible to > have a stable PKI infrastructure over Fedora 16 with DogTag 9.0 (DogTag > 10 is still in alpha stage) > > In the meantime I'm locally testing all the functionalities of DogTag > 9.0 over Fedora 16 and CentOS. Will update as I progress. The IPA project (www.freeipa.org) uses dogtag as a core component of it's infrastructure. On Fedora IPA is known as freeipa and on RHEL (CentOS is a RHEL clone) it's known as just ipa. IPA is a critical component of many new deployments (RHEL, Fedora, and hopefully soon others) and since dogtag heavily is used by IPA you can be assured it's getting a lot attention and will run well on our targeted distributions (especially RHEL and it's derivatives). I'm not sure what you plan to use dogtag for, but IPA may give a much friendlier way to access the functionality found in dogtag, as well as a host of other features. The packaging issues you refer to are likely solved now largely because when IPA started making heavy use of dogtag a few years ago those issues percolated to the top and were addressed. The dogtag and IPA teams work very closely together and are constantly refining both products, you shouldn't worry in this regard. HTH, John -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From cfu at redhat.com Thu Sep 27 16:34:07 2012 From: cfu at redhat.com (Christina Fu) Date: Thu, 27 Sep 2012 09:34:07 -0700 Subject: [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server In-Reply-To: <6A95FA630FB5124C886BAD159CDBA1F016D5E063@wdc1exchmbxp05.hq.corp.viasat.com> References: <6A95FA630FB5124C886BAD159CDBA1F016D5CA54@wdc1exchmbxp05.hq.corp.viasat.com> <505A0C9D.1000709@redhat.com>, <50627A89.9080407@redhat.com> <6A95FA630FB5124C886BAD159CDBA1F016D5E063@wdc1exchmbxp05.hq.corp.viasat.com> Message-ID: <50647FFF.9000001@redhat.com> Hi Jamil, I am running a variant of jss-4.2.6-23 (with one extra patch that I have not had time to push/build, but it has nothing to do with your suspected area). For nss, I'm running nss-3.13.5-8.el5. Again, I develop on RHEL. Yes, if you'd send in your code with precise reproducing steps, I might be able to look into it sooner. Christina On 09/25/2012 11:10 PM, Nimeh, Jamil wrote: > Hi Christina, thank you very much for getting back to me. > > I haven't seen the problem with the PKCS#1 SHA-256 with RSA OID. That > seems to work across the board with JSS and Dogtag (otherwise I could > never sign a cert with SHA-256, I suppose). I'd be curious to know > what version of JSS is on your RHEL/RHCS8.1 machine, and perhaps what > NSS version. On my Fedora box it's JSS 4.2.6 and NSS 3.13.4. Maybe > something different between the bits we're running? > > I've run into the issue when a PKCS#7 or CMS signedData message is > created. In those cases, the SHA-256 OID would normally be asserted > in two locations: > 1. In the DigestAlgorithmIdentifiers segment of the SignedData object > (see RFC 5652 5.1): CMS/PKCS#7 objects have it properly asserted here. > > 2. In the DigestAlgorithmIdentifier portion of the SignerInfo (see RFC > 5652 5.3): This is where the OID gets messed up with SHA-2 algs. > Since there is only one signer, the DigestAlgorithmIdentifiers section > at the beginning would have only one OID, the SHA-256 one, and that > OID should be repeated again in the SignerInfo. > > What happens though is that the SignerInfo's DigestAlgorithmIdentifier > will show up with an OID of 2.16.840.1.101.3.4.1 when it should be > 2.16.840.1.101.3.4.2.1. This appears to happen with JSS 4.2.6, but > not with JSS 4.3. But 4.2.6 is what comes down when the dogtag > packages are pulled with yum, so I wasn't sure if I could pop in a > newer JSS safely. > > Tomorrow I'll take my doctored up CMCRevoke and cook up two messages, > one where I load the 4.2.6 JSS and one where I do 4.3 and I'll send > you the DER encodings so you can see what I'm talking about. I don't > recall, but I think the bug report for 824624 might have sample SCEP > CertRep messages from the CA, which show the issue using PKCS#7. > > Once again, thank you very much for taking the time to look at this. > > --Jamil > > ------------------------------------------------------------------------ > *From:* pki-users-bounces at redhat.com [pki-users-bounces at redhat.com] on > behalf of Christina Fu [cfu at redhat.com] > *Sent:* Tuesday, September 25, 2012 8:46 PM > *To:* pki-users at redhat.com > *Subject:* Re: [Pki-users] SHA-256 signed CMC revocation messages > failing to verify on server > > Hi Jamil, > > I tried to reproduce your issue, but I seemed to be able to generate > CMC revocation request with SHA-256 digest. I have to admit that my > main development machine is RHEL and I work on RHCS8.1 tree. > > I changed all "SHA1" to "SHA256" in CMCRevoke.java (with the exception > with DSA), compiled, and it just worked. Did you do anything different? > > I could see in dumpasn1 where SHA245 is in place: > C-Sequence (13) > Object Identifier (9) > 1 2 840 113549 1 1 11 (PKCS #1 SHA-256 With RSA Encryption) > NULL (0) > Christina > > On 09/19/2012 11:19 AM, Christina Fu wrote: >> Hi Jamil, >> >> We made an effort to support SHA2 where we can but might have missed >> a few places. I'll look into this and hopefully be able to get back >> to you in a few days. >> >> thanks, >> Christina >> >> On 09/19/2012 12:44 AM, Nimeh, Jamil wrote: >>> >>> Hello Dogtag Gurus, >>> >>> I have been trying to issue CMC revocation messages signed with >>> SHA-256, but the server fails to validate the message in the CMCAuth >>> java policy module. If I leave all fields the same but change the >>> signature algorithm to SHA-1 then everything seems to work fine. >>> >>> I suspect this is another side-effect of the root-cause for bug >>> 824624. It seems like in certain cases with JSS 4.2.6 when PKCS#7 >>> messages are created using any of the SHA-2 variants, the OIDs get >>> messed up. This happened with SCEP responses from the CA (the bug >>> referenced above) and I had it happen with the CMC revoke >>> modifications I made. The latter issue was fixed by pulling down >>> JSS 4.3 and loading that jar in the classpath for the modified >>> CMCRevoke tool. However, on the server side I ended up seeing >>> verification failures. >>> >>> I'm running pki-common-9.0.20, jss 4.2.6, and NSS 3.13.4. At one >>> point I had heard that Dogtag 9.0.X wasn't 100% safe to run with JSS >>> 4.3 or later. Is that still the case with the latest 9.0 packages? >>> >>> >>> Has anyone had any success generating these CMC messages using SHA-2 >>> hash algs and getting Dogtag to accept them? >>> >>> >>> Thanks, >>> >>> Jamil >>> >>> >>> _______________________________________________ >>> Pki-users mailing list >>> Pki-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-users >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: