Re: [Dcrup] new version draft-ietf-dcrup-dkim-crypto-04

[Martin Thomson <[e-mail]>]

Hi John,

This looks pretty good.

The abstract still says "and deprecates an obsolete signing
algorithm", which I think that you only obliquely.  I think that you
can remove the "Updates: RFC 6376" as well, but that means larger
changes.

In the spirit of leaving the removal of the crusty old stuff to the
other draft, I think that you should:

1. remove the clause from the abstract
2. remove the first paragraph of Section 6 (which specifies the update
to RFC 6376)
3. remove the requirement to use 1024-bit keys for "rsa-sha256"

That means changing Section 3 to concentrate on what rsafp does,
rather than specify it as patches to RFC 6376.

Yes, this doesn't make the change to hashed keys generic and others
will likely cargo-cult this document, but monkey-patching RFC 6376
like this could affect "rsa" keys as well as "rsafp" keys.

OLD:
   Section 5.5 of [RFC6376], on computing the message hash and
   signature, is modified as follows: When creating a signature with a
   signing algorithm that uses a key fingerprint, the signer includes
   the public key in the signature as a base64 encoded string with a k=
   tag.  The key in the tag is the same one that would be published in a
   non-fingerprint key record.
NEW:
   When creating a signature with an "rsafp" algorithm, the signer
   includes the public key in the signature as a base64 encoded
   string with a p= tag.  The value of the p= tag is an ASN.1
   DER-encoded [ITU-X660-1997] RSAPublicKey (see [RFC3447], Sections
   3.1 and A.1.1).

IMPORTANT: I think that you meant p= here rather than k=.

OLD:
   Section 3.7 of [RFC6376], on computing the message hashes, is not
   modified.  Since the key in the k= tag is known in advance, it
   included in the signature in the same manner as all of the other
   signature fields other than b=.
NEW:
   Message hashes are computed exactly as described in [RFC6376].
   Since the key in the p= tag is known in advance, it is included in
   the signature in the same manner as all of the other signature
   fields other than b=.

OLD:
   Section 6.1.3 of [RFC6376], to compute the verification, is modified
   as follows: In item 4, if the signing algorithm uses a key
   fingerprint, extract the verification key from the k= tag.  If there
   is no such tag, the signature does not validate.  Extract the key
   hash from the p= tag of the key record.  If there is no such tag or
   the tag is empty, the signature does not validate.  Compute the
   SHA-256 hash of the verification key, and compare it to the value of
   the key hash.  If they are not the same, the signature does not
   validate.  Otherwise proceed to verify the signature using the
   validation key and the algorithm described in the "a=" tag.
NEW:
   To verify a signature using the "rsafp" algorithm, follow the
   process described in RFC 6376 for "rsa" keys.  However, the
   "rsafp" algorithm takes the verification key from the p= tag.  If
   the p=tag is not present in the message, the signature does not
   validate.  In addition to signature verification, the verifier
   MUST ensure that the p= field of the key record is equal to the
   SHA-256 hash of the verification key.  If this check fails, the
   signature does not validate.

Final unrelated comment:

You recommend that "rsafp signatures SHOULD use key lengths of 1536 or
2048 bits".  I think that you want to include an "at least" here, and
use MUST.  Pick a number.  The rest of the industry is relatively
comfortable with 2048, which would be my pick, i.e., "rsafp signatures
MUST use keys that are 2048 bits or larger"



On 29 July 2017 at 04:11, John R Levine <[e-mail]> wrote:
> This takes out the sha-1 deprecation stuff and makes many editorial changes
> based on comments from ekr and Martin T.  I didn't necessarily do everything
> they suggested, but I think I did look at all the suggestions.
>
> Regards,
> John Levine, [e-mail], Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> _______________________________________________
> Dcrup mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dcrup