<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Hi Jamil,<br>
    <br>
    We branched off of JSS 4.2.6 and created several patches ever
    since.   Merging with upstream JSS (4.3) has been planned to be done
    within the next year also.  Until then, we are not able to provide
    information with confidence on how JSS4.3 would work with our
    current releases.  If any Dogtag community member has tried and has
    answer for you, it would be great. <br>
    <br>
    Christina<br>
    <br>
    On 10/10/2012 09:54 AM, Nimeh, Jamil wrote:
    <blockquote
cite="mid:6A95FA630FB5124C886BAD159CDBA1F016D5FF27@wdc1exchmbxp05.hq.corp.viasat.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <div style="direction: ltr; font-family: Tahoma; color: rgb(0, 0,
        0); font-size: 10pt;">
        <p>[Re-reply to include <a moz-do-not-send="true"
            href="mailto:pki-devel@redhat.com">pki-devel@redhat.com</a>]</p>
        <p> </p>
        <p>Hi Christina, sorry for taking so long to get back to you.  I
          can file this against JSS, but given that it's a down-rev
          version (4.2.6) and appears to be fixed in JSS 4.3, is it
          worth filing this?<br>
          <br>
          I guess the bigger question that affects SHA-2 algorithms as
          they are implemented in Dogtag is whether or not I can safely
          use JSS 4.3 with Dogtag 9.0.x?  4.2.6 is what appears to be
          the latest rev in the F15 yum repositories.  Do you (or anyone
          on your team maybe) know if there are incompatibilities
          between JSS 4.2.6 and 4.3 that would break a Dogtag 9
          installation?<br>
          <br>
          If it can work the areas that this would affect would be:</p>
        <ul>
          <li>Proper creation of SCEP CertRep messages when using SHA-2
            algs </li>
          <li>The ability to sign OCSP responses using something other
            than SHA-1 (can that be changed?  I don't see a tuneable for
            this)
          </li>
          <li>The ability to submit CMC revocation messages using SHA-2
            and have it properly validated before acting on it in the
            CA.</li>
        </ul>
        <p>There might be other areas as well (maybe in other CMC
          related functions) but those three areas are the ones I've run
          into.</p>
        <p><br>
        </p>
        <p>Thanks,</p>
        <p>Jamil<br>
        </p>
        <div style="font-family: Times New Roman; color: rgb(0, 0, 0);
          font-size: 16px;">
          <hr tabindex="-1">
          <div style="direction: ltr;" id="divRpF168686"><font
              color="#000000" face="Tahoma" size="2"><b>From:</b>
              <a class="moz-txt-link-abbreviated" href="mailto:pki-users-bounces@redhat.com">pki-users-bounces@redhat.com</a>
              [<a class="moz-txt-link-abbreviated" href="mailto:pki-users-bounces@redhat.com">pki-users-bounces@redhat.com</a>] on behalf of Christina Fu
              [<a class="moz-txt-link-abbreviated" href="mailto:cfu@redhat.com">cfu@redhat.com</a>]<br>
              <b>Sent:</b> Monday, October 01, 2012 1:22 PM<br>
              <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:pki-users@redhat.com">pki-users@redhat.com</a><br>
              <b>Subject:</b> Re: [Pki-users] SHA-256 signed CMC
              revocation messages failing to verify on server<br>
            </font><br>
          </div>
          <div>Hi Jamil,<br>
            <br>
            I see the issue now.  I agree there is an issue with the
            OID.  In fact, the hashalg (2) is missing from not just
            SHA256, but also SHA384 and SHA512 as well.<br>
            <br>
            Please go ahead and file a bug for JSS so it could be
            scheduled for future release.  It will probably be
            automatically assigned to me by default.<br>
            <br>
            thanks,<br>
            Christina<br>
            <br>
            On 09/27/2012 09:34 AM, Christina Fu wrote:
            <blockquote type="cite">Hi Jamil,<br>
              <br>
              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.<br>
              <br>
              Yes, if you'd send in your code with precise reproducing
              steps, I might be able to look into it sooner.<br>
              <br>
              Christina<br>
              <br>
              On 09/25/2012 11:10 PM, Nimeh, Jamil wrote:
              <blockquote type="cite">
                <div style="font-family: Tahoma; direction: ltr; color:
                  rgb(0, 0, 0); font-size: 10pt;">
                  Hi Christina, thank you very much for getting back to
                  me.<br>
                  <br>
                  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?<br>
                  <br>
                  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:<br>
                  1. In the DigestAlgorithmIdentifiers segment of the
                  SignedData object (see RFC 5652 5.1): CMS/PKCS#7
                  objects have it properly asserted here.<br>
                  <br>
                  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.<br>
                  <br>
                  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.<br>
                  <br>
                  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.<br>
                  <br>
                  Once again, thank you very much for taking the time to
                  look at this.<br>
                  <br>
                  --Jamil<br>
                  <br>
                  <div style="font-family: Times New Roman; color:
                    rgb(0, 0, 0); font-size: 16px;">
                    <hr tabindex="-1">
                    <div style="direction: ltr;" id="divRpF261303"><font
                        color="#000000" face="Tahoma" size="2"><b>From:</b>
                        <a moz-do-not-send="true"
                          class="moz-txt-link-abbreviated"
                          href="mailto:pki-users-bounces@redhat.com"
                          target="_blank">
                          pki-users-bounces@redhat.com</a> [<a
                          moz-do-not-send="true"
                          class="moz-txt-link-abbreviated"
                          href="mailto:pki-users-bounces@redhat.com"
                          target="_blank">pki-users-bounces@redhat.com</a>]
                        on behalf of Christina Fu [<a
                          moz-do-not-send="true"
                          class="moz-txt-link-abbreviated"
                          href="mailto:cfu@redhat.com" target="_blank">cfu@redhat.com</a>]<br>
                        <b>Sent:</b> Tuesday, September 25, 2012 8:46 PM<br>
                        <b>To:</b> <a moz-do-not-send="true"
                          class="moz-txt-link-abbreviated"
                          href="mailto:pki-users@redhat.com"
                          target="_blank">
                          pki-users@redhat.com</a><br>
                        <b>Subject:</b> Re: [Pki-users] SHA-256 signed
                        CMC revocation messages failing to verify on
                        server<br>
                      </font><br>
                    </div>
                    <div>Hi Jamil,<br>
                      <br>
                      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.<br>
                      <br>
                      I changed all "SHA1" to "SHA256" in CMCRevoke.java
                      (with the exception with DSA), compiled, and it
                      just worked.  Did you do anything different?<br>
                      <br>
                      I could see in dumpasn1 where SHA245 is in place:<br>
                      <pre>               C-Sequence  (13)
                  Object Identifier  (9)
                     1 2 840 113549 1 1 11 (PKCS #1 SHA-256 With RSA Encryption)
                  NULL  (0)
</pre>
                      Christina<br>
                      <br>
                      On 09/19/2012 11:19 AM, Christina Fu wrote:
                      <blockquote type="cite">Hi Jamil,<br>
                        <br>
                        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.<br>
                        <br>
                        thanks,<br>
                        Christina<br>
                        <br>
                        On 09/19/2012 12:44 AM, Nimeh, Jamil wrote:
                        <blockquote type="cite">
                          <style id="owaParaStyle">P {
        MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
BODY {
        FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: #000000; FONT-SIZE: 10pt
}
BODY {
        
}
BODY {
        
}
BODY {
        
}
BODY {
        
}
P {
        MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
                          <div style="font-family: Tahoma; direction:
                            ltr; color: rgb(0, 0, 0); font-size: 10pt;">
                            <div style="font-family: Tahoma; direction:
                              ltr; color: rgb(0, 0, 0); font-size:
                              10pt;">
                              <p>Hello Dogtag Gurus,</p>
                              <p> </p>
                              <p>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.</p>
                              <p> </p>
                              <p>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.<br>
                              </p>
                              <p> </p>
                              <p>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?</p>
                              <p><br>
                              </p>
                              <p>Has anyone had any success generating
                                these CMC messages using SHA-2 hash algs
                                and getting Dogtag to accept them?</p>
                              <p><br>
                              </p>
                              <p>Thanks,</p>
                              <p>Jamil<br>
                              </p>
                            </div>
                          </div>
                          <pre><fieldset class="mimeAttachmentHeader" target="_blank"></fieldset>
_______________________________________________
Pki-users mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Pki-users@redhat.com" target="_blank">Pki-users@redhat.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pki-users" target="_blank">https://www.redhat.com/mailman/listinfo/pki-users</a></pre>
                        </blockquote>
                        <br>
                        <pre><fieldset class="mimeAttachmentHeader" target="_blank"></fieldset>
_______________________________________________
Pki-users mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Pki-users@redhat.com" target="_blank">Pki-users@redhat.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pki-users" target="_blank">https://www.redhat.com/mailman/listinfo/pki-users</a></pre>
                      </blockquote>
                      <br>
                    </div>
                  </div>
                </div>
              </blockquote>
              <br>
              <pre><fieldset class="mimeAttachmentHeader" target="_blank"></fieldset>
_______________________________________________
Pki-users mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Pki-users@redhat.com" target="_blank">Pki-users@redhat.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pki-users" target="_blank">https://www.redhat.com/mailman/listinfo/pki-users</a></pre>
            </blockquote>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>