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 +
[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_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_medium=notification_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_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=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU=yR1DB3UWeazhNiqWGB07NHnQX7X0sBaV10lsxjVQCyU= . > > > > [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=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU=EMmhxG8NfXwv9nO6Y2ZN9tDB88eHvUbfak_OvsT00Mo= > > 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=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU=zYFrC9QqiVzp-IM4fM4if1sH-1FmUK_5zBke2JZfpds= > > 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=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU=xmA_CJoxQsfhCvG8cKa74L7xDHAFEOwovQW4GiV0oF0= > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dogtagpki_pki_blob_master_docs_installation_Installing-5FCA.md=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU=83Pg-UOJPzA7pY9--diEC4lV018HX4hJDeTLCIy-L0Y= > > 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=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU=k3uYPL8AgToneGDmk87jNyTQrbDFB4blo-HJYv5Dloo= > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dogtagpki_pki_blob_master_docs_user_Using-5FACME-5FResponder.md=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU=-HRxW3SCJkfx88xsd_2u7xdz9j6MEtGN23rlPHogJx0= > > Officially we do not support containerization yet, but it's possible to run > ACME, CA, and DS in containers under some scenarios. > > If you run Fedora 30 as a local Docker container, you can
