ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] editorials and nits

2006-07-07 16:18:28
Eric Allman <eric+dkim(_at_)sendmail(_dot_)org> writes:
Sorry - you're right about the reference, I just forgot to include
it, you could change text suggestion to: "The signature is
calculated using the RSA signature algorithm as specified in PKCS#1
version 1.5 [RFC3447], and with a fixed public exponent of 65537 -
if a different public exponent is required, then a new DKIM signing
algorithm tag value must be defined."

I made the change as you suggest --- but this left me wondering: when
you use openssl "genrsa", does that produce something that contains
the exponent or not?  If it does, then we shouldn't be mentioning
65537 at all.  If that is implied, then we should.  [IIRC I got this
wording from Jon --- perhaps he can add something.]

I don't agree that this is the appropriate test. The correct
test is what the right engineering choice is, and that's
clearly to use a PKCS#1 PublicKey struct. What would happen
if OpenSSL emitted some totally nonstandard thing?
That said, what openssl emits *is* a PKCS#1 public key
struct.

#34, Appendix C. I think that this can be deleted. Others may
disagree. In any case, the text says 768 and the command line
1024, no  password handling is shown and the last part could
confuse since that signature is not usable for DKIM. So if this
isn't deleted, then a bunch of changes are needed.

I fixed the discrepancy, but I don't think it should be deleted.
It's  non-normative and will help people understand how to use the
standard,  which I think is A Good Thing.

I'm not sure what you mean about password handling.  I just ran
through  these instructions, and there are no passwords requested.

Sure, you don't have to use passwords with s/w private keys, but you
really should do at least that much.

If we're going to give this kind of help, we don't want it to
encourage people to take less secure options without being clear
that that's what they're doing.

So are you saying that the genrsa step should be using -passin?  I can
see that as an optional step that we could discuss, but it's not
strictly required for the algorithm to work.

Frankly, I don't think the password advice makes much sense.
You in general want your server to restart unattended
This means that the key needs to be available without
some clown at the console typing the password. So, either
you don't use a password or you wire it into some config
file or script, at which point the question becomes why
you didn't just protect the key with whatever file permissions
protect the password.

-Ekr
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html