From builds at travis-ci.org Mon Jun 1 13:51:30 2020 From: builds at travis-ci.org (Travis CI) Date: Mon, 01 Jun 2020 13:51:30 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#733 (master - 2a95153) In-Reply-To: Message-ID: <5ed507e229dd3_13f911a6168a01312ed@travis-tasks-55f7f44d74-bxq28.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #733 Status: Errored Duration: 13 mins and 52 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/693449491?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmoluguw at redhat.com Tue Jun 2 01:19:50 2020 From: dmoluguw at redhat.com (Dinesh Prasanth Moluguwan Krishnamoorthy) Date: Mon, 1 Jun 2020 21:19:50 -0400 Subject: [Pki-devel] Configuration of Friendly Name and Country In-Reply-To: <1939126319.1053883.1590744361826@mail.yahoo.com> References: <610282460.993452.1589894499437.ref@mail.yahoo.com> <610282460.993452.1589894499437@mail.yahoo.com> <330501825.1349074.1589959713108@mail.yahoo.com> <1058440424.2164619.1590125265577@mail.yahoo.com> <629355512.2238047.1590152222893@mail.yahoo.com> <1939126319.1053883.1590744361826@mail.yahoo.com> Message-ID: Hi Nadeera, Please find my reply inline On Fri, May 29, 2020 at 5:28 AM Nadeera Galagedara < nadeeragalagedara at yahoo.com> wrote: > Dear Dinesh, > > I tried the method and still have the problem. I will tell you what i did > and can you tell me where did I do wrong. > > My root CA has "*Maximum number of intermediate CAs: unlimited*" and now > I am installing the issuing ca (what I use for to issue certificates for > clients). For the issuing *CA **Maximum number of intermediate* CAs want > to be *Zero*. > > I basically follow > https://www.dogtagpki.org/wiki/PKI_10.5_Installing_CA_with_External_CA_Signing_Certificate steps > (send the CSR to root CA and get back the signed certificate) and added > > policyset.caCertSet.5.default.name=Basic Constraints Extension Default > policyset.caCertSet.5.default.params.basicConstraintsCritical=true > policyset.caCertSet.5.default.params.basicConstraintsIsCA=true > policyset.caCertSet.5.default.params.basicConstraintsPathLen=0 > > lines to both step 1 and step 2 config files and installed the Issuing CA. > The above lines need to be added to profiles, not to .cfg for pkispawn. My colleague, Fraser, wrote an awesome blog post [1] explaining how Dogtag profiles work. Though the post was written in 2014 this should give you a good understanding of how to configure profiles. But, in your case, I believe you need to craft the CSR with this constraint. So, you need to use the `openssl` or `certutil` tools to specify the *basic Constraint*. For example, using openssl: openssl req \ -addext basicConstraints=critical,CA:TRUE,pathlen:1 \ ... You can also refer how to create CSR in our wiki [2] [1] https://frasertweedale.github.io/blog-redhat/posts/2014-05-14-dogtag-profile-definitions.html [2] https://www.dogtagpki.org/wiki/Generating_CA_Signing_CSR_with_OpenSSL HTH. Good luck! Regards, --Dinesh > Then I went to the Issuing CA's * "SSL End Users Services" *-> "*Manual > User Dual-Use Certificate **Enrollment"* and created a certificate. Then > I wend to *Agent Services* and approve that request. > > I imported that certificate to browser. But still it shows my issuing CA *Maximum > number of intermediate CAs: unlimited. * > > Can you tell me what did I do wrong. > > > On Friday, May 22, 2020, 11:27:29 PM GMT+5:30, Dinesh Prasanth Moluguwan > Krishnamoorthy wrote: > > > Nadeera, > > (CC'ing pki-devel) > > Setting the number of intermediate CAs can be achieved by using "Basic > Constraints Extension" [1] and setting the PathLen= to the required value. > > You need to set this extension on a CA profile and then issue a CA signing > cert. You can't modify this value on an already issued CA cert. Read more > on how to add this constraint to a profile here [2] > > [1] > https://access.redhat.com/documentation/en-us/red_hat_certificate_system/9/html-single/administration_guide_common_criteria_edition/index#Basic_Constraints_Extension_Default > [2] > https://access.redhat.com/documentation/en-us/red_hat_certificate_system/9/html-single/administration_guide_common_criteria_edition/index#about-extensions > > Regards, > --Dinesh > > On Fri, May 22, 2020 at 8:57 AM Nadeera Galagedara < > nadeeragalagedara at yahoo.com> wrote: > > Dear Dinesh, > > I want another help from you. How can I change the "Maximum number of > intermediate CAs: unlimited" value. > On Friday, May 22, 2020, 10:57:45 AM GMT+5:30, Nadeera Galagedara < > nadeeragalagedara at yahoo.com> wrote: > > > Dear Dinesh, > > That is a great explanation. That problem that problem is also solved. > Again thank you. > > On Wednesday, May 20, 2020, 08:27:56 PM GMT+5:30, Dinesh Prasanth > Moluguwan Krishnamoorthy wrote: > > > Hi Nadeera, > > I'm glad I could resolve your issues. > > As for the friendly/nickname, these names are customizable based on the > system you use and are not specified during the certificate issuance. > > For instance, when you specified " > *pki_ca_signing_nickname=mycompany_nickname"* this nickname was used to > import the CA system certificate in your PKI server's NSSDB. You can view > this by doing `certutil -L -d /etc/pki/pki-tomcat/alias` and you should see > the *mycompany_nickname* listed. > > I have very limited knowledge of handling certificates in windows. From > Googling around: you can try to *right-click on the certificate -> > Properties -> "general" tab -> Set "Friendly Name"*. > > HTH > > Regards, > --Dinesh > > On Wed, May 20, 2020 at 3:28 AM Nadeera Galagedara < > nadeeragalagedara at yahoo.com> wrote: > > Dear Dinesh, > > Thank you for your support and it is been very helpful. I am using Centos > 7 and the version came with it is 10.5. I am using that version. I think I > have corrected the country (with c=LK). But I still have a problem with the > nickname. > > I used the *pki_ca_signing_nickname=mycompany_nickname* line but still > the friendly name show on windows PC (I have imported the issued > certificate to a windows PC) format like 's ID. > My requirement is to show the the Friendly Name (shows as in Windows PC) as > "*mycompany_nickname* " I have attached a screenshot also. Please tell me > what did I do wrong. > > > [image: image.jpeg] > > > > > > > > > > > The full config is mentioned below > > > *Step 1* > > *[CA]* > *pki_admin_email=mycompany at abc.lk * > *pki_admin_name=caadmin* > *pki_admin_nickname=caadmin* > *pki_admin_password=Secret.123* > *pki_admin_uid=caadmin* > > *pki_client_database_password=Secret.123* > *pki_client_database_purge=False* > *pki_client_pkcs12_password=Secret.123* > > *pki_ds_base_dn=dc=issueca,dc=mycompany,dc=lk* > *pki_ds_database=ca2* > *pki_ds_password=Secret.123* > > *pki_security_domain_name=mycompany_domain* > *pki_token_password=Secret.123* > > *pki_external=True* > *pki_external_step_two=False* > > > *pki_ca_signing_subject_dn=cn=mycompany_cn,ou=mycompany_ou,o=mycompany_o,c=LK* > *pki_ca_signing_csr_path=ca_signing.csr* > > *pki_ca_signing_nickname=mycompany_nickname* > > *pki_default_ocsp_uri=http://ocsp.mycompany.lk * > > > > *Step 2* > > *[CA]* > *pki_admin_email=mycompany at abc.lk * > *pki_admin_name=caadmin* > *pki_admin_nickname=caadmin* > *pki_admin_password=Secret.123* > *pki_admin_uid=caadmin* > > *pki_client_database_password=Secret.123* > *pki_client_database_purge=False* > *pki_client_pkcs12_password=Secret.123* > > *pki_ds_base_dn=dc=issueca,dc=mycompany,dc=lk* > *pki_ds_database=ca2* > *pki_ds_password=Secret.123* > > *pki_security_domain_name=mycompany_domain* > *pki_token_password=Secret.123* > > *pki_external=True* > *pki_external_step_two=True* > > *pki_ca_signing_csr_path=ca_signing.csr* > *pki_ca_signing_cert_path=ca_signing.crt* > > *pki_ca_signing_nickname=mycompany_nickname* > > *pki_default_ocsp_uri=http://ocsp.mycompany.lk * > > > > > Thank you and best regards, > Nadeera. > > > > > > On Wednesday, May 20, 2020, 03:29:15 AM GMT+5:30, Dinesh Prasanth > Moluguwan Krishnamoorthy wrote: > > > Hi Nadeera, > > What version of dogtag PKI are you trying to install? You are referring to > PKI 10.5 docs. The latest release is 10.8.3 > > If you are using the latest packages, our docs are available in our > upstream repo: https://github.com/dogtagpki/pki/tree/v10.8/docs > > (see inline reply) > > On Tue, May 19, 2020 at 9:22 AM Nadeera Galagedara < > nadeeragalagedara at yahoo.com> wrote: > > Dear all, > > I am new to dogtag and I am installing a sub ca using the method > described in > https://www.dogtagpki.org/wiki/PKI_10.5_Installing_CA_with_External_CA_Signing_Certificate > . I want to know. > > 1) What is the parameter to change the *Friendly Name* > > We do not use "Friendly Name". Instead, we use "nickname" > To configure the nickname for CA signing certificate use: > pki_ca_signing_nickname= > > 2) What is the parameter to change the *Country/Locality* > > This is set using subject dn. So, in your case specify the Country using > this attribute: pki_ca_signing_subject_dn= > > > 3) Where (a page link ) I can find details about each of this > configuration parameters. > > I don't have a page that explains all the config parameters. But, I do > have a page that can give you a list of parameters that you can use (since > you mentioned 10.5, I'm listing the contents of 10.5 branch. Refer to the > appropriate branch for an updated list) > > https://github.com/dogtagpki/pki/blob/DOGTAG_10_5_BRANCH/base/server/etc/default.cfg > > HTH > > Regards, > --Dinesh > > > > > Thank you. > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.jpeg Type: image/jpeg Size: 11889 bytes Desc: not available URL: From ftweedal at redhat.com Tue Jun 2 02:31:28 2020 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 2 Jun 2020 12:31:28 +1000 Subject: [Pki-devel] Certificate Transparency SCT signature verification? In-Reply-To: References: Message-ID: <20200602023128.GA1932521@T470s> 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_type.length + issuer_key_hash.length + tbsCert.length + extensions.length; logger.debug(method + " data_len = "+ data_len); ByteArrayOutputStream ostream = new ByteArrayOutputStream(); ostream.write(version); ostream.write(signature_type); ostream.write(timestamp); ostream.write(entry_type); ostream.write(issuer_key_hash); ostream.write(tbsCert); !! I believe you need to prepend the length of tbsCert as a THREE-byte length field, because its definition is `opaque TBSCertificate<1..2^24-1>;' ostream.write(extensions); byte[] data = ostream.toByteArray(); // Now, verify the signature // Note: this part currently does not work; see method comment above // cfu ToDo: interpret the alg bytes later; hardcode for now Signature signer = Signature.getInstance("SHA256withEC", "Mozilla-JSS"); signer.initVerify(log_pubKey); signer.update(data); !! We could call signer.update() multiple times instead of making an intermediate ByteArrayOutputStream. I do not care about the performance, just whatever might simplify the routine. if (!signer.verify(signature)) { logger.error(method + "failed to verify SCT signature; pass for now"); // this method is not yet working; Let this pass for now // return false; } else { logger.debug(method + "SCT signature verified successfully"); } logger.debug("verifySCT ends"); return true; } Cheers, Fraser From edewata at redhat.com Tue Jun 2 03:42:33 2020 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 1 Jun 2020 23:42:33 -0400 (EDT) Subject: [Pki-devel] ACME Support: Error issuing certificate In-Reply-To: <461128887.74968333.1588722549092.JavaMail.zimbra@redhat.com> References: <461128887.74968333.1588722549092.JavaMail.zimbra@redhat.com> Message-ID: <1151718650.80906954.1591069353298.JavaMail.zimbra@redhat.com> ----- 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://github.com/dogtagpki/jss/pull/532 . > > > > [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://github.com/dogtagpki/pki/blob/master/base/acme/src/main/java/org/dogtagpki/acme/issuer/ACMEIssuer.java#L61 > > 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://github.com/dogtagpki/pki/blob/master/base/acme/src/main/java/org/dogtagpki/acme/issuer/PKIIssuer.java > > 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://www.dogtagpki.org/wiki/Installing_DS > https://github.com/dogtagpki/pki/blob/master/docs/installation/Installing_CA.md > > Then follow these docs to install and verify ACME: > https://github.com/dogtagpki/pki/blob/master/docs/installation/Installing_ACME_Responder.md > https://github.com/dogtagpki/pki/blob/master/docs/user/Using_ACME_Responder.md > > 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 execute commands in > the container to install ACME, CA, and DS like regular Fedora applications. > > However, if you want to run each of them as a single process in separate > Docker containers, it is possible with some code changes and tricks: > https://www.dogtagpki.org/wiki/PKI_ACME_Container > https://www.dogtagpki.org/wiki/PKI_CA_Container > https://www.dogtagpki.org/wiki/DS_Container > > Similarly, here are the docs for OpenShift deployment: > https://www.dogtagpki.org/wiki/PKI_ACME_OpenShift > https://www.dogtagpki.org/wiki/PKI_CA_OpenShift > https://www.dogtagpki.org/wiki/DS_OpenShift > > Please note that the wiki is used for development, so the content might be > outdated. The official docs are on GitHub. > > The ACME responder is easier to containerize. We might be able to officially > support its containerization soon. However, the CA might be more difficult > due to its dependency on systemd and other issues. The DS seems to require at > least some code changes. > > If you want to test ACME containerization, you probably can install ACME > in container with CA and DS running on the host machine. If you just want > to test ACME compatibility without containerization, it might be best to > install ACME, CA, and DS on regular machine for now. > > Hope this helps. Let me know if you have any question. > > -- > Endi S. Dewata Hi Jesse, I was just wondering if you managed to test against the ACME server. FYI, we're working on adding an embedded CA into the ACME server so it can be containerized more easily without dependency on a separate CA. Hopefully we will have something usable by the end of the month. -- Endi S. Dewata From jlvanhil at us.ibm.com Tue Jun 2 13:35:11 2020 From: jlvanhil at us.ibm.com (Jesse L Van hill) Date: Tue, 2 Jun 2020 08:35:11 -0500 Subject: [Pki-devel] ACME Support: Error issuing certificate In-Reply-To: <1151718650.80906954.1591069353298.JavaMail.zimbra@redhat.com> References: <461128887.74968333.1588722549092.JavaMail.zimbra@redhat.com> <1151718650.80906954.1591069353298.JavaMail.zimbra@redhat.com> Message-ID: 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 jlvanhil at us.ibm.com From: Endi Sukma Dewata To: Jesse L Van hill Cc: pki-devel at 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 under some scenarios. > > If you run Fedora 30 as a local Docker container, you can execute commands in > the container to install ACME, CA, and DS like regular Fedora applications. > > However, if you want to run each of them as a single process in separate > Docker containers, it is possible with some code changes and tricks: > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.dogtagpki.org_wiki_PKI-5FACME-5FContainer&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ&m=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU&s=VoKx7DcSwpPXtbs-ac9PdWEgBmWxLe-4fVHuSr-5RKo&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.dogtagpki.org_wiki_PKI-5FCA-5FContainer&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ&m=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU&s=krbjWrMWU2O_5EgaTueZWYXq9zGsZZuroKRynZe9UjQ&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.dogtagpki.org_wiki_DS-5FContainer&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ&m=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU&s=EUUoIMN4PZD6msDJagHHySPe9B2WHwXcKgU9lX2QkvE&e= > > Similarly, here are the docs for OpenShift deployment: > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.dogtagpki.org_wiki_PKI-5FACME-5FOpenShift&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ&m=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU&s=7dW0HhjY5hE4MAZDwLwf8LqrpBHBSNpmsGxqBTq8XSU&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.dogtagpki.org_wiki_PKI-5FCA-5FOpenShift&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ&m=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU&s=7OIJFGz0il3DDiaoMw5r7OGWVBF-ZN491dZNKsLcbTk&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.dogtagpki.org_wiki_DS-5FOpenShift&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=OeLqSQnCTv2HDGUGIGioVgCfu5htFL_AvF_k0yzMIuQ&m=_vqP6WqfPXWS-lVxVboHe0OGfbRUjz0O-aAdQx1k9yU&s=PVugzBKdsVXKuG_bbQxu9epLvCB3-bI-Eap4oSp3ggw&e= > > Please note that the wiki is used for development, so the content might be > outdated. The official docs are on GitHub. > > The ACME responder is easier to containerize. We might be able to officially > support its containerization soon. However, the CA might be more difficult > due to its dependency on systemd and other issues. The DS seems to require at > least some code changes. > > If you want to test ACME containerization, you probably can install ACME > in container with CA and DS running on the host machine. If you just want > to test ACME compatibility without containerization, it might be best to > install ACME, CA, and DS on regular machine for now. > > Hope this helps. Let me know if you have any question. > > -- > Endi S. Dewata Hi Jesse, I was just wondering if you managed to test against the ACME server. FYI, we're working on adding an embedded CA into the ACME server so it can be containerized more easily without dependency on a separate CA. Hopefully we will have something usable by the end of the month. -- Endi S. Dewata -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From builds at travis-ci.org Tue Jun 2 13:51:41 2020 From: builds at travis-ci.org (Travis CI) Date: Tue, 02 Jun 2020 13:51:41 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#734 (master - 2a95153) In-Reply-To: Message-ID: <5ed6596d7f485_13ff544765e20223653@travis-tasks-5cd78cf5db-skhkr.mail> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Tue Jun 2 22:05:19 2020 From: cfu at redhat.com (Christina Fu) Date: Tue, 2 Jun 2020 15:05:19 -0700 Subject: [Pki-devel] Certificate Transparency SCT signature verification? In-Reply-To: <20200602023128.GA1932521@T470s> References: <20200602023128.GA1932521@T470s> Message-ID: 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_type.length + > issuer_key_hash.length + tbsCert.length + > extensions.length; > > logger.debug(method + " data_len = "+ data_len); > ByteArrayOutputStream ostream = new ByteArrayOutputStream(); > > ostream.write(version); > ostream.write(signature_type); > ostream.write(timestamp); > > ostream.write(entry_type); > ostream.write(issuer_key_hash); > ostream.write(tbsCert); > !! I believe you need to prepend the length of tbsCert as a > THREE-byte length field, because its definition is > `opaque TBSCertificate<1..2^24-1>;' > > ostream.write(extensions); > > byte[] data = ostream.toByteArray(); > > // Now, verify the signature > // Note: this part currently does not work; see method comment > above > > // cfu ToDo: interpret the alg bytes later; hardcode for now > Signature signer = Signature.getInstance("SHA256withEC", > "Mozilla-JSS"); > signer.initVerify(log_pubKey); > signer.update(data); > !! We could call signer.update() multiple times instead of making an > intermediate ByteArrayOutputStream. I do not care about the > performance, just whatever might simplify the routine. > > if (!signer.verify(signature)) { > logger.error(method + "failed to verify SCT signature; pass > for now"); > // this method is not yet working; Let this pass for now > // return false; > } else { > logger.debug(method + "SCT signature verified successfully"); > } > logger.debug("verifySCT ends"); > > return true; > } > > > > Cheers, > Fraser > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Wed Jun 3 13:52:48 2020 From: builds at travis-ci.org (Travis CI) Date: Wed, 03 Jun 2020 13:52:48 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#735 (master - 2a95153) In-Reply-To: Message-ID: <5ed7ab2f9653c_13ff84621670813668f@travis-tasks-845d689f9f-jg4jc.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #735 Status: Errored Duration: 14 mins and 33 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/694255449?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmoluguw at redhat.com Wed Jun 3 22:50:23 2020 From: dmoluguw at redhat.com (Dinesh Prasanth Moluguwan Krishnamoorthy) Date: Wed, 3 Jun 2020 18:50:23 -0400 Subject: [Pki-devel] Questions regarding addition of our own Cockpit module Message-ID: Hello team, I?m part of Dogtag PKI open-source project [1]. Our team strives to provide enterprise-class open-source Public Key Infrastructure (PKI) [2]. Dogtag PKI server is a Java web application running on Tomcat. Currently, we have a stand-alone Java AWT client tool called pkiconsole to access PKI services on the server. PKI users are authenticated using client certificates stored in LDAP. These users only exist in LDAP, they are not users on the host itself. We are trying to convert pkiconsole into a web application. We had a chance to look at Cockpit from a very high-level and have some questions. I?m reaching out to the members of the Cockpit team before we could make a concrete decision on whether Cockpit is a perfect choice for us. The questions are: 1. According to [3] Cockpit seems to require the host to join the IdM domain in order to authenticate PKI users into Cockpit using client cert auth. Is it possible to use client cert auth without joining a domain? Will that require major changes in Cockpit? 2. Suppose the user has been authenticated into Cockpit using a client cert as described in #1, is it possible for Cockpit to use the same client certificate auth to access PKI server? Or do we need to use a different auth mechanism? Regards, The PKI Team [1] https://github.com/dogtagpki/pki [2] https://www.dogtagpki.org/wiki/PKI_Main_Page [3] https://cockpit-project.org/guide/latest/cert-authentication -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmoluguw at redhat.com Thu Jun 4 00:17:39 2020 From: dmoluguw at redhat.com (Dinesh Prasanth Moluguwan Krishnamoorthy) Date: Wed, 3 Jun 2020 20:17:39 -0400 Subject: [Pki-devel] Questions regarding addition of our own Cockpit module Message-ID: Hello team, I?m part of Dogtag PKI open-source project [1]. Our team strives to provide enterprise-class open-source Public Key Infrastructure (PKI) [2]. Dogtag PKI server is a Java web application running on Tomcat. Currently, we have a stand-alone Java AWT client tool called pkiconsole to access PKI services on the server. PKI users are authenticated using client certificates stored in LDAP. These users only exist in LDAP, they are not users on the host itself. We are trying to convert pkiconsole into a web application. We had a chance to look at Cockpit from a very high-level and have some questions. I?m reaching out to the members of the Cockpit team, before we could make a concrete decision on whether Cockpit is a perfect choice for us. The questions are: 1. According to [3] Cockpit seems to require the host to join the IdM domain in order to authenticate PKI users into Cockpit using client cert auth. Is it possible to use client cert auth without joining a domain? Will that require major changes in Cockpit? 2. Suppose the user has been authenticated into Cockpit using a client cert as described in #1, is it possible for Cockpit to use the same client certificate auth to access PKI server? Or do we need to use a different auth mechanism? Regards, The PKI Team [1] https://github.com/dogtagpki/pki [2] https://www.dogtagpki.org/wiki/PKI_Main_Page [3] https://cockpit-project.org/guide/latest/cert-authentication -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Thu Jun 4 02:57:49 2020 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 4 Jun 2020 12:57:49 +1000 Subject: [Pki-devel] Questions regarding addition of our own Cockpit module In-Reply-To: References: Message-ID: <20200604025749.GJ1932521@T470s> On Wed, Jun 03, 2020 at 08:17:39PM -0400, Dinesh Prasanth Moluguwan Krishnamoorthy wrote: > Hello team, > > I?m part of Dogtag PKI open-source project [1]. Our team strives to provide > enterprise-class open-source Public Key Infrastructure (PKI) [2]. > > Dogtag PKI server is a Java web application running on Tomcat. Currently, > we have a stand-alone Java AWT client tool called pkiconsole to access PKI > services on the server. PKI users are authenticated using client > certificates stored in LDAP. These users only exist in LDAP, they are not > users on the host itself. > > We are trying to convert pkiconsole into a web application. We had a chance > to look at Cockpit from a very high-level and have some questions. I?m > reaching out to the members of the Cockpit team, before we could make a > concrete decision on whether Cockpit is a perfect choice for us. > > The questions are: > > 1. According to [3] Cockpit seems to require the host to join the IdM > domain in order to authenticate PKI users into Cockpit using client cert > auth. Is it possible to use client cert auth without joining a domain? Will > that require major changes in Cockpit? > At a glance at the linked doc, it looks like Cockpit is using mod_lookup_identity certmap capability or something similar for user cert authn. Therefore to work directly for Dogtag users I think it is more than just configuration; something would need to be built. > 2. Suppose the user has been authenticated into Cockpit using a client cert > as described in #1, is it possible for Cockpit to use the same client > certificate auth to access PKI server? Or do we need to use a different > auth mechanism? > How would this even work? Cockpit does not have the user's private key. Or Cockpit would need a highly privileged agent credential and access control around its use. Danger! We had quite a few CVEs in FreeIPA because of this kind of privilege separation violation. Or some new mechanism like a signed "endorsement" from Cockpit that user "alice" requests to do operation X, with ACL enforcement staying in Dogtag (where it belongs). Anything is possible, but only some approaches are secure. I like the idea of Cockpit using a proxy credential. But the only mechanism we have for that is GSS-API/Kerberos, which takes us full circle back to the requirement for a full-fledge IDM environment. Cheers, Fraser > Regards, > The PKI Team > > [1] https://github.com/dogtagpki/pki > > [2] https://www.dogtagpki.org/wiki/PKI_Main_Page > > [3] https://cockpit-project.org/guide/latest/cert-authentication > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From builds at travis-ci.org Thu Jun 4 13:52:53 2020 From: builds at travis-ci.org (Travis CI) Date: Thu, 04 Jun 2020 13:52:53 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#736 (master - 2a95153) In-Reply-To: Message-ID: <5ed8fcb53c5ed_13fdbd4715828160529@travis-tasks-6cb487fd6-gb9ql.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #736 Status: Errored Duration: 14 mins and 28 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/694644900?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Fri Jun 5 13:53:29 2020 From: builds at travis-ci.org (Travis CI) Date: Fri, 05 Jun 2020 13:53:29 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#737 (master - 2a95153) In-Reply-To: Message-ID: <5eda4e59859b6_13fad12e16e4c14426e@travis-tasks-b7ff9dffb-7nsgq.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #737 Status: Errored Duration: 14 mins and 39 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/695027705?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Sat Jun 6 13:53:34 2020 From: builds at travis-ci.org (Travis CI) Date: Sat, 06 Jun 2020 13:53:34 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#738 (master - 2a95153) In-Reply-To: Message-ID: <5edb9fde2cfe0_13f9fe191510c210419@travis-tasks-98fbb46c-xlvhl.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #738 Status: Errored Duration: 14 mins and 9 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/695384200?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Sun Jun 7 13:54:59 2020 From: builds at travis-ci.org (Travis CI) Date: Sun, 07 Jun 2020 13:54:59 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#739 (master - 2a95153) In-Reply-To: Message-ID: <5edcf1b29f32b_13fec7adcd0382141f3@travis-tasks-64bc846988-sxggn.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #739 Status: Errored Duration: 14 mins and 38 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/695665476?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Mon Jun 8 13:54:27 2020 From: builds at travis-ci.org (Travis CI) Date: Mon, 08 Jun 2020 13:54:27 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#740 (master - 2a95153) In-Reply-To: Message-ID: <5ede4312a50b4_13fc06b0d756c161722@travis-tasks-cd698885-btfm7.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #740 Status: Errored Duration: 13 mins and 26 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/696019238?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Tue Jun 9 13:56:25 2020 From: builds at travis-ci.org (Travis CI) Date: Tue, 09 Jun 2020 13:56:25 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#741 (master - 2a95153) In-Reply-To: Message-ID: <5edf95079967e_13f9e6fb193e02314dc@travis-tasks-5d9d774588-w462k.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #741 Status: Errored Duration: 14 mins and 34 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/696460182?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Wed Jun 10 13:55:37 2020 From: builds at travis-ci.org (Travis CI) Date: Wed, 10 Jun 2020 13:55:37 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#742 (master - 2a95153) In-Reply-To: Message-ID: <5ee0e65958975_13fd8505eae6c17056b@travis-tasks-7b69d96954-8jfdr.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #742 Status: Errored Duration: 13 mins and 43 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/696847732?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Thu Jun 11 13:56:10 2020 From: builds at travis-ci.org (Travis CI) Date: Thu, 11 Jun 2020 13:56:10 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#743 (master - 2a95153) In-Reply-To: Message-ID: <5ee237f9e44d7_13fe6b851647020399c@travis-tasks-c68d59-frlhc.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #743 Status: Errored Duration: 13 mins and 38 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/697224572?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Fri Jun 12 00:08:25 2020 From: cfu at redhat.com (Christina Fu) Date: Thu, 11 Jun 2020 17:08:25 -0700 Subject: [Pki-devel] Certificate Transparency SCT signature verification? In-Reply-To: References: <20200602023128.GA1932521@T470s> Message-ID: HI Fraser, verifySCT still fails. I still think the fact the rfc does not require the signed object to accompany the signature presents undue challenge to the party that needs to verify the signature. Although I understand that this is v1, and the issue would not be present in v2 since there will not be poison extension ;-/. I'd appreciate it if you could find time to take a closer look. Here is my latest attempt: https://github.com/dogtagpki/pki/pull/440 Since it's a patch against the latest code, for a full view, it would be easier if you just apply the patch and read from "(Certificate Transparency)" in base/ca/src/com/netscape/ca/CAService.java This patch would require JSS change at: https://github.com/dogtagpki/jss/pull/575 Code still requires some refinement but I wish to address the verification issue before cleaning things up. Of course I still let verifySCT returns success for now just so people could still play with CT. Much appreciated! Christina On Tue, Jun 2, 2020 at 3:05 PM Christina Fu wrote: > 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_type.length + >> issuer_key_hash.length + tbsCert.length + >> extensions.length; >> >> logger.debug(method + " data_len = "+ data_len); >> ByteArrayOutputStream ostream = new ByteArrayOutputStream(); >> >> ostream.write(version); >> ostream.write(signature_type); >> ostream.write(timestamp); >> >> ostream.write(entry_type); >> ostream.write(issuer_key_hash); >> ostream.write(tbsCert); >> !! I believe you need to prepend the length of tbsCert as a >> THREE-byte length field, because its definition is >> `opaque TBSCertificate<1..2^24-1>;' >> >> ostream.write(extensions); >> >> byte[] data = ostream.toByteArray(); >> >> // Now, verify the signature >> // Note: this part currently does not work; see method comment >> above >> >> // cfu ToDo: interpret the alg bytes later; hardcode for now >> Signature signer = Signature.getInstance("SHA256withEC", >> "Mozilla-JSS"); >> signer.initVerify(log_pubKey); >> signer.update(data); >> !! We could call signer.update() multiple times instead of making an >> intermediate ByteArrayOutputStream. I do not care about the >> performance, just whatever might simplify the routine. >> >> if (!signer.verify(signature)) { >> logger.error(method + "failed to verify SCT signature; pass >> for now"); >> // this method is not yet working; Let this pass for now >> // return false; >> } else { >> logger.debug(method + "SCT signature verified successfully"); >> } >> logger.debug("verifySCT ends"); >> >> return true; >> } >> >> >> >> Cheers, >> Fraser >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Fri Jun 12 00:58:18 2020 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 12 Jun 2020 10:58:18 +1000 Subject: [Pki-devel] Certificate Transparency SCT signature verification? In-Reply-To: References: <20200602023128.GA1932521@T470s> Message-ID: <20200612005818.GD2312208@T470s> Hi Christina, I will find a day next week to have a close look. Probably Tuesday or Wednesday. It will help to have test environment setup documentation, i.e. how to set up a log server to test with, how to configure Dogtag, etc. If this stuff is already written then you just need to tell me where to look :) Cheers, Fraser On Thu, Jun 11, 2020 at 05:08:25PM -0700, Christina Fu wrote: > HI Fraser, > verifySCT still fails. I still think the fact the rfc does not require the > signed object to accompany the signature presents undue challenge to the > party that needs to verify the signature. Although I understand that this > is v1, and the issue would not be present in v2 since there will not be > poison extension ;-/. > I'd appreciate it if you could find time to take a closer look. > > Here is my latest attempt: > https://github.com/dogtagpki/pki/pull/440 > Since it's a patch against the latest code, for a full view, it would be > easier if you just apply the patch and read from "(Certificate > Transparency)" in > base/ca/src/com/netscape/ca/CAService.java > This patch would require JSS change at: > https://github.com/dogtagpki/jss/pull/575 > > Code still requires some refinement but I wish to address the verification > issue before cleaning things up. Of course I still let verifySCT returns > success for now just so people could still play with CT. > Much appreciated! > Christina > > On Tue, Jun 2, 2020 at 3:05 PM Christina Fu wrote: > > > 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_type.length + > >> issuer_key_hash.length + tbsCert.length + > >> extensions.length; > >> > >> logger.debug(method + " data_len = "+ data_len); > >> ByteArrayOutputStream ostream = new ByteArrayOutputStream(); > >> > >> ostream.write(version); > >> ostream.write(signature_type); > >> ostream.write(timestamp); > >> > >> ostream.write(entry_type); > >> ostream.write(issuer_key_hash); > >> ostream.write(tbsCert); > >> !! I believe you need to prepend the length of tbsCert as a > >> THREE-byte length field, because its definition is > >> `opaque TBSCertificate<1..2^24-1>;' > >> > >> ostream.write(extensions); > >> > >> byte[] data = ostream.toByteArray(); > >> > >> // Now, verify the signature > >> // Note: this part currently does not work; see method comment > >> above > >> > >> // cfu ToDo: interpret the alg bytes later; hardcode for now > >> Signature signer = Signature.getInstance("SHA256withEC", > >> "Mozilla-JSS"); > >> signer.initVerify(log_pubKey); > >> signer.update(data); > >> !! We could call signer.update() multiple times instead of making an > >> intermediate ByteArrayOutputStream. I do not care about the > >> performance, just whatever might simplify the routine. > >> > >> if (!signer.verify(signature)) { > >> logger.error(method + "failed to verify SCT signature; pass > >> for now"); > >> // this method is not yet working; Let this pass for now > >> // return false; > >> } else { > >> logger.debug(method + "SCT signature verified successfully"); > >> } > >> logger.debug("verifySCT ends"); > >> > >> return true; > >> } > >> > >> > >> > >> Cheers, > >> Fraser > >> > >> From builds at travis-ci.org Fri Jun 12 13:59:23 2020 From: builds at travis-ci.org (Travis CI) Date: Fri, 12 Jun 2020 13:59:23 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#744 (master - 2a95153) In-Reply-To: Message-ID: <5ee38a3b5c8eb_13fb6c03ec3881244aa@travis-tasks-7b5794998d-vhpb4.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #744 Status: Errored Duration: 16 mins and 14 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/697615610?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Sat Jun 13 13:57:29 2020 From: builds at travis-ci.org (Travis CI) Date: Sat, 13 Jun 2020 13:57:29 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#745 (master - 2a95153) In-Reply-To: Message-ID: <5ee4db494fee3_13fe477891c3c98371@travis-tasks-8c9667cc8-754p8.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #745 Status: Errored Duration: 13 mins and 59 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/697965585?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Sun Jun 14 13:57:46 2020 From: builds at travis-ci.org (Travis CI) Date: Sun, 14 Jun 2020 13:57:46 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#746 (master - 2a95153) In-Reply-To: Message-ID: <5ee62cda52b19_13fcceb2eb0881375c0@travis-tasks-5c5fbfd479-r8rsl.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #746 Status: Errored Duration: 14 mins and 4 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/698200775?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Mon Jun 15 13:57:36 2020 From: builds at travis-ci.org (Travis CI) Date: Mon, 15 Jun 2020 13:57:36 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#747 (master - 2a95153) In-Reply-To: Message-ID: <5ee77e501c888_13fb60b4187cc1354c6@travis-tasks-68f486c5d7-v4q5b.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #747 Status: Errored Duration: 13 mins and 31 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/698531970?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Mon Jun 15 17:45:53 2020 From: cfu at redhat.com (Christina Fu) Date: Mon, 15 Jun 2020 10:45:53 -0700 Subject: [Pki-devel] Certificate Transparency SCT signature verification? In-Reply-To: <20200612005818.GD2312208@T470s> References: <20200602023128.GA1932521@T470s> <20200612005818.GD2312208@T470s> Message-ID: Hi Fraser, That sounds good! I just added the following page to document my "quick test" procedure which I use during development: https://www.dogtagpki.org/wiki/PKI_10.9_Certificate_Transparency btw, the verifySCT is currently enabled, but the failure is ignored. However, you could look in the debug log for "verifySCT" to see relevant debug messages. I'll ask Dinesh to add his more comprehensive testing procedure to the page. thanks!! Christina On Thu, Jun 11, 2020 at 5:58 PM Fraser Tweedale wrote: > Hi Christina, > > I will find a day next week to have a close look. Probably Tuesday > or Wednesday. It will help to have test environment setup > documentation, i.e. how to set up a log server to test with, how to > configure Dogtag, etc. If this stuff is already written then you > just need to tell me where to look :) > > Cheers, > Fraser > > On Thu, Jun 11, 2020 at 05:08:25PM -0700, Christina Fu wrote: > > HI Fraser, > > verifySCT still fails. I still think the fact the rfc does not require > the > > signed object to accompany the signature presents undue challenge to the > > party that needs to verify the signature. Although I understand that > this > > is v1, and the issue would not be present in v2 since there will not be > > poison extension ;-/. > > I'd appreciate it if you could find time to take a closer look. > > > > Here is my latest attempt: > > https://github.com/dogtagpki/pki/pull/440 > > Since it's a patch against the latest code, for a full view, it would be > > easier if you just apply the patch and read from "(Certificate > > Transparency)" in > > base/ca/src/com/netscape/ca/CAService.java > > This patch would require JSS change at: > > https://github.com/dogtagpki/jss/pull/575 > > > > Code still requires some refinement but I wish to address the > verification > > issue before cleaning things up. Of course I still let verifySCT returns > > success for now just so people could still play with CT. > > Much appreciated! > > Christina > > > > On Tue, Jun 2, 2020 at 3:05 PM Christina Fu wrote: > > > > > 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_type.length + > > >> issuer_key_hash.length + tbsCert.length + > > >> extensions.length; > > >> > > >> logger.debug(method + " data_len = "+ data_len); > > >> ByteArrayOutputStream ostream = new ByteArrayOutputStream(); > > >> > > >> ostream.write(version); > > >> ostream.write(signature_type); > > >> ostream.write(timestamp); > > >> > > >> ostream.write(entry_type); > > >> ostream.write(issuer_key_hash); > > >> ostream.write(tbsCert); > > >> !! I believe you need to prepend the length of tbsCert as a > > >> THREE-byte length field, because its definition is > > >> `opaque TBSCertificate<1..2^24-1>;' > > >> > > >> ostream.write(extensions); > > >> > > >> byte[] data = ostream.toByteArray(); > > >> > > >> // Now, verify the signature > > >> // Note: this part currently does not work; see method comment > > >> above > > >> > > >> // cfu ToDo: interpret the alg bytes later; hardcode for now > > >> Signature signer = Signature.getInstance("SHA256withEC", > > >> "Mozilla-JSS"); > > >> signer.initVerify(log_pubKey); > > >> signer.update(data); > > >> !! We could call signer.update() multiple times instead of making an > > >> intermediate ByteArrayOutputStream. I do not care about the > > >> performance, just whatever might simplify the routine. > > >> > > >> if (!signer.verify(signature)) { > > >> logger.error(method + "failed to verify SCT signature; > pass > > >> for now"); > > >> // this method is not yet working; Let this pass for now > > >> // return false; > > >> } else { > > >> logger.debug(method + "SCT signature verified > successfully"); > > >> } > > >> logger.debug("verifySCT ends"); > > >> > > >> return true; > > >> } > > >> > > >> > > >> > > >> Cheers, > > >> Fraser > > >> > > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Tue Jun 16 13:59:23 2020 From: builds at travis-ci.org (Travis CI) Date: Tue, 16 Jun 2020 13:59:23 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#748 (master - 2a95153) In-Reply-To: Message-ID: <5ee8d03b54abe_13fae41b1b3ac1723cb@travis-tasks-77456fcfc8-phj67.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #748 Status: Errored Duration: 14 mins and 28 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/698923599?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Tue Jun 16 14:59:48 2020 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 17 Jun 2020 00:59:48 +1000 Subject: [Pki-devel] Certificate Transparency SCT signature verification? In-Reply-To: References: <20200602023128.GA1932521@T470s> <20200612005818.GD2312208@T470s> Message-ID: <20200616145948.GE2312208@T470s> Thanks for the testing notes, Christina. Today I set up a local test CT log server using a container image. I plan to document more thoroughly but rough notes at [1]. Now to the issue I found - I have a commit[2] in a private branch. Hopefully the commit message and comments explain it well enough. Is it the last issue? Not sure yet, I finally got it compiled but haven't run the code yet. Tomorrow's adventure. [1] https://github.com/frasertweedale/notes-redhat/blob/master/ct.rst [2] https://github.com/frasertweedale/pki/tree/fix/ct-verify Cheers, Fraser On Mon, Jun 15, 2020 at 10:45:53AM -0700, Christina Fu wrote: > Hi Fraser, > That sounds good! I just added the following page to document my "quick > test" procedure which I use during development: > https://www.dogtagpki.org/wiki/PKI_10.9_Certificate_Transparency > btw, the verifySCT is currently enabled, but the failure is ignored. > However, you could look in the debug log for "verifySCT" to see relevant > debug messages. > > I'll ask Dinesh to add his more comprehensive testing procedure to the page. > thanks!! > Christina > > On Thu, Jun 11, 2020 at 5:58 PM Fraser Tweedale wrote: > > > Hi Christina, > > > > I will find a day next week to have a close look. Probably Tuesday > > or Wednesday. It will help to have test environment setup > > documentation, i.e. how to set up a log server to test with, how to > > configure Dogtag, etc. If this stuff is already written then you > > just need to tell me where to look :) > > > > Cheers, > > Fraser > > > > On Thu, Jun 11, 2020 at 05:08:25PM -0700, Christina Fu wrote: > > > HI Fraser, > > > verifySCT still fails. I still think the fact the rfc does not require > > the > > > signed object to accompany the signature presents undue challenge to the > > > party that needs to verify the signature. Although I understand that > > this > > > is v1, and the issue would not be present in v2 since there will not be > > > poison extension ;-/. > > > I'd appreciate it if you could find time to take a closer look. > > > > > > Here is my latest attempt: > > > https://github.com/dogtagpki/pki/pull/440 > > > Since it's a patch against the latest code, for a full view, it would be > > > easier if you just apply the patch and read from "(Certificate > > > Transparency)" in > > > base/ca/src/com/netscape/ca/CAService.java > > > This patch would require JSS change at: > > > https://github.com/dogtagpki/jss/pull/575 > > > > > > Code still requires some refinement but I wish to address the > > verification > > > issue before cleaning things up. Of course I still let verifySCT returns > > > success for now just so people could still play with CT. > > > Much appreciated! > > > Christina > > > > > > On Tue, Jun 2, 2020 at 3:05 PM Christina Fu wrote: > > > > > > > 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_type.length + > > > >> issuer_key_hash.length + tbsCert.length + > > > >> extensions.length; > > > >> > > > >> logger.debug(method + " data_len = "+ data_len); > > > >> ByteArrayOutputStream ostream = new ByteArrayOutputStream(); > > > >> > > > >> ostream.write(version); > > > >> ostream.write(signature_type); > > > >> ostream.write(timestamp); > > > >> > > > >> ostream.write(entry_type); > > > >> ostream.write(issuer_key_hash); > > > >> ostream.write(tbsCert); > > > >> !! I believe you need to prepend the length of tbsCert as a > > > >> THREE-byte length field, because its definition is > > > >> `opaque TBSCertificate<1..2^24-1>;' > > > >> > > > >> ostream.write(extensions); > > > >> > > > >> byte[] data = ostream.toByteArray(); > > > >> > > > >> // Now, verify the signature > > > >> // Note: this part currently does not work; see method comment > > > >> above > > > >> > > > >> // cfu ToDo: interpret the alg bytes later; hardcode for now > > > >> Signature signer = Signature.getInstance("SHA256withEC", > > > >> "Mozilla-JSS"); > > > >> signer.initVerify(log_pubKey); > > > >> signer.update(data); > > > >> !! We could call signer.update() multiple times instead of making an > > > >> intermediate ByteArrayOutputStream. I do not care about the > > > >> performance, just whatever might simplify the routine. > > > >> > > > >> if (!signer.verify(signature)) { > > > >> logger.error(method + "failed to verify SCT signature; > > pass > > > >> for now"); > > > >> // this method is not yet working; Let this pass for now > > > >> // return false; > > > >> } else { > > > >> logger.debug(method + "SCT signature verified > > successfully"); > > > >> } > > > >> logger.debug("verifySCT ends"); > > > >> > > > >> return true; > > > >> } > > > >> > > > >> > > > >> > > > >> Cheers, > > > >> Fraser > > > >> > > > >> > > > > From ftweedal at redhat.com Wed Jun 17 02:45:54 2020 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 17 Jun 2020 12:45:54 +1000 Subject: [Pki-devel] Certificate Transparency SCT signature verification? In-Reply-To: <20200616145948.GE2312208@T470s> References: <20200602023128.GA1932521@T470s> <20200612005818.GD2312208@T470s> <20200616145948.GE2312208@T470s> Message-ID: <20200617024554.GF2312208@T470s> On Wed, Jun 17, 2020 at 12:59:57AM +1000, Fraser Tweedale wrote: > Thanks for the testing notes, Christina. > > Today I set up a local test CT log server using a container image. > I plan to document more thoroughly but rough notes at [1]. > > Now to the issue I found - I have a commit[2] in a private branch. > Hopefully the commit message and comments explain it well enough. > > Is it the last issue? Not sure yet, I finally got it compiled but > haven't run the code yet. Tomorrow's adventure. > > [1] https://github.com/frasertweedale/notes-redhat/blob/master/ct.rst > [2] https://github.com/frasertweedale/pki/tree/fix/ct-verify > > Cheers, > Fraser > I went down the garden path on this one. It turns out that JSS/NSS *does* use the DER-encoded ECDSA-Sig-Value as the signature format. (I wrote a small test program to check this). So most of the code I wrote yesterday is wrong. Analysis continues. Thanks, Fraser > On Mon, Jun 15, 2020 at 10:45:53AM -0700, Christina Fu wrote: > > Hi Fraser, > > That sounds good! I just added the following page to document my "quick > > test" procedure which I use during development: > > https://www.dogtagpki.org/wiki/PKI_10.9_Certificate_Transparency > > btw, the verifySCT is currently enabled, but the failure is ignored. > > However, you could look in the debug log for "verifySCT" to see relevant > > debug messages. > > > > I'll ask Dinesh to add his more comprehensive testing procedure to the page. > > thanks!! > > Christina > > > > On Thu, Jun 11, 2020 at 5:58 PM Fraser Tweedale wrote: > > > > > Hi Christina, > > > > > > I will find a day next week to have a close look. Probably Tuesday > > > or Wednesday. It will help to have test environment setup > > > documentation, i.e. how to set up a log server to test with, how to > > > configure Dogtag, etc. If this stuff is already written then you > > > just need to tell me where to look :) > > > > > > Cheers, > > > Fraser > > > > > > On Thu, Jun 11, 2020 at 05:08:25PM -0700, Christina Fu wrote: > > > > HI Fraser, > > > > verifySCT still fails. I still think the fact the rfc does not require > > > the > > > > signed object to accompany the signature presents undue challenge to the > > > > party that needs to verify the signature. Although I understand that > > > this > > > > is v1, and the issue would not be present in v2 since there will not be > > > > poison extension ;-/. > > > > I'd appreciate it if you could find time to take a closer look. > > > > > > > > Here is my latest attempt: > > > > https://github.com/dogtagpki/pki/pull/440 > > > > Since it's a patch against the latest code, for a full view, it would be > > > > easier if you just apply the patch and read from "(Certificate > > > > Transparency)" in > > > > base/ca/src/com/netscape/ca/CAService.java > > > > This patch would require JSS change at: > > > > https://github.com/dogtagpki/jss/pull/575 > > > > > > > > Code still requires some refinement but I wish to address the > > > verification > > > > issue before cleaning things up. Of course I still let verifySCT returns > > > > success for now just so people could still play with CT. > > > > Much appreciated! > > > > Christina > > > > > > > > On Tue, Jun 2, 2020 at 3:05 PM Christina Fu wrote: > > > > > > > > > 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_type.length + > > > > >> issuer_key_hash.length + tbsCert.length + > > > > >> extensions.length; > > > > >> > > > > >> logger.debug(method + " data_len = "+ data_len); > > > > >> ByteArrayOutputStream ostream = new ByteArrayOutputStream(); > > > > >> > > > > >> ostream.write(version); > > > > >> ostream.write(signature_type); > > > > >> ostream.write(timestamp); > > > > >> > > > > >> ostream.write(entry_type); > > > > >> ostream.write(issuer_key_hash); > > > > >> ostream.write(tbsCert); > > > > >> !! I believe you need to prepend the length of tbsCert as a > > > > >> THREE-byte length field, because its definition is > > > > >> `opaque TBSCertificate<1..2^24-1>;' > > > > >> > > > > >> ostream.write(extensions); > > > > >> > > > > >> byte[] data = ostream.toByteArray(); > > > > >> > > > > >> // Now, verify the signature > > > > >> // Note: this part currently does not work; see method comment > > > > >> above > > > > >> > > > > >> // cfu ToDo: interpret the alg bytes later; hardcode for now > > > > >> Signature signer = Signature.getInstance("SHA256withEC", > > > > >> "Mozilla-JSS"); > > > > >> signer.initVerify(log_pubKey); > > > > >> signer.update(data); > > > > >> !! We could call signer.update() multiple times instead of making an > > > > >> intermediate ByteArrayOutputStream. I do not care about the > > > > >> performance, just whatever might simplify the routine. > > > > >> > > > > >> if (!signer.verify(signature)) { > > > > >> logger.error(method + "failed to verify SCT signature; > > > pass > > > > >> for now"); > > > > >> // this method is not yet working; Let this pass for now > > > > >> // return false; > > > > >> } else { > > > > >> logger.debug(method + "SCT signature verified > > > successfully"); > > > > >> } > > > > >> logger.debug("verifySCT ends"); > > > > >> > > > > >> return true; > > > > >> } > > > > >> > > > > >> > > > > >> > > > > >> Cheers, > > > > >> Fraser > > > > >> > > > > >> > > > > > > From builds at travis-ci.org Wed Jun 17 14:05:42 2020 From: builds at travis-ci.org (Travis CI) Date: Wed, 17 Jun 2020 14:05:42 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#749 (master - 2a95153) In-Reply-To: Message-ID: <5eea2336800e3_13fa5b1d9cb78162923@travis-tasks-7878657df5-66x9b.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #749 Status: Errored Duration: 19 mins and 56 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/699312154?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Thu Jun 18 14:01:02 2020 From: builds at travis-ci.org (Travis CI) Date: Thu, 18 Jun 2020 14:01:02 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#750 (master - 2a95153) In-Reply-To: Message-ID: <5eeb739c23e9f_13fda33e1c11495039@travis-tasks-8448647545-nc2sp.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #750 Status: Errored Duration: 14 mins and 25 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/699698943?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Fri Jun 19 13:48:39 2020 From: builds at travis-ci.org (Travis CI) Date: Fri, 19 Jun 2020 13:48:39 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#751 (master - 2a95153) In-Reply-To: Message-ID: <5eecc2371d61c_13f9bb1d98f3c1131d2@travis-tasks-858b4bd74-9chn9.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #751 Status: Errored Duration: 1 min and 41 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/700073033?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Sat Jun 20 14:02:28 2020 From: builds at travis-ci.org (Travis CI) Date: Sat, 20 Jun 2020 14:02:28 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#752 (master - 2a95153) In-Reply-To: Message-ID: <5eee16f29a563_13fe0ddcecce8145093@travis-tasks-7c54c84f69-tbsqc.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #752 Status: Errored Duration: 14 mins and 28 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/700350430?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Sun Jun 21 14:02:19 2020 From: builds at travis-ci.org (Travis CI) Date: Sun, 21 Jun 2020 14:02:19 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#753 (master - 2a95153) In-Reply-To: Message-ID: <5eef686abcc67_13ff2e6b9d4f8609c8@travis-tasks-54d99c94-c22pj.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #753 Status: Errored Duration: 13 mins and 23 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/700569508?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Mon Jun 22 14:03:59 2020 From: builds at travis-ci.org (Travis CI) Date: Mon, 22 Jun 2020 14:03:59 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#754 (master - 2a95153) In-Reply-To: Message-ID: <5ef0ba4ebee70_13fda0de1ac041493a7@travis-tasks-d9444c694-h52s8.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #754 Status: Errored Duration: 14 mins and 51 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/700885177?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmoluguw at redhat.com Tue Jun 23 00:07:34 2020 From: dmoluguw at redhat.com (Dinesh Prasanth Moluguwan Krishnamoorthy) Date: Mon, 22 Jun 2020 20:07:34 -0400 Subject: [Pki-devel] Questions regarding addition of our own Cockpit module In-Reply-To: <5e80bf62252a994ab34cc35b904a8f8e7355f9ba.camel@redhat.com> References: <20200605091359.GC1572@piware.de> <5e80bf62252a994ab34cc35b904a8f8e7355f9ba.camel@redhat.com> Message-ID: Hello team, We discussed the possibility of using Cockpit in Dogtag PKI with our whole team (including Devs, QEs, CEE, POs and PMs). It seems that the proposed solutions by Martin and Simon seem to require major architectural changes to Dogtag PKI product itself, which, as Fraser pointed out, circles back to the requirement of full-fledged IDM environment. So, as of now, we have decided to use the PatternFly and ReactJS directly to design our web interface (to stay as close to the cockpit design as possible). Regards, --Dinesh On Mon, Jun 8, 2020 at 8:36 AM Simon Kobyda wrote: > On Fri, 2020-06-05 at 11:13 +0200, Martin Pitt wrote: > > Hello Dinesh, > > > > Dinesh Prasanth Moluguwan Krishnamoorthy [2020-06-03 20:17 -0400]: > > > I?m part of Dogtag PKI open-source project [1]. Our team strives to > > > provide > > > enterprise-class open-source Public Key Infrastructure (PKI) [2]. > > > > FTR, Simon Kobyda (CCed) is working on a Cockpit page for managing > > certificates > > [1]. There may be some overlap here, so perhaps you can meet and > > exchange some > > ideas. > > > > This sounds interesting. Is this module of yours (as I guess from email > subject) mainly oriented for Smart Cards? What use cases does it look > to solve? > The module I'm working on is so far oriented about functionalities > provided by certmonger. It provides UI to functionalities such > requesting and tracking certificate, importing preexisting certificate > & key and renewing and resubmiting it. > It can request certificate from CA configured to certmonger like IPA. > The module so far doesn't have hard set limitations so it can be > expanded (for example outside of scope of just certmonger) if we find > some overlap. > > > > 1. According to [3] Cockpit seems to require the host to join the > > > IdM > > > domain in order to authenticate PKI users into Cockpit using client > > > cert > > > auth. Is it possible to use client cert auth without joining a > > > domain? Will > > > that require major changes in Cockpit? > > > > To be precise, Cockpit calls sssd to map a given certificate from TLS > > client > > cert auth to a user [2], with FindByCertificate(). > > > > This doesn't *inherently* require IdM. It's just (1) the only way how > > I got > > that sssd lookup mechanism to actually work, and (2) it generally > > makes sense > > to maintain this cert?user mapping centrally. > > > > Allegedly it is possible to configure sssd to do this mapping with > > local > > certificates [2]. I played around with that a few weeks ago, as that > > would be a > > very interesting use case, but I didn't manage to get it working -- > > apparently > > the FindByCertificate() sssd method only works with IdM, not with > > these local > > certificates. Making that work may be an interesting project. > > > > So this all hinges on sssd -- if that can map a certificate, you can > > log into > > Cockpit. Cockpit itself would need no modifications for backends > > other than > > FreeIPA. > > > > > 2. Suppose the user has been authenticated into Cockpit using a > > > client cert > > > as described in #1, is it possible for Cockpit to use the same > > > client > > > certificate auth to access PKI server? Or do we need to use a > > > different > > > auth mechanism? > > > > As Fraser already pointed out, cockpit's web server doesn't have the > > private > > key that the browser end was using to authenticate, so that doesn't > > work. > > > > Does it have to be TLS client cert auth, or would kerberos work as > > well? We > > are currently designing that so that we can "forward" (or rather, > > convert/transcend) the initial client cert auth to a kerberos ticket, > > so that > > cockpit can use that to further authenticate to services like sudo or > > ssh. > > Structurally that's very similar, but it would require the PKI server > > to accept > > delegated (S4U) kerberos tickets. > > > > Martin > > > > > > [1] https://github.com/skobyda/cockpit-certificates > > [2] > > > https://docs.pagure.org/SSSD.sssd/design_pages/lookup_users_by_certificate.html > > [3] > > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_authselect_on_a_red_hat_enterprise_linux_host/configuring-and-importing-local-certificates-to-a-smart-card_using_authselect_on_a_red_hat_enterprise_linux_host > > [4] https://projects.engineering.redhat.com/browse/COCKPIT-542 -- RH > > internal only > > > _______________________________________________ > cockpit-devel mailing list -- cockpit-devel at lists.fedorahosted.org > To unsubscribe send an email to cockpit-devel-leave at lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/cockpit-devel at lists.fedorahosted.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Tue Jun 23 13:51:04 2020 From: builds at travis-ci.org (Travis CI) Date: Tue, 23 Jun 2020 13:51:04 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#755 (master - 2a95153) In-Reply-To: Message-ID: <5ef208c5b37d2_13faaffbf2748772ea@travis-tasks-847569c697-x2sgm.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #755 Status: Errored Duration: 1 min and 27 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/701272031?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Wed Jun 24 14:46:24 2020 From: builds at travis-ci.org (Travis CI) Date: Wed, 24 Jun 2020 14:46:24 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#756 (master - 2a95153) In-Reply-To: Message-ID: <5ef367406369a_13fd66d516b3821811f@travis-tasks-7f8fccf46b-x6jtb.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #756 Status: Errored Duration: 50 mins and 2 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/701655776?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Thu Jun 25 14:04:52 2020 From: builds at travis-ci.org (Travis CI) Date: Thu, 25 Jun 2020 14:04:52 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#757 (master - 2a95153) In-Reply-To: Message-ID: <5ef4af03eb8e6_13fb06276205817629c@travis-tasks-5968dd68fd-c85n5.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #757 Status: Errored Duration: 14 mins and 34 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/702032723?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Fri Jun 26 14:05:38 2020 From: builds at travis-ci.org (Travis CI) Date: Fri, 26 Jun 2020 14:05:38 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#758 (master - 2a95153) In-Reply-To: Message-ID: <5ef600b2b550_13fcfe96ae278132272@travis-tasks-f745448f5-bgmwl.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #758 Status: Errored Duration: 14 mins and 54 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/702377716?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Sat Jun 27 14:05:18 2020 From: builds at travis-ci.org (Travis CI) Date: Sat, 27 Jun 2020 14:05:18 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#759 (master - 2a95153) In-Reply-To: Message-ID: <5ef7521e1ef10_13fec79da2cd0206751@travis-tasks-5f5d77996b-grh7f.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #759 Status: Errored Duration: 14 mins and 6 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/702650499?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Sun Jun 28 14:05:58 2020 From: builds at travis-ci.org (Travis CI) Date: Sun, 28 Jun 2020 14:05:58 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#760 (master - 2a95153) In-Reply-To: Message-ID: <5ef8a3c5c514e_13f929b4b0088159844@travis-tasks-7d8f4bc4d8-p4q5l.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #760 Status: Errored Duration: 14 mins and 20 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/702875965?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Mon Jun 29 14:08:08 2020 From: builds at travis-ci.org (Travis CI) Date: Mon, 29 Jun 2020 14:08:08 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#761 (master - 2a95153) In-Reply-To: Message-ID: <5ef9f5c69b189_13fd96603bdec2766dd@travis-tasks-6b8fdd47bd-h72pm.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #761 Status: Errored Duration: 15 mins and 57 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/703152112?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Mon Jun 29 20:12:12 2020 From: edewata at redhat.com (Endi Dewata) Date: Mon, 29 Jun 2020 15:12:12 -0500 Subject: [Pki-devel] ACME Support: Error issuing certificate In-Reply-To: References: <461128887.74968333.1588722549092.JavaMail.zimbra@redhat.com> <1151718650.80906954.1591069353298.JavaMail.zimbra@redhat.com> Message-ID: Hi Jesse, I'd like to let you know that we have created a PKI ACME container that can be deployed much more easily on Podman or OpenShift: https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Deploying_ACME_on_Podman.md https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Deploying_ACME_on_OpenShift.md By default the container will generate a self-signed CA signing certificate and use an ephemeral database, but you can configure it with a permanent certificate and persistent database. We've also set up a demo instance that you can try: https://acme.demo.dogtagpki.org/acme/directory Just let me know if you have any questions. Thanks! -- Endi S. Dewata On Tue, Jun 2, 2020 at 8:35 AM Jesse L Van hill wrote: > 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 jlvanhil at us.ibm.com > > [image: Inactive hide details for Endi Sukma Dewata ---06/01/2020 10:42:43 > PM-------- Original Message ----- > > Hi -]Endi Sukma Dewata > ---06/01/2020 10:42:43 PM-------- Original Message ----- > > Hi - > > From: Endi Sukma Dewata > To: Jesse L Van hill > Cc: pki-devel at redhat.com > Date: 06/01/2020 10:42 PM > Subject: [EXTERNAL] Re: [Pki-devel] ACME Support: Error issuing > certificate > ------------------------------ > Hi Jesse, > > I was just wondering if you managed to test against the ACME server. > FYI, we're working on adding an embedded CA into the ACME server so > it can be containerized more easily without dependency on a separate > CA. Hopefully we will have something usable by the end of the month. > > -- > Endi S. Dewata > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From jlvanhil at us.ibm.com Mon Jun 29 20:43:50 2020 From: jlvanhil at us.ibm.com (Jesse L Van hill) Date: Mon, 29 Jun 2020 15:43:50 -0500 Subject: [Pki-devel] ACME Support: Error issuing certificate In-Reply-To: References: <461128887.74968333.1588722549092.JavaMail.zimbra@redhat.com> <1151718650.80906954.1591069353298.JavaMail.zimbra@redhat.com> Message-ID: Hi Endi - Thanks for letting me know about this. We have testing on PKI on our list of tasks as we finish up working on our ACME client. I will let you know what we find when we test. Jesse Van Hill Websphere Identity Management Architect & Dev Lead WebSphere Application Server & Open Liberty https://openliberty.io/ 507-513-6234 jlvanhil at us.ibm.com From: Endi Dewata To: Jesse L Van hill Cc: pki-devel at redhat.com Date: 06/29/2020 03:37 PM Subject: [EXTERNAL] Re: [Pki-devel] ACME Support: Error issuing certificate Hi Jesse, I'd like to let you know that we have created a PKI ACME container that can be deployed much more easily on Podman or OpenShift: https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Deploying_ACME_on_Podman.md https://github.com/dogtagpki/pki/blob/master/docs/installation/acme/Deploying_ACME_on_OpenShift.md By default the container will generate a self-signed CA signing certificate and use an ephemeral database, but you can configure it with a permanent certificate and persistent database. We've also set up a demo instance that you can try: https://acme.demo.dogtagpki.org/acme/directory Just let me know if you have any questions. Thanks! -- Endi S. Dewata On Tue, Jun 2, 2020 at 8:35 AM Jesse L Van hill wrote: 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 jlvanhil at us.ibm.com Inactive hide details for Endi Sukma Dewata ---06/01/2020 10:42:43 PM-------- Original Message ----- > > Hi -Endi Sukma Dewata ---06/01/2020 10:42:43 PM-------- Original Message ----- > > Hi - From: Endi Sukma Dewata To: Jesse L Van hill Cc: pki-devel at redhat.com Date: 06/01/2020 10:42 PM Subject: [EXTERNAL] Re: [Pki-devel] ACME Support: Error issuing certificate Hi Jesse, I was just wondering if you managed to test against the ACME server. FYI, we're working on adding an embedded CA into the ACME server so it can be containerized more easily without dependency on a separate CA. Hopefully we will have something usable by the end of the month. -- Endi S. Dewata -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From builds at travis-ci.org Tue Jun 30 14:06:50 2020 From: builds at travis-ci.org (Travis CI) Date: Tue, 30 Jun 2020 14:06:50 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#762 (master - 2a95153) In-Reply-To: Message-ID: <5efb46fa39c97_13ffdce7b28dc23577@travis-tasks-6bd9d95f6c-xk92g.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #762 Status: Errored Duration: 13 mins and 47 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/703532606?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. -------------- next part -------------- An HTML attachment was scrubbed... URL: