Re: [Pki-devel] Certificate Transparency SCT signature verification?
Hi Fraser, Thanks for the response! Regarding the poison extension, yes I was aware that it needed to be removed so the code already had it removed. It was the order of things left inside tbsCert that I was concerned about since I used the existing delete method provided for the Extension class, which I wasn't sure if it'd preserve the order of the remaining extensions. Thanks for confirming my suspicion. I will double-check the order. Also thanks for the input on how to handle failed CT log communication v.s. response verification failure. I will address them separately as suggested. Finally, nice catch with the missing data length!! I'll add that and go from there. thanks again! Christina On Mon, Jun 1, 2020 at 7:31 PM Fraser Tweedale wrote: > Hi Christina, > > Adding pki-devel@ for wider audience. Comments below. > > On Mon, Jun 01, 2020 at 06:28:42PM -0700, Christina Fu wrote: > > Hi Fraser, > > Do you know how the signature returned in the SCT response could be > > verified by the CA? > > My thought is that the CA should somehow verify the CT response after > > sending the add-pre-chain request and before signing the cert. Since log > > inclusion verification would not be feasible right after the request (the > > SCT response is supposed to be just a "promise, according to the rfc), I > > ruled that out and intend to stay with just the following two > verifications > > on the response itself: > > > >- checking if log id (CT log signer public key hash) returned in the > CT > >response is correct > >- this I have no problem verifying > > - Verifying if the signature returned in the CT response is correct > > - this I can't seem to get it working. > > > > I put the verification work above in the method "verifySCT". > > > https://github.com/dogtagpki/pki/blob/master/base/ca/src/com/netscape/ca/CAService.java#L1209 > > What I am wondering is how this can be done properly. Since the tbsCert > is > > not to contain the poison extension, the poison extension needs to be > > removed by the CT server before it signs. What if the order of the > > extensions contained in the tbsCert gets changed in the process? > > > The poison extension must be removed, and care must be taken to keep > everything else in the same order, and reserialise the parts in > exactly the same way. > > > It seems that the response should contain the tbsCert that it signs > (which > > isn't per the rfc) or I am not sure how the CA could verify the > signature. > > > The response does not contain the TBCCertificate. Both sides (log > and client) remove the poison extension (and change nothing else), > then both sides can sign the same data. > > > So the question now is if I should just leave out the check, unless you > > have other suggestions. > > > I do think we should verify the signature, to ensure the message was > actually received by the log server we wanted and not an impostor. > > > Of course, I also could have missed something in my code. > > > The binary format is complex and it's easy to miss something. After > you implement removal of the poison extension, if it is still not > working I will go over the code with a fine-tooth comb. > > I copied some of the code and left comments below, too. Comments > begin with `!!'. I think I found one bug and a couple of possible > improvements. > > > One last question, currently in the code, if verifySCT fails, I just > > "continue" to process for next CT log. Should this just bail out all > > together or it's fine to continue? Or could this be a choice by the > admin. > > What do you think and why? > > > https://github.com/dogtagpki/pki/blob/master/base/ca/src/com/netscape/ca/CAService.java#L951 > > > My line of thinking is this: > > - we should tolerate communication errors with log (perhaps > enqueuing the cert for a retry later) > > - but (assuming we implement it correctly) verifySCT failure is > indicative of something wrong with the log (e.g. key changed); it > is not a communication error and can be treated differently. > > - I think it's OK to fail hard. Admins will likely want to know if > something is wrong with CT logging. > > - But in case we make a mistake, or an org needs issuance to > continue despite CT log misbehaviour, there should be a config > knob to allow this condition to be ignored. "In case of > emergency..." > > > > > > thanks, > > Christina > > boolean verifySCT(CTResponse response, byte[] tbsCert, String > logPublicKey) > throws Exception { > > /* ... SNIP ... */ > > byte[] extensions = new byte[] {0, 0}; > !! although no extensions have been defined I think we should we take >extensions from the CT response to future-proof this code. i.e. >decode the base64 data from the "extensions" field, and prepend the > length. > > // piece them together > > int data_len = version.length + signature_type.length + > timestamp.length + entry_
[Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#734 (master - 2a95153)
Build Update for dogtagpki/pki-nightly-test - Build: #734 Status: Errored Duration: 13 mins and 45 secs Commit: 2a95153 (master) Author: Dinesh Prasanth M K Message: Remove EOL F29 from matrix and add support for v10.8 branch Signed-off-by: Dinesh Prasanth M K View the changeset: https://github.com/dogtagpki/pki-nightly-test/compare/1cec22733aad03cad1e589a08281f4a2db79ec90...2a95153102234446e6beb5d4074ae6eebd760fb3 View the full build log and details: https://travis-ci.org/github/dogtagpki/pki-nightly-test/builds/693844499?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the dogtagpki/pki-nightly-test repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=20325727&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. ___ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
Re: [Pki-devel] ACME Support: Error issuing certificate
Hi Endi - Unfortunately, customer issues have kept me from pursuing this further. I or one of my team still intends on doing so. I will be sure to let you know when I have tested. Jesse Van Hill Websphere Identity Management Architect & Dev Lead WebSphere Application Server & Open Liberty https://openliberty.io/ 507-513-6234 jlvan...@us.ibm.com From: Endi Sukma Dewata To: Jesse L Van hill Cc: pki-devel@redhat.com Date: 06/01/2020 10:42 PM Subject:[EXTERNAL] Re: [Pki-devel] ACME Support: Error issuing certificate - Original Message - > > Hi - > > > > My team is adding ACME 2.0 client support to the Open Liberty application > > server and wanted to test against Dogtag PKI's ACME server. My intention is > > to containerize the ACME server and drive it through the same functional > > tests we run against other ACME CA servers (i.e. - Pebble and Boulder for > > instance) to verify compatibility. > > > > The first error I hit was an issue with using JSS 4.7 and I understand that > > will be fixed by PR https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dogtagpki_jss_pull_532&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ&m=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU&s=yR1DB3UWeazhNiqWGB07NHnQX7X0sBaV10lsxjVQCyU&e= . > > > > [snip] > > > > To move past this error, I was advised to move down to JSS 4.6.2. Upon > > doing > > so, I made it past the initial error but now hit the following error: > > > > [snip] > > > > I can see in the ACME server's trace that it does indeed authorize my > > ownership of the domain and then try to issue the certificate. Examining > > the > > AcmeIssuer class shows that this class has several methods that are not > > implemented. > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dogtagpki_pki_blob_master_base_acme_src_main_java_org_dogtagpki_acme_issuer_ACMEIssuer.java-23L61&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ&m=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU&s=EMmhxG8NfXwv9nO6Y2ZN9tDB88eHvUbfak_OvsT00Mo&e= > > Is this expected or is it possible I have a misconfiguration? I assume I am > > testing too early and need to wait until the implementation is further > > along, but I wanted to test early enough that if there were issues I could > > detect them earlier rather than later. > > > > If it matters, I am testing the with the image from @pki/master on a Fedora > > 30 docker container. > > Hi Jesse, > > Thanks for your interest on Dogtag PKI and particularly the ACME responder. > Please note that the ACME responder itself is not a CA; it requires another > CA to issue the certificates. Currently the only supported CA is Dogtag PKI > CA which is connected through PKIIssuer: > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dogtagpki_pki_blob_master_base_acme_src_main_java_org_dogtagpki_acme_issuer_PKIIssuer.java&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ&m=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU&s=zYFrC9QqiVzp-IM4fM4if1sH-1FmUK_5zBke2JZfpds&e= > > The ACMEIssuer is just a base class. It's possible to support other CAs > by extending ACMEIssuer. If you would like to add support for another issuer > upstream feel free to submit a pull request. We have a prototype for OpenSSL > that we might add later. > > The issue with JSS is correct, and we're still working to fix it. > > The unimplemented ACMEIssuer issue seems to be caused by a missing CA. Please > follow these docs to install 389 DS, then install Dogtag PKI CA: > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.dogtagpki.org_wiki_Installing-5FDS&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ&m=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU&s=xmA_CJoxQsfhCvG8cKa74L7xDHAFEOwovQW4GiV0oF0&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dogtagpki_pki_blob_master_docs_installation_Installing-5FCA.md&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ&m=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU&s=83Pg-UOJPzA7pY9--diEC4lV018HX4hJDeTLCIy-L0Y&e= > > Then follow these docs to install and verify ACME: > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dogtagpki_pki_blob_master_docs_installation_Installing-5FACME-5FResponder.md&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ&m=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU&s=k3uYPL8AgToneGDmk87jNyTQrbDFB4blo-HJYv5Dloo&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dogtagpki_pki_blob_master_docs_user_Using-5FACME-5FResponder.md&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ&m=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU&s=-HRxW3SCJkfx88xsd_2u7xdz9j6MEtGN23rlPHogJx0&e= > > Officially we do not support containerization yet, but it's possible to run > ACME, CA, and DS in containers und