On Mon, Nov 29, 2021 at 3:01 AM Grant Byers <[email protected]> wrote:
> Hi Pierre, > > > Thanks for the clarification. FWIW, I haven't experienced any issues with > replication agreement credentials post rolling of keys, but we've been > running 1.3 and are just now migrating to 1.4, so may need to keep an eye > on that. > > Do you think it would it be feasible to have those attribute encryption > keys based on a different RSA key? I could raise a feature request. The way > the world has been heading with certs is to make them shorter, shorter, > shorter. Ordinarily, that's not a bad thing because we can use config > management to automatically roll certs as required, but have found the > process with NSS to be quite cumbersome. The RH doco on the subject (RHDS > 11 admin guide) involves a complete new key every time it is renewed, but > there's no mention of care around attribute encryption (that's an issue for > the RH doco team) - > https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/managing_the_nss_database_used_by_directory_server#renewing_a_certificate. > <https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/managing_the_nss_database_used_by_directory_server#renewing_a_certificate> > Hi Grant, I agree. Feel free to open a bugzilla for the bug doc and also a rfe about being able to handle certificate renewal when using attribute encryption (there is clearly a hole in this area ...) IMHO using a different key will just displace the problem. There still be trouble when replacing that key (by nature the, probability a cryptographic key get compromised increase over time, and it should be replaced after some time (that is why certificates have expiration time)) ) IMHO we will probably need several keys (1 for encryption and a few others to decrypt the attributes encrypted with older keys. Anyway a sure thing is that this subject deserves thorough thinking. Regards Pierre > > If I were using attribute encryption, i think i would just keep re-using > the original CSR to issue a new cert and replace that rather than rolling > the key each time, but I believe that's considered bad practice these days > too. A separate rsa key would be ideal IMO. > > > Cheers, > Grant > > > On Fri, 2021-11-26 at 13:48 +0100, Pierre Rogier wrote: > > [External Mail] > > Hi Grant, > > I think that you are absolutely right here: > I suspect that the "Please disable encryption" is misleading > as according to the code, the only way not to initialize the > attribute encryption keys is to fully disable the security. > So removing the attribute encryption key entry is probably the only > thing to do. (possible because no encrypted attributes are configured) > > That said there is another point that could cause problems with cert > renewal: the replication agreement credential is also using > symmetrical encryption so you may have to replace their passwords. > > Regards > Pierre > > On Fri, Nov 26, 2021 at 2:35 AM Grant Byers <[email protected]> > wrote: > > Hi all, > > > Is there a way to either permanently disable attribute encryption, or to > have the symmetric keys generated from an alternate RSA private key to that > used for > TLS (given by cn=RSA,cn=encryption,cn=config)? I may be missing something, > but this seems to be completely tied to TLS. > > > We don't use attribute encryption at all presently, and the process we use > for rolling certtificates is basically a re-key. This results in the > following error > messages; > > > [25/Nov/2021:06:32:33.562508644 +0000] - ERR - attrcrypt_unwrap_key - > Failed to unwrap key for cipher AES > [25/Nov/2021:06:32:33.564813203 +0000] - ERR - attrcrypt_cipher_init - > Symmetric key failed to unwrap with the private key; Cert might have been > renewed since > the key is wrapped. To recover the encrypted contents, keep the wrapped > symmetric key value. > [25/Nov/2021:06:32:33.931422579 +0000] - ERR - attrcrypt_unwrap_key - > Failed to unwrap key for cipher 3DES > [25/Nov/2021:06:32:33.935241033 +0000] - ERR - attrcrypt_cipher_init - > Symmetric key failed to unwrap with the private key; Cert might have been > renewed since > the key is wrapped. To recover the encrypted contents, keep the wrapped > symmetric key value. > [25/Nov/2021:06:32:33.937228742 +0000] - ERR - attrcrypt_init - All > prepared ciphers are not available. Please disable attribute encryption. > > > I realise we could delete the encrypted attribute keys entries as part of > our renewal process & have them regenerated, but that seems pretty hackish. > The > message implies attribute encryption can be disabled ("Please disable > attribute encryption."), yet the only way I see to do this is to disable > TLS via nsslapd- > security. Can someone confirm? > > > Thanks, > Grant > > _______________________________________________ > 389-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=04%7C01%7Cgrant.byers%40aarnet.edu.au%7C8506a06c7aa848a455a808d9b0db31fd%7C4795f4d0a4b847c4af198dd47da5d8d4%7C0%7C0%7C637735277785356961%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2F93YS7vRUygCl6uOytRCzDHVCFCpFKhqeTIggQNVF50%3D&reserved=0> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines&data=04%7C01%7Cgrant.byers%40aarnet.edu.au%7C8506a06c7aa848a455a808d9b0db31fd%7C4795f4d0a4b847c4af198dd47da5d8d4%7C0%7C0%7C637735277785356961%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yRKfiXq7dk2BY08HbpIDz9NMX%2Fv3TNnuCWCwwj23ns4%3D&reserved=0> > List Archives: > https://lists.fedoraproject.org/archives/list/[email protected] > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedoraproject.org%2Farchives%2Flist%2F389-users%40lists.fedoraproject.org&data=04%7C01%7Cgrant.byers%40aarnet.edu.au%7C8506a06c7aa848a455a808d9b0db31fd%7C4795f4d0a4b847c4af198dd47da5d8d4%7C0%7C0%7C637735277785366955%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=esiaVS50oEa1pdw29vHZ0JedRKFo78xmYpUI3UWZ5R8%3D&reserved=0> > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure.io%2Ffedora-infrastructure&data=04%7C01%7Cgrant.byers%40aarnet.edu.au%7C8506a06c7aa848a455a808d9b0db31fd%7C4795f4d0a4b847c4af198dd47da5d8d4%7C0%7C0%7C637735277785366955%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=LaDwUPF7RLEfbsbKFDc9rxq771I2Yq8%2FyKDxPl6R77g%3D&reserved=0> > > > > _______________________________________________ > 389-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/[email protected] > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > > > _______________________________________________ > 389-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/[email protected] > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- -- 389 Directory Server Development Team
_______________________________________________ 389-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
