It seems to me that the intent is to create keys in the manner shown
in Appendix C. Since that contains the modulus, it seems like we
should just drop all mention of the modulus --- it's just not
relevant in this context.
I would like to check with Jon Callas first, just to make sure, since
I think I got that wording from him. He may have had something in
particular in mind. Or I may just be misremembering.
eric
--On July 4, 2006 4:54:39 PM +0100 Stephen Farrell
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> wrote:
Just so's we don't lose this (the other thread is called "editorials
and nits":-).
We should fix base to match the information below supplied by EKR,
which is, I assume, what's implemented and which is also correct.
(And get rid of the hardcoded 65537 stuff.)
Stephen.
Here's the relevant text:
k= Key type (plain-text; OPTIONAL, default is "rsa").
Signers and
verifiers MUST support the "rsa" key type. The "rsa" key
type
indicates that an RSA public key, as defined in [RFC3447],
sections 3.1 and A.1.1, is being used in the p= tag.
(Note: the
p= tag further encodes the value using the base64
algorithm.)
And here's what's in A.1.1:
An RSA public key should be represented with the ASN.1 type
RSAPublicKey:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}
The fields of type RSAPublicKey have the following meanings:
* modulus is the RSA modulus n.
* publicExponent is the RSA public exponent e.
The only ASN.1 definition here is for the full public key.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html