[ietf-dkim] new issue: more details of key record format in base

[Eric Allman]

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.farrell at cs.tcd.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
>