I have various minor nits with the base document. Overall I consider the
document ready to go; these nits can be taken care of during AUTH48.
Tony Hansen
tony@xxxxxxx
1. Introduction
o archival is not a design goal
^^^^^^^^
All of the other bullet items have full sentences, but this one does
not. (Archival is an adjective, not a noun.) Suggestions are replacing
"archival" with "message archiving" or "archiving".
3.2 Tag=Value Lists
< however, no encoding may include the semicolon (";")
This is slightly ambiguous, as it could be read as saying that the value
being encoded cannot have a semicolon in it, as opposed to the encoded
version of the value. I suggest that this be changed to read
> however, no encoding may use an unencoded semicolon (";")
or
> however, no encoding may produce an unencoded semicolon (";")
3.3.1 The rsa-sha1 Signing Algorithm
3.3.2 The rsa-sha256 Signing Algorithm
< (defined in PKCS#1
< (actually PKCS#1
This wording is different between these two sections and could lead
someone to wonder what is different in their treatment. I suggest that
they be made the same.
3.3.3 Key sizes
< See [RFC3766] for further discussion of selecting
> See [RFC3766] for further discussion on selecting
3.5 The DKIM-Signature header field
< after the body of the message;
We no longer include the body of the message in the digest calculation.
I suggest changing this fragment to:
> after the rest of the header fields being signed;
5.4 Determine the header fields to Sign
< Signers MAY claim to have signed ...
< ...
< Signers choosing to sign ....
< The signer MAY include more instances of a header field ...
The sentence "The signer MAY" is at the end of the paragraph starting
"Signers choosing". It would make more sense to move this information to
the paragraph starting "Signers MAY claim".
6.1.3 Compute the Verification
< 3. Verify that the hash of the canonicalized message body computed ...
What happens if the hash does not match? Suggested addition is:
> If the hash does not match, the verifier SHOULD ignore the signature
> and return PERMFAIL (body hash did not verify).
< used the "N-4" trick ... informative note in Section 5.5.
The informative note is really in Section 3.4.5, but is not referred to
there as 'the "N-4" trick'. The reader may have a problem following this
reference. I suggest you change it to this:
> used the "N-4" trick (omitting the final "--CRLF") ... informative
> note in Section 3.4.5.
6.2 Communicate Verification Results
< Verifiers may wish to delete existing results header fields after
< verification and before adding a new header field to circumvent this
< attack.
This sentence is a bit awkward. I suggest his instead:
> To circumvent this attack, verifiers may wish to delete existing
> results header fields after verification and before adding a new
> header field .
A.1 The user composes an email and A.2 The email is signed
The message as shown in these two sections are not identical. In
particular, the indentation before "Joe" is different in the two
examples. The A.2 and A.3 examples are consistent, so I suggest that the
example in A.1 be changed. An alternative is to provide an explicit dump
of the example in A.1 so the exact bytes are known, such as:
0000000 F r o m : J o e S i x P a c
0000020 k < j o e @ f o o t b a l l .
0000040 e x a m p l e . c o m > \r \n T o
0000060 : S u z i e Q < s u z i e
0000100 @ s h o p p i n g . e x a m p l
0000120 e . n e t > \r \n S u b j e c t :
0000140 I s d i n n e r r e a d y
0000160 ? \r \n D a t e : F r i , 1 1
0000200 J u l 2 0 0 3 2 1 : 0 0 :
0000220 3 7 - 0 7 0 0 ( P D T ) \r \n
0000240 M e s s a g e - I D : < 2 0 0
0000260 3 0 7 1 2 0 4 0 0 3 7 . 4 6 3 4
0000300 1 . 5 F 8 J @ f o o t b a l l .
0000320 e x a m p l e . c o m > \r \n \r \n
0000340 H i . \r \n \r \n W e l o s t t
0000360 h e g a m e . A r e y o u
0000400 h u n g r y y e t ? \r \n \r \n
0000420 J o e . \r \n
0000433
A.2 The email is signed
The hashes in this section are not what would be produced by the sample
private key found in Appendix C. (This was discussed at one of the past
meetings.) Change bh= and b= to the following values:
bh=jpltwNFTq83Bkjt/Y2ekyqr/+i296daNkFZSdaz8VCY=;
b=bnUoMBPJ5wBigyZG2V4OG2JxLWJATkSkb9Ig+8OAu3cE2x/er+B7Tp1a1kEwZKdOtlTHlvF4JKg6
RZUbN5urRJoaiD4RiSbf8D6fmMHtzEn8/OHpTCcdLOJaTp8/mKz69/RpatVBas2OqWas7jrlaLGf
HdBktHs6fxOzzAB7Wro=;
A.3 The email signature is verified
< The result ... is stored in the "Authentication-Results" header
< ...
< X-Authentication-Results: shopping.example.net
< header.from=joe@xxxxxxxxxxxxxxxxxxxx; dkim=pass
These are not consistent, and imply the pre-existence of the A-R header.
Also, it is not the header.from value that has been authenticated, but
the i= value within the dkim-signature. I suggest that these lines be
changed to:
< The result ... could be stored in a header named something like
< "Dkim-Authentication-Results"
< ...
< Dkim-Authentication-Results: shopping.example.net
< header.dkim.i=joe@xxxxxxxxxxxxxxxxxxxx
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf