retitle 619746 gnutls-bin: [certtool] please create CSR outputs with stricter permission tags 619746 + upstream thanks
Hi Nikos! On Wed, 30 Mar 2011 14:20:04 +0200, Nikos Mavrogiannopoulos wrote: > On Wed, Mar 30, 2011 at 2:01 PM, Luca Capello <[email protected]> wrote: > >>> I don't quite understand what is the issue here. What is the >>> information contained in the CRQ that you consider "useless"? >> As I wrote, the "new" CSR (BTW, what does CRQ mean?) contains data other >> than the request itself, e.g. the password in clear, example below. > > But this is how the PKCS #10 certificate request is designed. The > challenge password might be used by your CA to revoke your > certificate, and is stored in the clear. Thank you for the explanation, I am not a SSL/TLS/CA expert. > Does actually your CA require that password? I'd expect to ask for > something like that via an out-band process. As far as I remember, back in 2008 the CAcert.org we form did not ask me for any password, but I could be wrong. >> Previous versions of certtool (at least the one I used in August 2008, >> <http://snapshot.debian.org/package/gnutls26/2.4.1-1/>) generated a CSR >> which contained only the part between the BEGIN and END separators. > > Ok, it seems I have misanderstood. I don't see however why printing the > text form of the encoded request is an issue here. Could you elaborate > on that? After your explanation, I do not see any problem with the "full" CSR and TBH I prefer this way, given that it is easier to know the parameters you have use to generated your CSR. > I can understand though that having stricter permissions for the > generated file might be needed. Yes, please, it should be the same as `certtool --generate-privkey --output output.key`, which creates output.key with mode 600. I changed the title of this bug to reflect where the problem is ;-) Thx, bye, Gismo / Luca
pgp4jUsOFBWuu.pgp
Description: PGP signature
