Don't need to copy the challenge data before calling DER_Encode because...

Don't need to copy the challenge data before calling DER_Encode because
DER_Encode will copy it.  Document the GenKeyAndSignChallenge function.

R=mattm,davidben
BUG=148
TEST=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=50682

[wtc, 2010-06-18 18:20:33]

mattm: please review this CL.

davidben: these are the only minor issues I found while
reviewing keygen_handler_nss.cc yesterday, to ensure our
code is correct and the bug is in NSS.

[wtc, 2010-06-18 18:26:27]

Some notes:

http://codereview.chromium.org/2866011/diff/4001/5001
File net/third_party/mozilla_security_manager/nsKeygenHandler.cpp (right):

http://codereview.chromium.org/2866011/diff/4001/5001#newcode212
net/third_party/mozilla_security_manager/nsKeygenHandler.cpp:212:
pkac.challenge.data = (unsigned char *)challenge.data();
DER_Encode does not use the |type| field.  I'm initializing
it just for style (or rather defensive programming).

The |data| field is 'unsigned char*', while challenge.data()
is 'const char*'.  If I use C++ casts, I'll need two (first
const_cast and then reinterpret_cast).  So I use a C style
cast for brevity.  If you want, I can change to C++ casts.
DER_Encode does not mutate the bytes pointed to by the
|data| field, which is why it's safe to cast away the const.
(This is a common limitation of C APIs that use a data-buffer
type for both input and output.)

[mattm, 2010-06-18 19:03:58]

LGTM

[davidben, 2010-06-18 20:55:50]

LGTM