Re: [Dcrup] sequence of drafts, draft-ietf-dcrup-dkim-usage and document shepherds

[Scott Kitterman <[e-mail]>]

On Saturday, June 10, 2017 08:02:46 PM Salz, Rich wrote:
> > Given that (which I wasn't aware of), I'll revise my estimate downwards. 
> > I
> > still think a separate draft for clearing out the obsolete cruft is worth
> > advancing and getting done.
> 
> Yes, there's a growing tradition for "die-die-die" documents.

OK.  Given that, I'd like to resolve the question of how to refer to rsa-sha1 
in section three.  There, as far as I can tell, two visions, roughly what's in 
-02 and what was in -01:

Current (-02):

> 3.  DKIM Signing and Verification Algorithms
> 
>    This section replaces [RFC6376] Section 3.3 in its entirety.
>    
>    Generally, DKIM supports multiple digital signature algorithms.  One
>    algorithm, rsa-sha256, is currenlty defined.  Signers MUST implement
>    and sign using rsa-sha256.  Verifiers MUST implement rsa-sha256.
> 
> 3.1.  The rsa-sha256 Signing Algorithm
> 
>    The rsa-sha256 Signing Algorithm computes a message hash as described
>    in [RFC6376], Section 3.7 using SHA-256 [FIPS-180-3-2008] as the
>    hash-alg.  That hash is then signed by the Signer using the RSA
>    algorithm (defined in PKCS#1 version 1.5 [RFC8017]) as the crypt-alg
>    and the Signer's private key.  The hash MUST NOT be truncated or
>    converted into any form other than the native binary form before
>    being signed.  The signing algorithm SHOULD use a public exponent of
>    65537.
> 
> 3.2.  Key Sizes
...

and -01:

> 3.  DKIM Signing and Verification Algorithms
> 
>    This section replaces [RFC6376] Section 3.3 in its entirety.
>    
>    DKIM supports multiple digital signature algorithms.  Two algorithms
>    were defined by [RFC6376]: rsa-sha1 and rsa-sha256.  Signers MUST
>    implement and sign using rsa-sha256.  Verifiers MUST implement rsa-
>    sha256.  The rsa-sha1 signing algorithm is obsolete and MUST NOT be
>    used.
> 
> 3.1.  The rsa-sha1 Signing Algorithm
> 
>    This algorithm is obsolete and MUST NOT be used.
> 
> 3.2.  The rsa-sha256 Signing Algorithm
> 
>    The rsa-sha256 Signing Algorithm computes a message hash as described
>    in [RFC6376], Section 3.7 using SHA-256 [FIPS-180-3-2008] as the
>    hash-alg.  That hash is then signed by the Signer using the RSA
>    algorithm (defined in PKCS#1 version 1.5 [RFC8017]) as the crypt-alg
>    and the Signer's private key.  The hash MUST NOT be truncated or
>    converted into any form other than the native binary form before
>    being signed.  The signing algorithm SHOULD use a public exponent of
>    65537.
> 
> 3.3.  Key Sizes
...

Personally, I prefer the explicit MUST NOT we had in -01 and I think that's 
along the lines of what Martin Thomson was suggesting.  A hatless msk 
preferred something more like what's there now.

Technically, I think the amount to the same thing.  Is it better to be more 
explicit about what's being removed or be implicit by removing it from what's 
specified?  Personally, I think explicit is better than implicit, but being a 
Python guy, I would [1]

Scott K

[1] https://www.python.org/dev/peps/pep-0020/