From builds at travis-ci.org Sun Mar 1 08:17:36 2020 From: builds at travis-ci.org (Travis CI) Date: Sun, 01 Mar 2020 08:17:36 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#641 (master - 1cec227) In-Reply-To: Message-ID: <5e5b6fa0327f_43f83edb131f814524c@50ec6484-4740-4115-83c1-1a8ab6f983d6.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #641 Status: Errored Duration: 14 mins and 36 secs Commit: 1cec227 (master) Author: Dinesh Prasanth M K Message: Update nightly CI matrix Signed-off-by: Dinesh Prasanth M K View the changeset: https://github.com/dogtagpki/pki-nightly-test/compare/7d8d351192b013988a4667ee2dd16892d47291ff...1cec22733aad03cad1e589a08281f4a2db79ec90 View the full build log and details: https://travis-ci.org/dogtagpki/pki-nightly-test/builds/656871335?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 Mar 2 08:19:02 2020 From: builds at travis-ci.org (Travis CI) Date: Mon, 02 Mar 2020 08:19:02 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#642 (master - 1cec227) In-Reply-To: Message-ID: <5e5cc176a4896_43fa3de91244c110811@7459879f-b6bc-46f1-b252-c5423d7835c7.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #642 Status: Errored Duration: 15 mins and 7 secs Commit: 1cec227 (master) Author: Dinesh Prasanth M K Message: Update nightly CI matrix Signed-off-by: Dinesh Prasanth M K View the changeset: https://github.com/dogtagpki/pki-nightly-test/compare/7d8d351192b013988a4667ee2dd16892d47291ff...1cec22733aad03cad1e589a08281f4a2db79ec90 View the full build log and details: https://travis-ci.org/dogtagpki/pki-nightly-test/builds/657178181?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 Mar 3 08:19:40 2020 From: builds at travis-ci.org (Travis CI) Date: Tue, 03 Mar 2020 08:19:40 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#643 (master - 1cec227) In-Reply-To: Message-ID: <5e5e131a74d9d_43fa825d12a60859c8@766a85f4-637c-47e0-b3ca-90605cac3f18.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #643 Status: Errored Duration: 15 mins and 23 secs Commit: 1cec227 (master) Author: Dinesh Prasanth M K Message: Update nightly CI matrix Signed-off-by: Dinesh Prasanth M K View the changeset: https://github.com/dogtagpki/pki-nightly-test/compare/7d8d351192b013988a4667ee2dd16892d47291ff...1cec22733aad03cad1e589a08281f4a2db79ec90 View the full build log and details: https://travis-ci.org/dogtagpki/pki-nightly-test/builds/657637996?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 Mar 4 08:21:18 2020 From: builds at travis-ci.org (Travis CI) Date: Wed, 04 Mar 2020 08:21:18 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#644 (master - 1cec227) In-Reply-To: Message-ID: <5e5f64fe84c9d_43f7fc57a4dcc126919@ac5bcc85-708f-4eae-8830-88ae9e75db4f.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #644 Status: Errored Duration: 16 mins and 44 secs Commit: 1cec227 (master) Author: Dinesh Prasanth M K Message: Update nightly CI matrix Signed-off-by: Dinesh Prasanth M K View the changeset: https://github.com/dogtagpki/pki-nightly-test/compare/7d8d351192b013988a4667ee2dd16892d47291ff...1cec22733aad03cad1e589a08281f4a2db79ec90 View the full build log and details: https://travis-ci.org/dogtagpki/pki-nightly-test/builds/658102812?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 Mar 5 08:20:49 2020 From: builds at travis-ci.org (Travis CI) Date: Thu, 05 Mar 2020 08:20:49 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#645 (master - 1cec227) In-Reply-To: Message-ID: <5e60b661d1f5_43fd42458cb3073448@103a718f-b1bd-4f27-99a9-dff097db2b67.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #645 Status: Errored Duration: 15 mins and 9 secs Commit: 1cec227 (master) Author: Dinesh Prasanth M K Message: Update nightly CI matrix Signed-off-by: Dinesh Prasanth M K View the changeset: https://github.com/dogtagpki/pki-nightly-test/compare/7d8d351192b013988a4667ee2dd16892d47291ff...1cec22733aad03cad1e589a08281f4a2db79ec90 View the full build log and details: https://travis-ci.org/dogtagpki/pki-nightly-test/builds/658575907?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 Mar 6 08:21:58 2020 From: builds at travis-ci.org (Travis CI) Date: Fri, 06 Mar 2020 08:21:58 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#646 (master - 1cec227) In-Reply-To: Message-ID: <5e62082638061_43fc9a77fbc681277ab@573b6746-c475-4f13-9f0f-0b9d54550263.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #646 Status: Errored Duration: 15 mins and 27 secs Commit: 1cec227 (master) Author: Dinesh Prasanth M K Message: Update nightly CI matrix Signed-off-by: Dinesh Prasanth M K View the changeset: https://github.com/dogtagpki/pki-nightly-test/compare/7d8d351192b013988a4667ee2dd16892d47291ff...1cec22733aad03cad1e589a08281f4a2db79ec90 View the full build log and details: https://travis-ci.org/dogtagpki/pki-nightly-test/builds/659045421?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 Thu Mar 5 18:26:15 2020 From: dmoluguw at redhat.com (Dinesh Prasanth Moluguwan Krishnamoorthy) Date: Thu, 05 Mar 2020 23:56:15 +0530 Subject: [Pki-devel] PKI 10.8.3 is available upstream! Message-ID: <4a207e97b1c46ce926bb3e1729b24ea415ff4cbc.camel@redhat.com> Hello everyone, PKI 10.8.3 is now available upstream: https://github.com/dogtagpki/pki/releases/tag/v10.8.3 Fedora builds have been made and submitted to Bodhi for testing: F30: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6ce7aa6d82 F31: https://bodhi.fedoraproject.org/updates/FEDORA-2020-86a3576a8a F32: https://bodhi.fedoraproject.org/updates/FEDORA-2020-5f05c3ec46 Fedora Rawhide builds are also available. We welcome testing and feedback for the update. Regards, PKI Team -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From builds at travis-ci.org Fri Mar 6 16:45:35 2020 From: builds at travis-ci.org (Travis CI) Date: Fri, 06 Mar 2020 16:45:35 +0000 Subject: [Pki-devel] Broken: SilleBille/pki-nightly-test#54 (master - 2a95153) In-Reply-To: Message-ID: <5e627e2f74264_43fc51df0bb54163932@59c88d26-481b-4a15-be62-741390fcfabe.mail> Build Update for SilleBille/pki-nightly-test ------------------------------------- Build: #54 Status: Broken Duration: 12 mins and 13 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/SilleBille/pki-nightly-test/compare/bb61a08667de...2a9515310223 View the full build log and details: https://travis-ci.org/SilleBille/pki-nightly-test/builds/659226759?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the SilleBille/pki-nightly-test repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=20442787&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 Mar 7 08:21:52 2020 From: builds at travis-ci.org (Travis CI) Date: Sat, 07 Mar 2020 08:21:52 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#647 (master - 1cec227) In-Reply-To: Message-ID: <5e6359a0894d0_43fb622c1b908623f4@064c30a6-d355-44b6-b9af-55bf7ad878e4.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #647 Status: Errored Duration: 15 mins and 11 secs Commit: 1cec227 (master) Author: Dinesh Prasanth M K Message: Update nightly CI matrix Signed-off-by: Dinesh Prasanth M K View the changeset: https://github.com/dogtagpki/pki-nightly-test/compare/7d8d351192b013988a4667ee2dd16892d47291ff...1cec22733aad03cad1e589a08281f4a2db79ec90 View the full build log and details: https://travis-ci.org/dogtagpki/pki-nightly-test/builds/659467597?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 Mar 7 09:39:48 2020 From: builds at travis-ci.org (Travis CI) Date: Sat, 07 Mar 2020 09:39:48 +0000 Subject: [Pki-devel] Failed: dogtagpki/pki-nightly-test#648 (master - 2a95153) In-Reply-To: Message-ID: <5e636be46818d_43fb16b016024606cd@2ca6f76c-33df-4bfd-b32c-e53835485f0d.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #648 Status: Failed Duration: 23 mins and 17 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/1cec22733aad...2a9515310223 View the full build log and details: https://travis-ci.org/dogtagpki/pki-nightly-test/builds/659478872?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 Mar 8 08:30:52 2020 From: builds at travis-ci.org (Travis CI) Date: Sun, 08 Mar 2020 08:30:52 +0000 Subject: [Pki-devel] [CRON] Still Failing: dogtagpki/pki-nightly-test#649 (master - 2a95153) In-Reply-To: Message-ID: <5e64ad3b50068_43f89c0c1f064671fc@89c85480-99ea-4d18-90a3-9f87c9248fff.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #649 Status: Still Failing Duration: 23 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/dogtagpki/pki-nightly-test/builds/659746660?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 Mar 9 08:32:18 2020 From: builds at travis-ci.org (Travis CI) Date: Mon, 09 Mar 2020 08:32:18 +0000 Subject: [Pki-devel] [CRON] Still Failing: dogtagpki/pki-nightly-test#650 (master - 2a95153) In-Reply-To: Message-ID: <5e65ff1227dd5_43ff7a4295e7452156@f3602277-0129-45e3-b96a-10a7c1746f03.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #650 Status: Still Failing Duration: 24 mins and 29 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/dogtagpki/pki-nightly-test/builds/660034892?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 Mar 9 11:07:15 2020 From: builds at travis-ci.org (Travis CI) Date: Mon, 09 Mar 2020 11:07:15 +0000 Subject: [Pki-devel] [CRON] Still Failing: dogtagpki/pki-nightly-test#650 (master - 2a95153) In-Reply-To: Message-ID: <5e662362d7f3e_43fa83eff18bc1432ef@722a7870-35af-4783-8211-8b4772b65e12.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #650 Status: Still Failing Duration: 9 mins and 30 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/dogtagpki/pki-nightly-test/builds/660034892?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 Mar 10 08:32:46 2020 From: builds at travis-ci.org (Travis CI) Date: Tue, 10 Mar 2020 08:32:46 +0000 Subject: [Pki-devel] [CRON] Still Failing: dogtagpki/pki-nightly-test#651 (master - 2a95153) In-Reply-To: Message-ID: <5e6750adc12c1_43f9b559930101433ee@a9519123-fb1b-4e50-8d77-0b76fbc34ef7.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #651 Status: Still Failing Duration: 24 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/dogtagpki/pki-nightly-test/builds/660512674?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 Mar 11 08:34:19 2020 From: builds at travis-ci.org (Travis CI) Date: Wed, 11 Mar 2020 08:34:19 +0000 Subject: [Pki-devel] [CRON] Still Failing: dogtagpki/pki-nightly-test#652 (master - 2a95153) In-Reply-To: Message-ID: <5e68a28ae86b6_43f8aac50a9449224c@e13bd48c-4c12-4280-a471-c68957e0cb66.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #652 Status: Still Failing Duration: 25 mins and 13 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/dogtagpki/pki-nightly-test/builds/660969337?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 Mar 12 08:39:30 2020 From: builds at travis-ci.org (Travis CI) Date: Thu, 12 Mar 2020 08:39:30 +0000 Subject: [Pki-devel] [CRON] Still Failing: dogtagpki/pki-nightly-test#653 (master - 2a95153) In-Reply-To: Message-ID: <5e69f54186609_43fe170813b48106841@77b819dd-5c7b-4c0a-af25-6adee04ed059.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #653 Status: Still Failing Duration: 29 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/661423180?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 Mar 12 23:33:49 2020 From: builds at travis-ci.org (Travis CI) Date: Thu, 12 Mar 2020 23:33:49 +0000 Subject: [Pki-devel] [CRON] Canceled: dogtagpki/pki-nightly-test#653 (master - 2a95153) In-Reply-To: Message-ID: <5e6ac6dcc2923_43fbedcff04a8108260@3ce18dfb-31bb-49ab-8d34-96f56133c1aa.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #653 Status: Canceled Duration: 15 mins and 10 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/661423180?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 Mar 13 08:41:13 2020 From: builds at travis-ci.org (Travis CI) Date: Fri, 13 Mar 2020 08:41:13 +0000 Subject: [Pki-devel] [CRON] Failed: dogtagpki/pki-nightly-test#654 (master - 2a95153) In-Reply-To: Message-ID: <5e6b472953c5b_43fbedb608fcc1920c8@3ce18dfb-31bb-49ab-8d34-96f56133c1aa.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #654 Status: Failed Duration: 31 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/661864032?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 Mar 14 08:55:24 2020 From: builds at travis-ci.org (Travis CI) Date: Sat, 14 Mar 2020 08:55:24 +0000 Subject: [Pki-devel] [CRON] Fixed: dogtagpki/pki-nightly-test#655 (master - 2a95153) In-Reply-To: Message-ID: <5e6c9bfc75a78_43fb382d910a012376b@e33a1f5d-740b-489c-8d9b-327eef1d1320.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #655 Status: Fixed Duration: 30 mins and 10 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/662325041?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 Mar 15 08:31:17 2020 From: builds at travis-ci.org (Travis CI) Date: Sun, 15 Mar 2020 08:31:17 +0000 Subject: [Pki-devel] [CRON] Broken: dogtagpki/pki-nightly-test#656 (master - 2a95153) In-Reply-To: Message-ID: <5e6de7d51676e_43fa6235a4e94295bf@8b382a49-9e84-46eb-ad3d-d72d38c21cb0.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #656 Status: Broken Duration: 20 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/662637285?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 Mar 16 09:01:56 2020 From: builds at travis-ci.org (Travis CI) Date: Mon, 16 Mar 2020 09:01:56 +0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#657 (master - 2a95153) In-Reply-To: Message-ID: <5e6f40841050c_43fef114a0f8412029b@cb59c125-6895-4432-ab4c-8462ec3c38d8.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #657 Status: Errored Duration: 50 mins and 0 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/662961175?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 Mar 16 12:57:05 2020 From: builds at travis-ci.org (Travis CI) Date: Mon, 16 Mar 2020 12:57:05 -0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#637 (master - 1cec227) In-Reply-To: Message-ID: <5e5629d29cd2_43fe91989514c10154b@8884ecad-4724-4674-848f-93c1a17118e9.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #637 Status: Errored Duration: 17 mins and 41 secs Commit: 1cec227 (master) Author: Dinesh Prasanth M K Message: Update nightly CI matrix Signed-off-by: Dinesh Prasanth M K View the changeset: https://github.com/dogtagpki/pki-nightly-test/compare/7d8d351192b013988a4667ee2dd16892d47291ff...1cec22733aad03cad1e589a08281f4a2db79ec90 View the full build log and details: https://travis-ci.org/dogtagpki/pki-nightly-test/builds/655241700?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 Mar 16 14:07:23 2020 From: builds at travis-ci.org (Travis CI) Date: Mon, 16 Mar 2020 14:07:23 -0000 Subject: [Pki-devel] [CRON] Errored: dogtagpki/pki-nightly-test#639 (master - 1cec227) In-Reply-To: Message-ID: <5e58cc728b0dd_43fcc4d48d010122548@efa60485-fa96-42b5-8a4e-d36cf7960f4e.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #639 Status: Errored Duration: 15 mins and 40 secs Commit: 1cec227 (master) Author: Dinesh Prasanth M K Message: Update nightly CI matrix Signed-off-by: Dinesh Prasanth M K View the changeset: https://github.com/dogtagpki/pki-nightly-test/compare/7d8d351192b013988a4667ee2dd16892d47291ff...1cec22733aad03cad1e589a08281f4a2db79ec90 View the full build log and details: https://travis-ci.org/dogtagpki/pki-nightly-test/builds/656146346?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 Mar 17 06:38:38 2020 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 17 Mar 2020 16:38:38 +1000 Subject: [Pki-devel] ACME certificate IDs Message-ID: <20200317063838.GU251527@T470s> Hi Endi, Just want to quickly discuss certificate IDs. Currently on ACMEBackend interface we have public BigInteger issueCertificate(String csr); I think this is a bit of a problem. e.g. Dogtag currently supports multiple issuers (LWCAs). It is incidental that serial numbers do not collide. This might not hold for other backends. Yet we need the certificate ID to uniquely identify the certificate, so that we can retrieve it, revoke it, etc. I suggest changing the return value to a string (which is how it gets stored in the ACMEOrder object anyway). I'd further suggest that by convention, where possible, the string be a representation of issuer+serial, which is a bit nicer for humans looking at the stored objects than a base64url-encoded big-endian bigint. What do you think? Cheers, Fraser From builds at travis-ci.org Tue Mar 17 08:41:34 2020 From: builds at travis-ci.org (Travis CI) Date: Tue, 17 Mar 2020 08:41:34 +0000 Subject: [Pki-devel] [CRON] Failed: dogtagpki/pki-nightly-test#658 (master - 2a95153) In-Reply-To: Message-ID: <5e708d3e55575_43fd364096f38997d9@ebf802c3-9d48-42b0-b522-7a52684ed56d.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #658 Status: Failed Duration: 28 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/663397385?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 Tue Mar 17 21:04:59 2020 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 17 Mar 2020 17:04:59 -0400 (EDT) Subject: [Pki-devel] ACME certificate IDs In-Reply-To: <20200317063838.GU251527@T470s> References: <20200317063838.GU251527@T470s> Message-ID: <1638034160.37904670.1584479099220.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Endi, > > Just want to quickly discuss certificate IDs. > > Currently on ACMEBackend interface we have > > public BigInteger issueCertificate(String csr); > > I think this is a bit of a problem. e.g. Dogtag currently supports > multiple issuers (LWCAs). It is incidental that serial numbers do > not collide. This might not hold for other backends. Yet we need > the certificate ID to uniquely identify the certificate, so that we > can retrieve it, revoke it, etc. > > I suggest changing the return value to a string (which is how it > gets stored in the ACMEOrder object anyway). > > I'd further suggest that by convention, where possible, the string > be a representation of issuer+serial, which is a bit nicer for > humans looking at the stored objects than a base64url-encoded > big-endian bigint. > > What do you think? > > Cheers, > Fraser Hi Fraser, I agree there is a problem, but I'm not sure about using issuer+serial as certificate ID. What do we use as "issuer", is it the issuer DN or the authority ID? Is issuer DN unique enough? How do we join with the serial number? What format do we use for serial number? What if we need to add another field in the future? It seems there's going to be many questions/issues with this solution. How about this instead? 1. Change issueCertificate() to return the full cert chain. 2. Store the cert chain in a "certs" table in ACME database. 3. Autogenerate the cert ID for each cert record. 4. Store the account ID in the cert record. 5. Store the cert ID in the order record. So a copy of the cert will be stored in ACME database. The cert ID will be unique for that particular ACME server. We don't need to include the issuer DN/ID. The cert serial number will not matter either. We can also use the certs table to authorize revocation requests. The cert ID is not meant to be human readable anyway (as shown in RFC 8555). -- Endi S. Dewata From builds at travis-ci.org Wed Mar 18 08:35:22 2020 From: builds at travis-ci.org (Travis CI) Date: Wed, 18 Mar 2020 08:35:22 +0000 Subject: [Pki-devel] [CRON] Still Failing: dogtagpki/pki-nightly-test#659 (master - 2a95153) In-Reply-To: Message-ID: <5e71dd4a2bc4b_43fd5447174d41011e0@995c2b91-6a44-4437-a892-302e856dd410.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #659 Status: Still Failing Duration: 22 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/663836829?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 Wed Mar 18 10:27:47 2020 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 18 Mar 2020 20:27:47 +1000 Subject: [Pki-devel] ACME certificate IDs In-Reply-To: <1638034160.37904670.1584479099220.JavaMail.zimbra@redhat.com> References: <20200317063838.GU251527@T470s> <1638034160.37904670.1584479099220.JavaMail.zimbra@redhat.com> Message-ID: <20200318102747.GW251527@T470s> On Tue, Mar 17, 2020 at 05:04:59PM -0400, Endi Sukma Dewata wrote: > ----- Original Message ----- > > Hi Endi, > > > > Just want to quickly discuss certificate IDs. > > > > Currently on ACMEBackend interface we have > > > > public BigInteger issueCertificate(String csr); > > > > I think this is a bit of a problem. e.g. Dogtag currently supports > > multiple issuers (LWCAs). It is incidental that serial numbers do > > not collide. This might not hold for other backends. Yet we need > > the certificate ID to uniquely identify the certificate, so that we > > can retrieve it, revoke it, etc. > > > > I suggest changing the return value to a string (which is how it > > gets stored in the ACMEOrder object anyway). > > > > I'd further suggest that by convention, where possible, the string > > be a representation of issuer+serial, which is a bit nicer for > > humans looking at the stored objects than a base64url-encoded > > big-endian bigint. > > > > What do you think? > > > > Cheers, > > Fraser > > Hi Fraser, > > I agree there is a problem, but I'm not sure about using issuer+serial > as certificate ID. What do we use as "issuer", is it the issuer DN > or the authority ID? > The issuer DN. > Is issuer DN unique enough? > (issuer, serial) pair must be globally unique. > How do we join with > the serial number? > What format do we use for serial number? > Doesn't really matter as long as it is unambiguous. For example, serial as decimal number, followed by ';', followed by string representation of Issuer DN. > What if we need to add another field in the future? It seems there's going to > be many questions/issues with this solution. > It is up to the ACMEBackend to produce a certificate ID. I'm simply proposing this because a backend could contain multiple CAs with separate serial number domains, hence deriving certificate ID from serial number alone would not be unique. The idea of (issuer,serial) pair is just a suggested convention. Some backends e.g. might prefer UUIDs or whatever makes it easy to retrieve a certificate/chain. > How about this instead? > > 1. Change issueCertificate() to return the full cert chain. > 2. Store the cert chain in a "certs" table in ACME database. > 3. Autogenerate the cert ID for each cert record. > 4. Store the account ID in the cert record. > 5. Store the cert ID in the order record. > > So a copy of the cert will be stored in ACME database. The cert > ID will be unique for that particular ACME server. We don't need > to include the issuer DN/ID. The cert serial number will not matter > either. We can also use the certs table to authorize revocation > requests. > I thought about this a little while back, and I prefer the current approach of storing an identifier as a "handle" to retrieve the cert from the backend. Cert objects will increase the size of records/objects significantly. For the LDAP backend it could be a problem, both for disk usage but in particular for replication. I'm OK with the idea of *optional* certificate/chain storage in the ACME database, e.g. for backends that do not support retrieval. But I don't think we need that with the current backends (certainly not with the PKIBackend). > The cert ID is not meant to be human readable anyway (as > shown in RFC 8555). > But it doesn't matter if it is human readable. Either way, storing only the serial number is not enough IMO. Cheers, Fraser From builds at travis-ci.org Thu Mar 19 08:42:29 2020 From: builds at travis-ci.org (Travis CI) Date: Thu, 19 Mar 2020 08:42:29 +0000 Subject: [Pki-devel] [CRON] Still Failing: dogtagpki/pki-nightly-test#660 (master - 2a95153) In-Reply-To: Message-ID: <5e733073efb6d_43fee7b3909c87814c@698c465a-9160-4233-be8f-f58ea264c3d5.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #660 Status: Still Failing Duration: 29 mins and 16 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/664288029?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 Fri Mar 20 04:55:46 2020 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 20 Mar 2020 00:55:46 -0400 (EDT) Subject: [Pki-devel] ACME certificate IDs In-Reply-To: <20200318102747.GW251527@T470s> References: <20200317063838.GU251527@T470s> <1638034160.37904670.1584479099220.JavaMail.zimbra@redhat.com> <20200318102747.GW251527@T470s> Message-ID: <1856675820.38770554.1584680146400.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > > Currently on ACMEBackend interface we have > > > > > > public BigInteger issueCertificate(String csr); > > > > > > I think this is a bit of a problem. e.g. Dogtag currently supports > > > multiple issuers (LWCAs). It is incidental that serial numbers do > > > not collide. This might not hold for other backends. Yet we need > > > the certificate ID to uniquely identify the certificate, so that we > > > can retrieve it, revoke it, etc. > > > > > > I suggest changing the return value to a string (which is how it > > > gets stored in the ACMEOrder object anyway). > > > > > > I'd further suggest that by convention, where possible, the string > > > be a representation of issuer+serial, which is a bit nicer for > > > humans looking at the stored objects than a base64url-encoded > > > big-endian bigint. > > > > I agree there is a problem, but I'm not sure about using issuer+serial > > as certificate ID. What do we use as "issuer", is it the issuer DN > > or the authority ID? > > The issuer DN. > > > Is issuer DN unique enough? > > (issuer, serial) pair must be globally unique. > > > How do we join with the serial number? > > What format do we use for serial number? > > Doesn't really matter as long as it is unambiguous. For example, > serial as decimal number, followed by ';', followed by string > representation of Issuer DN. > > > What if we need to add another field in the future? It seems there's going > > to > > be many questions/issues with this solution. > > It is up to the ACMEBackend to produce a certificate ID. I'm simply > proposing this because a backend could contain multiple CAs with > separate serial number domains, hence deriving certificate ID from > serial number alone would not be unique. The idea of > (issuer,serial) pair is just a suggested convention. Some backends > e.g. might prefer UUIDs or whatever makes it easy to retrieve a > certificate/chain. > > > How about this instead? > > > > 1. Change issueCertificate() to return the full cert chain. > > 2. Store the cert chain in a "certs" table in ACME database. > > 3. Autogenerate the cert ID for each cert record. > > 4. Store the account ID in the cert record. > > 5. Store the cert ID in the order record. > > > > So a copy of the cert will be stored in ACME database. The cert > > ID will be unique for that particular ACME server. We don't need > > to include the issuer DN/ID. The cert serial number will not matter > > either. We can also use the certs table to authorize revocation > > requests. > > I thought about this a little while back, and I prefer the current > approach of storing an identifier as a "handle" to retrieve the cert > from the backend. Cert objects will increase the size of > records/objects significantly. For the LDAP backend it could be a > problem, both for disk usage but in particular for replication. > > I'm OK with the idea of *optional* certificate/chain storage in the > ACME database, e.g. for backends that do not support retrieval. But > I don't think we need that with the current backends (certainly not > with the PKIBackend). > > > The cert ID is not meant to be human readable anyway (as > > shown in RFC 8555). > > But it doesn't matter if it is human readable. Either way, storing > only the serial number is not enough IMO. Let me backtrack a little bit. Is there a plan to modify Dogtag to eventually support different serial number domains? If not, this is not an issue for Dogtag. If there is such plan, will the issuer DN be unique across LWCAs? If issuer DN will be unique, it's something to consider. If not, (issuer DN, serial number) will not be unique either, so we need to use something else such as authority ID. Or is there another backend with multiple issuers that we want to support in the future? The cert ID will have to be something like (issuer ID, serial number) where the issuer ID is unique for the backend. If the issuer DN is unique, it can be used as the issuer ID. Otherwise, it needs to be a backend-specific unique ID similar to authority ID in Dogtag. We need to consider these possibilities before changing the cert ID. On the other hand, I'm still not sure it's actually necessary to include these information into cert ID. Let's look at the code. For cert enrollment (ACMEFinalizeOrderService) we convert the serial number that we get from ACMEBackend into cert ID: BigInteger serialNumber = backend.issueCertificate(csr); String certID = Base64.encodeBase64URLSafeString(serialNumber.toByteArray()); We can change it so ACMEBackend can generate the cert ID like this: String certID = backend.issueCertificate(csr); If the cert ID is (issuer DN, serial number), we can generate the cert ID from the new cert. But does the backend return the new cert or just the serial number? If the serial number is not unique, the backend might need to be changed to return the cert itself so we can get the issuer DN. If the cert ID is (authority ID, serial number), how do we get the authority ID since it's not included in the cert? The backend might need to be changed to return the authority ID along with the new cert, or to provide a way to look up the authority ID using a cert. For cert retrieval (ACMECertificateService) we're passing the cert ID to ACMEBackend: String certChain = backend.getCertificateChain(certID); The ACMEBackend can extract the issuer DN or authority ID from the cert ID so it can retrieve the cert from the backend again. Since we get the cert during enrollment anyway, we can actually store it into ACME database like this: String certChain = backend.issueCertificate(csr); String certID = database.addCert(certChain, orderID, accountID, expirationTime); Later we can simply retrieve it from the database instead of calling the backend again: String certChain = database.getCertificateChain(certID); Here the cert ID can simply be a unique ID generated by the database. Unlike earlier, the backend doesn't need to know about cert ID at all. For cert revocation (ACMERevokeCertificateService) the client will only provide the cert binaries. It doesn't provide the cert ID. Currently the ACMEEngine.validateRevocation() will generate the cert ID from the serial number so it can find the order that generated the cert (so we can authorize the account): String certID = Base64.encodeBase64URLSafeString(serialNumber.toByteArray()); ACMEOrder order = database.getOrderByCertificate(certID); We can changed it so ACMEBackend can generate the cert ID like this: String certID = backend.getCertID(certBytes); ACMEOrder order = database.getOrderByCertificate(certID); If the cert ID is (issuer DN, serial number), we can generate the cert ID from the provided cert binaries. But if the cert ID is (authority ID, serial number), how do we get the authority ID? Do we call the lookup operation above again to get the authority ID? Instead of that we can do this: String certID = database.getCertID(certBytes); ACMEOrder order = database.getOrderByCertificate(certID); which doesn't involve the backend at all. So backend-issued cert ID might work if we use a backend that already provides the required functionality above. Otherwise we may need to modify the backend, which is not always an option. The database-issued cert ID is a solution that doesn't require modifications to the backend, so I think it should be the default option. The certs stored in ACME database should be considered a cache. The server can purge it so it doesn't grow too large if that's a concern. Note that regardless of cert ID, the above revocation mechanism relies on order, authorization, or cert records in ACME database, which may not be available depending on the server's purging policy. If someone needs to have a reliable revocation mechanism they need to revoke using the private key. -- Endi S. Dewata From builds at travis-ci.org Fri Mar 20 08:50:29 2020 From: builds at travis-ci.org (Travis CI) Date: Fri, 20 Mar 2020 08:50:29 +0000 Subject: [Pki-devel] [CRON] Fixed: dogtagpki/pki-nightly-test#661 (master - 2a95153) In-Reply-To: Message-ID: <5e7483d5876bf_43f8a4676e98051657@445b122c-5ff1-4e41-b7e8-a5c8c644da36.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #661 Status: Fixed Duration: 29 mins and 53 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/664747072?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 Fri Mar 20 10:11:41 2020 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 20 Mar 2020 20:11:41 +1000 Subject: [Pki-devel] ACME certificate IDs In-Reply-To: <1856675820.38770554.1584680146400.JavaMail.zimbra@redhat.com> References: <20200317063838.GU251527@T470s> <1638034160.37904670.1584479099220.JavaMail.zimbra@redhat.com> <20200318102747.GW251527@T470s> <1856675820.38770554.1584680146400.JavaMail.zimbra@redhat.com> Message-ID: <20200320075807.GA251527@T470s> Hi Endi, Responses inline. On Fri, Mar 20, 2020 at 12:55:46AM -0400, Endi Sukma Dewata wrote: > ----- Original Message ----- > > > > Currently on ACMEBackend interface we have > > > > > > > > public BigInteger issueCertificate(String csr); > > > > > > > > I think this is a bit of a problem. e.g. Dogtag currently supports > > > > multiple issuers (LWCAs). It is incidental that serial numbers do > > > > not collide. This might not hold for other backends. Yet we need > > > > the certificate ID to uniquely identify the certificate, so that we > > > > can retrieve it, revoke it, etc. > > > > > > > > I suggest changing the return value to a string (which is how it > > > > gets stored in the ACMEOrder object anyway). > > > > > > > > I'd further suggest that by convention, where possible, the string > > > > be a representation of issuer+serial, which is a bit nicer for > > > > humans looking at the stored objects than a base64url-encoded > > > > big-endian bigint. > > > > > > I agree there is a problem, but I'm not sure about using issuer+serial > > > as certificate ID. What do we use as "issuer", is it the issuer DN > > > or the authority ID? > > > > The issuer DN. > > > > > Is issuer DN unique enough? > > > > (issuer, serial) pair must be globally unique. > > > > > How do we join with the serial number? > > > What format do we use for serial number? > > > > Doesn't really matter as long as it is unambiguous. For example, > > serial as decimal number, followed by ';', followed by string > > representation of Issuer DN. > > > > > What if we need to add another field in the future? It seems there's going > > > to > > > be many questions/issues with this solution. > > > > It is up to the ACMEBackend to produce a certificate ID. I'm simply > > proposing this because a backend could contain multiple CAs with > > separate serial number domains, hence deriving certificate ID from > > serial number alone would not be unique. The idea of > > (issuer,serial) pair is just a suggested convention. Some backends > > e.g. might prefer UUIDs or whatever makes it easy to retrieve a > > certificate/chain. > > > > > How about this instead? > > > > > > 1. Change issueCertificate() to return the full cert chain. > > > 2. Store the cert chain in a "certs" table in ACME database. > > > 3. Autogenerate the cert ID for each cert record. > > > 4. Store the account ID in the cert record. > > > 5. Store the cert ID in the order record. > > > > > > So a copy of the cert will be stored in ACME database. The cert > > > ID will be unique for that particular ACME server. We don't need > > > to include the issuer DN/ID. The cert serial number will not matter > > > either. We can also use the certs table to authorize revocation > > > requests. > > > > I thought about this a little while back, and I prefer the current > > approach of storing an identifier as a "handle" to retrieve the cert > > from the backend. Cert objects will increase the size of > > records/objects significantly. For the LDAP backend it could be a > > problem, both for disk usage but in particular for replication. > > > > I'm OK with the idea of *optional* certificate/chain storage in the > > ACME database, e.g. for backends that do not support retrieval. But > > I don't think we need that with the current backends (certainly not > > with the PKIBackend). > > > > > The cert ID is not meant to be human readable anyway (as > > > shown in RFC 8555). > > > > But it doesn't matter if it is human readable. Either way, storing > > only the serial number is not enough IMO. > > Let me backtrack a little bit. Is there a plan to modify Dogtag to > eventually support different serial number domains? If not, this is > not an issue for Dogtag. > There is no plan to do so. It is not an issue for Dogtag. But still, I feel basing certificate ID on only serial number is not a robust approach in general. > If there is such plan, will the issuer DN > be unique across LWCAs? If issuer DN will be unique, it's something > to consider. If not, (issuer DN, serial number) will not be unique > either, so we need to use something else such as authority ID. > > Or is there another backend with multiple issuers that we want to > support in the future? The cert ID will have to be something like > (issuer ID, serial number) where the issuer ID is unique for the > backend. If the issuer DN is unique, it can be used as the issuer > ID. Otherwise, it needs to be a backend-specific unique ID similar > to authority ID in Dogtag. > All certs must have unique (issuer,serial). This is implied by the requirement that all certs from a given issuer must have different serial numbers. > > We need to consider these possibilities before changing the cert ID. > On the other hand, I'm still not sure it's actually necessary to > include these information into cert ID. > > Let's look at the code. For cert enrollment (ACMEFinalizeOrderService) > we convert the serial number that we get from ACMEBackend into cert ID: > > BigInteger serialNumber = backend.issueCertificate(csr); > String certID = Base64.encodeBase64URLSafeString(serialNumber.toByteArray()); > > We can change it so ACMEBackend can generate the cert ID like this: > > String certID = backend.issueCertificate(csr); > I strongly agree with pushing the certID generation into the ACMEBackend. Stepping away from the whole (issuer,serial) discussion, say (for example) the only "handle" a backend has for accessing a cert is a UUID. Then storing the serial number is no good - you cannot derive the UUID handle from the serial number. So the backend must generate the (String) certID that is appropriate for that backend. > If the cert ID is (issuer DN, serial number), we can generate the > cert ID from the new cert. But does the backend return the new cert > or just the serial number? > Yeah, good question; of course you must be able to retrieve the cert (and therefore you can learn the Issuer DN) but this could mean another round-trip to Dogtag. Which is the next thing you said :) > If the serial number is not unique, the > backend might need to be changed to return the cert itself so we > can get the issuer DN. > > If the cert ID is (authority ID, serial number), how do we get the > authority ID since it's not included in the cert? The backend might > need to be changed to return the authority ID along with the new > cert, or to provide a way to look up the authority ID using a cert. > I am not suggesting to use the authority ID. But FWIW Dogtag does enforce that Issuer DN <-> Authority ID is a bijection. > > For cert retrieval (ACMECertificateService) we're passing the cert ID > to ACMEBackend: > > String certChain = backend.getCertificateChain(certID); > > The ACMEBackend can extract the issuer DN or authority ID from the > cert ID so it can retrieve the cert from the backend again. > > Since we get the cert during enrollment anyway, we can actually store > it into ACME database like this: > > String certChain = backend.issueCertificate(csr); > String certID = database.addCert(certChain, orderID, accountID, expirationTime); > > Later we can simply retrieve it from the database instead of calling > the backend again: > > String certChain = database.getCertificateChain(certID); > As I said in previous email, I am opposed to storing the cert (chain) in the ACME database. If some backend requires it e.g. because the backend itself does not store the cert, then it can be optional. But we do not need that now. > Here the cert ID can simply be a unique ID generated by the database. > Unlike earlier, the backend doesn't need to know about cert ID at all. > > For cert revocation (ACMERevokeCertificateService) the client will > only provide the cert binaries. It doesn't provide the cert ID. > And the ACMEBackend implementation receives the cert, and must work out what to do with it. How it tells the backend system to revoke the certificate, and whether that process even involves a string CertID handle, or just a serial number, or the (issuer,serial) pair, or whatever, depends on the backend system. But I think that the current interface: public void revokeCert(ACMERevocation revocation) ... ... is suitable. > Currently the ACMEEngine.validateRevocation() will generate the > cert ID from the serial number so it can find the order that > generated the cert (so we can authorize the account): > > String certID = Base64.encodeBase64URLSafeString(serialNumber.toByteArray()); > ACMEOrder order = database.getOrderByCertificate(certID); > > We can changed it so ACMEBackend can generate the cert ID like this: > > String certID = backend.getCertID(certBytes); > ACMEOrder order = database.getOrderByCertificate(certID); > > If the cert ID is (issuer DN, serial number), we can generate the > cert ID from the provided cert binaries. But if the cert ID is > (authority ID, serial number), how do we get the authority ID? Do > we call the lookup operation above again to get the authority ID? > > Instead of that we can do this: > > String certID = database.getCertID(certBytes); > ACMEOrder order = database.getOrderByCertificate(certID); > > which doesn't involve the backend at all. > > So backend-issued cert ID might work if we use a backend that > already provides the required functionality above. Otherwise we > may need to modify the backend, which is not always an option. > > The database-issued cert ID is a solution that doesn't require > modifications to the backend, so I think it should be the default > option. The certs stored in ACME database should be considered > a cache. The server can purge it so it doesn't grow too large if > that's a concern. > > Note that regardless of cert ID, the above revocation mechanism > relies on order, authorization, or cert records in ACME database, > which may not be available depending on the server's purging > policy. If someone needs to have a reliable revocation mechanism > they need to revoke using the private key. > Let us put aside the discussion about whether for the PKIBackend we use only (serial) as certID, or (issuer,serial) pair. I think we *should* switch to something derived from (issuer,serial), but we do not *need* to. So we can leave that discussion for now. The main change we need is for ACMEBackend.issuerCertificate to return String certID, i.e.: public String issuerCertificate(String csr) ... because BigInteger (i.e. serial) may not be an appropriate "handle" for all backends. Hence we should require each ACMEBackend implementation to produce the appropriate certIDs. Do you agree? Cheers, Fraser From edewata at redhat.com Fri Mar 20 19:41:05 2020 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 20 Mar 2020 15:41:05 -0400 (EDT) Subject: [Pki-devel] ACME certificate IDs In-Reply-To: <20200320075807.GA251527@T470s> References: <20200317063838.GU251527@T470s> <1638034160.37904670.1584479099220.JavaMail.zimbra@redhat.com> <20200318102747.GW251527@T470s> <1856675820.38770554.1584680146400.JavaMail.zimbra@redhat.com> <20200320075807.GA251527@T470s> Message-ID: <976864110.40010329.1584733265682.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > Let me backtrack a little bit. Is there a plan to modify Dogtag to > > eventually support different serial number domains? If not, this is > > not an issue for Dogtag. > > There is no plan to do so. It is not an issue for Dogtag. But > still, I feel basing certificate ID on only serial number is not a > robust approach in general. > > > If there is such plan, will the issuer DN > > be unique across LWCAs? If issuer DN will be unique, it's something > > to consider. If not, (issuer DN, serial number) will not be unique > > either, so we need to use something else such as authority ID. > > > > Or is there another backend with multiple issuers that we want to > > support in the future? The cert ID will have to be something like > > (issuer ID, serial number) where the issuer ID is unique for the > > backend. If the issuer DN is unique, it can be used as the issuer > > ID. Otherwise, it needs to be a backend-specific unique ID similar > > to authority ID in Dogtag. > > All certs must have unique (issuer,serial). This is implied by the > requirement that all certs from a given issuer must have different > serial numbers. > > > We need to consider these possibilities before changing the cert ID. > > On the other hand, I'm still not sure it's actually necessary to > > include these information into cert ID. > > > > Let's look at the code. For cert enrollment (ACMEFinalizeOrderService) > > we convert the serial number that we get from ACMEBackend into cert ID: > > > > BigInteger serialNumber = backend.issueCertificate(csr); > > String certID = > > Base64.encodeBase64URLSafeString(serialNumber.toByteArray()); > > > > We can change it so ACMEBackend can generate the cert ID like this: > > > > String certID = backend.issueCertificate(csr); > > > > I strongly agree with pushing the certID generation into the > ACMEBackend. Stepping away from the whole (issuer,serial) > discussion, say (for example) the only "handle" a backend has for > accessing a cert is a UUID. Then storing the serial number is no > good - you cannot derive the UUID handle from the serial number. > > So the backend must generate the (String) certID that is appropriate > for that backend. > > > If the cert ID is (issuer DN, serial number), we can generate the > > cert ID from the new cert. But does the backend return the new cert > > or just the serial number? > > > Yeah, good question; of course you must be able to retrieve the > cert (and therefore you can learn the Issuer DN) but this could mean > another round-trip to Dogtag. Which is the next thing you said :) > > > If the serial number is not unique, the > > backend might need to be changed to return the cert itself so we > > can get the issuer DN. > > > > If the cert ID is (authority ID, serial number), how do we get the > > authority ID since it's not included in the cert? The backend might > > need to be changed to return the authority ID along with the new > > cert, or to provide a way to look up the authority ID using a cert. > > > I am not suggesting to use the authority ID. But FWIW Dogtag does > enforce that Issuer DN <-> Authority ID is a bijection. > > > > > For cert retrieval (ACMECertificateService) we're passing the cert ID > > to ACMEBackend: > > > > String certChain = backend.getCertificateChain(certID); > > > > The ACMEBackend can extract the issuer DN or authority ID from the > > cert ID so it can retrieve the cert from the backend again. > > > > Since we get the cert during enrollment anyway, we can actually store > > it into ACME database like this: > > > > String certChain = backend.issueCertificate(csr); > > String certID = database.addCert(certChain, orderID, accountID, > > expirationTime); > > > > Later we can simply retrieve it from the database instead of calling > > the backend again: > > > > String certChain = database.getCertificateChain(certID); > > > As I said in previous email, I am opposed to storing the cert > (chain) in the ACME database. If some backend requires it e.g. > because the backend itself does not store the cert, then it can be > optional. But we do not need that now. > > > Here the cert ID can simply be a unique ID generated by the database. > > Unlike earlier, the backend doesn't need to know about cert ID at all. > > > > For cert revocation (ACMERevokeCertificateService) the client will > > only provide the cert binaries. It doesn't provide the cert ID. > > > And the ACMEBackend implementation receives the cert, and must work > out what to do with it. How it tells the backend system to revoke > the certificate, and whether that process even involves a string > CertID handle, or just a serial number, or the (issuer,serial) pair, > or whatever, depends on the backend system. But I think that the > current interface: > > public void revokeCert(ACMERevocation revocation) ... > > ... is suitable. > > > Currently the ACMEEngine.validateRevocation() will generate the > > cert ID from the serial number so it can find the order that > > generated the cert (so we can authorize the account): > > > > String certID = > > Base64.encodeBase64URLSafeString(serialNumber.toByteArray()); > > ACMEOrder order = database.getOrderByCertificate(certID); > > > > We can changed it so ACMEBackend can generate the cert ID like this: > > > > String certID = backend.getCertID(certBytes); > > ACMEOrder order = database.getOrderByCertificate(certID); > > > > If the cert ID is (issuer DN, serial number), we can generate the > > cert ID from the provided cert binaries. But if the cert ID is > > (authority ID, serial number), how do we get the authority ID? Do > > we call the lookup operation above again to get the authority ID? > > > > Instead of that we can do this: > > > > String certID = database.getCertID(certBytes); > > ACMEOrder order = database.getOrderByCertificate(certID); > > > > which doesn't involve the backend at all. > > > > So backend-issued cert ID might work if we use a backend that > > already provides the required functionality above. Otherwise we > > may need to modify the backend, which is not always an option. > > > > The database-issued cert ID is a solution that doesn't require > > modifications to the backend, so I think it should be the default > > option. The certs stored in ACME database should be considered > > a cache. The server can purge it so it doesn't grow too large if > > that's a concern. > > > > Note that regardless of cert ID, the above revocation mechanism > > relies on order, authorization, or cert records in ACME database, > > which may not be available depending on the server's purging > > policy. If someone needs to have a reliable revocation mechanism > > they need to revoke using the private key. > > > Let us put aside the discussion about whether for the PKIBackend we > use only (serial) as certID, or (issuer,serial) pair. I think we > *should* switch to something derived from (issuer,serial), but we do > not *need* to. So we can leave that discussion for now. > > The main change we need is for ACMEBackend.issuerCertificate to > return String certID, i.e.: > > public String issuerCertificate(String csr) ... > > because BigInteger (i.e. serial) may not be an appropriate "handle" > for all backends. Hence we should require each ACMEBackend > implementation to produce the appropriate certIDs. > > Do you agree? > > Cheers, > Fraser > Hi Fraser, Please take a look at this PR: https://github.com/dogtagpki/pki/pull/350 So the PKIBackend will continue to work like before, but these changes should allow us to support: - both single-authority and multi-authority backends - both one-step and two-step enrollments One thing though, I think we discussed before about using UUID to generate the serial number which has a very low chance of collision. If a backend uses UUID for all of its certificate authorities, can the serial number by itself be considered unique? -- Endi S. Dewata From ascheel at redhat.com Fri Mar 20 22:20:47 2020 From: ascheel at redhat.com (Alex Scheel) Date: Fri, 20 Mar 2020 18:20:47 -0400 (EDT) Subject: [Pki-devel] CVEs in RHEL 7 In-Reply-To: <441057227.10384253.1584742785258.JavaMail.zimbra@redhat.com> Message-ID: <24420835.10384263.1584742847234.JavaMail.zimbra@redhat.com> Hey Amy, Matt asked about our CVE response in RHEL 7. As far as I know, we have the following CVEs (grouped below by category). Third Party: - CVE-2016-10735 (bootstrap) XSS Moderate - CVE-2018-14040 (bootstrap) XSS Moderate - CVE-2018-14042 (bootstrap) XSS Moderate - CVE-2019-8331 (bootstrap) XSS Moderate - CVE-2019-11358 (js-jquery) XSS/DoS Moderate - CVE-2015-9251 (js-jquery) XSS Moderate These I'd recommend CLOSE->WONTFIX ; all are more work than they are worth in the last RHEL 7 release. It requires updating our dependencies and then re-testing the entire web UIs. They're not stored XSS and I'm not sure there's actually a viable way to exploit these in a RHCS environment. They're mostly about a way for a third-party site to inject content run in a trusted execution environment on a RHCS instance. That requires substantial theme customization (and/or changes to the server-side code to load elements from a third-party site) to enable and is well outside the scope of our support. Additionally, all operations are audited in our customer's deployments, so tracking down _who_ did this would be possible. I think it is safe to close these in RHEL 7. I'd like to fix all of these in RHEL 8 eventually, but again, that requires significant work and validation that we didn't break anything. All of these third-party dependencies (Bootstrap, jquery, ...) are severely out of date, and updating them is likely to break stuff. Doable, but not fun. :-) First Party - CVE-2019-10178 (TPS UI) XSS Moderate - CVE-2019-10179 (KRA UI) XSS Moderate - CVE-2019-10180 (TPS UI) XSS Low - CVE-2020-1696 (TPS UI) XSS Moderate - CVE-2020-1721 (KRA UI) XSS Low - CVE-2019-10146 (CA UI) XSS Low We don't have fixes for these in RHEL 8 yet. I think we should fix them in RHEL 8 and close them in RHEL 7. Testing these is significantly easier, and backporting would be easier. In all cases, I believe our QE team was the reporter. Someone familiar with this UI should probably fix them (Endi? Jack? Christina? I'm not sure). I think the changes should probably be server-side sanitation coupled with better front-end injection to prevent XSS. I can review, but I wouldn't know where to start to fix them. I wouldn't consider backporting them until someone (Amy? the customer?) is concerned and we've fixed them. However, my same argument about third-party ones stands here too: access is audited so it should be easy to find out who did this. My 2c., but I think they should be RHEL 8.3 candidates and not RHEL 7.9. If fixes are required/requested by the customer, we can always add them in a batch update. Thanks, - Alex From ftweedal at redhat.com Mon Mar 23 01:54:35 2020 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 23 Mar 2020 11:54:35 +1000 Subject: [Pki-devel] ACME certificate IDs In-Reply-To: <976864110.40010329.1584733265682.JavaMail.zimbra@redhat.com> References: <20200317063838.GU251527@T470s> <1638034160.37904670.1584479099220.JavaMail.zimbra@redhat.com> <20200318102747.GW251527@T470s> <1856675820.38770554.1584680146400.JavaMail.zimbra@redhat.com> <20200320075807.GA251527@T470s> <976864110.40010329.1584733265682.JavaMail.zimbra@redhat.com> Message-ID: <20200323015435.GB251527@T470s> On Fri, Mar 20, 2020 at 03:41:05PM -0400, Endi Sukma Dewata wrote: > ----- Original Message ----- > > > Let me backtrack a little bit. Is there a plan to modify Dogtag to > > > eventually support different serial number domains? If not, this is > > > not an issue for Dogtag. > > > > There is no plan to do so. It is not an issue for Dogtag. But > > still, I feel basing certificate ID on only serial number is not a > > robust approach in general. > > > > > If there is such plan, will the issuer DN > > > be unique across LWCAs? If issuer DN will be unique, it's something > > > to consider. If not, (issuer DN, serial number) will not be unique > > > either, so we need to use something else such as authority ID. > > > > > > Or is there another backend with multiple issuers that we want to > > > support in the future? The cert ID will have to be something like > > > (issuer ID, serial number) where the issuer ID is unique for the > > > backend. If the issuer DN is unique, it can be used as the issuer > > > ID. Otherwise, it needs to be a backend-specific unique ID similar > > > to authority ID in Dogtag. > > > > All certs must have unique (issuer,serial). This is implied by the > > requirement that all certs from a given issuer must have different > > serial numbers. > > > > > We need to consider these possibilities before changing the cert ID. > > > On the other hand, I'm still not sure it's actually necessary to > > > include these information into cert ID. > > > > > > Let's look at the code. For cert enrollment (ACMEFinalizeOrderService) > > > we convert the serial number that we get from ACMEBackend into cert ID: > > > > > > BigInteger serialNumber = backend.issueCertificate(csr); > > > String certID = > > > Base64.encodeBase64URLSafeString(serialNumber.toByteArray()); > > > > > > We can change it so ACMEBackend can generate the cert ID like this: > > > > > > String certID = backend.issueCertificate(csr); > > > > > > > I strongly agree with pushing the certID generation into the > > ACMEBackend. Stepping away from the whole (issuer,serial) > > discussion, say (for example) the only "handle" a backend has for > > accessing a cert is a UUID. Then storing the serial number is no > > good - you cannot derive the UUID handle from the serial number. > > > > So the backend must generate the (String) certID that is appropriate > > for that backend. > > > > > If the cert ID is (issuer DN, serial number), we can generate the > > > cert ID from the new cert. But does the backend return the new cert > > > or just the serial number? > > > > > Yeah, good question; of course you must be able to retrieve the > > cert (and therefore you can learn the Issuer DN) but this could mean > > another round-trip to Dogtag. Which is the next thing you said :) > > > > > If the serial number is not unique, the > > > backend might need to be changed to return the cert itself so we > > > can get the issuer DN. > > > > > > If the cert ID is (authority ID, serial number), how do we get the > > > authority ID since it's not included in the cert? The backend might > > > need to be changed to return the authority ID along with the new > > > cert, or to provide a way to look up the authority ID using a cert. > > > > > I am not suggesting to use the authority ID. But FWIW Dogtag does > > enforce that Issuer DN <-> Authority ID is a bijection. > > > > > > > > For cert retrieval (ACMECertificateService) we're passing the cert ID > > > to ACMEBackend: > > > > > > String certChain = backend.getCertificateChain(certID); > > > > > > The ACMEBackend can extract the issuer DN or authority ID from the > > > cert ID so it can retrieve the cert from the backend again. > > > > > > Since we get the cert during enrollment anyway, we can actually store > > > it into ACME database like this: > > > > > > String certChain = backend.issueCertificate(csr); > > > String certID = database.addCert(certChain, orderID, accountID, > > > expirationTime); > > > > > > Later we can simply retrieve it from the database instead of calling > > > the backend again: > > > > > > String certChain = database.getCertificateChain(certID); > > > > > As I said in previous email, I am opposed to storing the cert > > (chain) in the ACME database. If some backend requires it e.g. > > because the backend itself does not store the cert, then it can be > > optional. But we do not need that now. > > > > > Here the cert ID can simply be a unique ID generated by the database. > > > Unlike earlier, the backend doesn't need to know about cert ID at all. > > > > > > For cert revocation (ACMERevokeCertificateService) the client will > > > only provide the cert binaries. It doesn't provide the cert ID. > > > > > And the ACMEBackend implementation receives the cert, and must work > > out what to do with it. How it tells the backend system to revoke > > the certificate, and whether that process even involves a string > > CertID handle, or just a serial number, or the (issuer,serial) pair, > > or whatever, depends on the backend system. But I think that the > > current interface: > > > > public void revokeCert(ACMERevocation revocation) ... > > > > ... is suitable. > > > > > Currently the ACMEEngine.validateRevocation() will generate the > > > cert ID from the serial number so it can find the order that > > > generated the cert (so we can authorize the account): > > > > > > String certID = > > > Base64.encodeBase64URLSafeString(serialNumber.toByteArray()); > > > ACMEOrder order = database.getOrderByCertificate(certID); > > > > > > We can changed it so ACMEBackend can generate the cert ID like this: > > > > > > String certID = backend.getCertID(certBytes); > > > ACMEOrder order = database.getOrderByCertificate(certID); > > > > > > If the cert ID is (issuer DN, serial number), we can generate the > > > cert ID from the provided cert binaries. But if the cert ID is > > > (authority ID, serial number), how do we get the authority ID? Do > > > we call the lookup operation above again to get the authority ID? > > > > > > Instead of that we can do this: > > > > > > String certID = database.getCertID(certBytes); > > > ACMEOrder order = database.getOrderByCertificate(certID); > > > > > > which doesn't involve the backend at all. > > > > > > So backend-issued cert ID might work if we use a backend that > > > already provides the required functionality above. Otherwise we > > > may need to modify the backend, which is not always an option. > > > > > > The database-issued cert ID is a solution that doesn't require > > > modifications to the backend, so I think it should be the default > > > option. The certs stored in ACME database should be considered > > > a cache. The server can purge it so it doesn't grow too large if > > > that's a concern. > > > > > > Note that regardless of cert ID, the above revocation mechanism > > > relies on order, authorization, or cert records in ACME database, > > > which may not be available depending on the server's purging > > > policy. If someone needs to have a reliable revocation mechanism > > > they need to revoke using the private key. > > > > > Let us put aside the discussion about whether for the PKIBackend we > > use only (serial) as certID, or (issuer,serial) pair. I think we > > *should* switch to something derived from (issuer,serial), but we do > > not *need* to. So we can leave that discussion for now. > > > > The main change we need is for ACMEBackend.issuerCertificate to > > return String certID, i.e.: > > > > public String issuerCertificate(String csr) ... > > > > because BigInteger (i.e. serial) may not be an appropriate "handle" > > for all backends. Hence we should require each ACMEBackend > > implementation to produce the appropriate certIDs. > > > > Do you agree? > > > > Cheers, > > Fraser > > > > Hi Fraser, > > Please take a look at this PR: > https://github.com/dogtagpki/pki/pull/350 > > So the PKIBackend will continue to work like before, but > these changes should allow us to support: > - both single-authority and multi-authority backends > - both one-step and two-step enrollments > > One thing though, I think we discussed before about using UUID to > generate the serial number which has a very low chance of collision. > If a backend uses UUID for all of its certificate authorities, can > the serial number by itself be considered unique? > Practically speaking, I'd say yes. As I already discussed at length, I'd prefer we rely on what X.509 *requires* to be unique (i.e. (issuer,serial)) where possible. But if we are confident a backend with multiple issuers has a single serial number domain (whether they are UUIDs or just a single sequential source like Dogtag), *and* that this property is unlikely to change, then I can live with it. I'll try to review PR 350 today. Cheers, Fraser From builds at travis-ci.org Fri Mar 27 13:30:13 2020 From: builds at travis-ci.org (Travis CI) Date: Fri, 27 Mar 2020 13:30:13 +0000 Subject: [Pki-devel] [CRON] Broken: dogtagpki/pki-nightly-test#668 (master - 2a95153) In-Reply-To: Message-ID: <5e7dffe4d30dc_43f8ca049f860475657@18837656-1ef5-4eb0-a71a-c1eb7bff768e.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #668 Status: Broken Duration: 33 mins and 32 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/667680957?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 Mar 28 13:28:31 2020 From: builds at travis-ci.org (Travis CI) Date: Sat, 28 Mar 2020 13:28:31 +0000 Subject: [Pki-devel] [CRON] Still Failing: dogtagpki/pki-nightly-test#669 (master - 2a95153) In-Reply-To: Message-ID: <5e7f50febd5ac_43f7e3a63d4706835a6@70ba5f9d-cfef-40f4-801f-89c811353c83.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #669 Status: Still Failing Duration: 30 mins and 53 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/668048974?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 Mar 29 13:29:36 2020 From: builds at travis-ci.org (Travis CI) Date: Sun, 29 Mar 2020 13:29:36 +0000 Subject: [Pki-devel] [CRON] Still Failing: dogtagpki/pki-nightly-test#670 (master - 2a95153) In-Reply-To: Message-ID: <5e80a2bfdee74_43fa12df9e9686599c0@8f1ec063-8cff-4441-9b4f-17d055002349.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #670 Status: Still Failing Duration: 30 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/668342003?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 Mar 30 13:52:20 2020 From: builds at travis-ci.org (Travis CI) Date: Mon, 30 Mar 2020 13:52:20 +0000 Subject: [Pki-devel] [CRON] Fixed: dogtagpki/pki-nightly-test#671 (master - 2a95153) In-Reply-To: Message-ID: <5e81f9937b464_43ff95f0170f07754b5@27b11fd7-751f-4344-80c6-dceda9749a9f.mail> Build Update for dogtagpki/pki-nightly-test ------------------------------------- Build: #671 Status: Fixed Duration: 31 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/668733687?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: