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(a)redhat.com [pki-users-bounces(a)redhat.com] on
behalf of Christina Fu [cfu(a)redhat.com]
*Sent:* Tuesday, September 25, 2012 8:46 PM
*To:* pki-users(a)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(a)redhat.com
>>
https://www.redhat.com/mailman/listinfo/pki-users
>
>
> _______________________________________________
> Pki-users mailing list
> Pki-users(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/pki-users