Subject: [ietf-dkim] draft-ietf-dkim-base-02 typos?

From: Douglas Otis <[email-masked]>
Date: Wed, 31 May 2006 14:22:23 -0700

Errors are highlighted using [[error]] notation.  This was based upon  
the draft located at:
http://ietf.org/internet-drafts/draft-ietf-dkim-base-02.txt

There seems to be a type of corruption introduced and were not noted  
in Jim's nits.

3.4.6  Example

  Example 3:  When processed using relaxed header canonicalization and
    simple body [[canoniccalization]],

3.5  The DKIM-Signature header field

h=   Signed header fields (plain-text, but see description;
        REQUIRED).  A colon-separated list of header field names that
        identify the header fields presented to the signing algorithm.
        The field MUST contain the complete list of header fields in the
        order presented to the signing algorithm.  The field MAY contain
        names of header fields that do not exist when signed;  
nonexistent
        header fields do not contribute to the signature computation
        (that is, they are treated as the null input, [[includiing]] the

z=   Copied header fields (plain-text, but see description; OPTIONAL,
        default is null).  A vertical-bar-separated list of selected
        header field names and copies of header field values that  
identify the header
        fields present when
        the message was signed.  It is not required to include all  
header
        fields present at the time of signing.  This field need not
        contain the same header fields listed in the "h=" tag.  Copied
        header field values MUST immediately follow the header field  
name
        with a colon separator (no white space permitted).  Header field
        values MUST be represented as Quoted-Printable [RFC2045] with
        vertical bars, colons, semicolons, and white space encoded in
        addition to the usual requirements.

        Verifiers MUST NOT use the header field names or copied values
        for checking the signature in any way.  Copied header field
        values are for diagnostic use [[onnly]].

3.6.1  Textual Representation

    It is expected that many key servers will choose to present the keys
    in an otherwise unstructured text format (for example, an XML form
    would not be considered to be unstructured text for this purpose).
    The following definition [[MMUST]] be used for any DKIM key  
represented in
    an otherwise unstructured textual form.
...
        y   This domain is testing DKIM.  Verifiers MUST NOT treat
            messages from signers in testing mode differently from
            unsigned email, even should the signature fail to verify.
            Verifiers MAY wish to track testing [[modee]] results to  
assist
            the signer.

3.7  Computing the Message Hashes

   In hash step 1, the signer or verifier MUST hash the message body,
    canonicalized using the body canonicalization algorithm specified in
    the "c=" tag and truncated to the length specified in the "l=" tag.
    That hash value is then converted to base64 form and inserted into
    the "bh=" tag of the [[DKIMM-Signature:]] header field.

  All tags and their values in the DKIM-Signature header field are
    included in the cryptographic hash with the sole exception of the
    value portion of the "b=" (signature) tag, which MUST be treated as
    the null string.  All tags MUST be included even if they might  
not be
    understood by the verifier.  The header field MUST be presented to
    the hash algorithm after the body of the message rather than with  
the
    rest of the header fields and MUST be canonicalized as specified in
    [[the€]] "c=" (canonicalization) tag.  The DKIM-Signature header  
field
    MUST NOT be included in its own h= tag.

5.1  Determine if the Email Should be Signed and by Whom

    A signer MUST NOT sign an email if it is unwilling to be held
    responsible for the message; in particular, the signer SHOULD ensure
    that the submitter has a bona fide relationship with the signer and
    that the submitter has [[tthe]] right to use the address being  
claimed.

5.4  Determine the header fields to Sign

    The From header field MUST be signed (that is, included in the h=  
tag
    of the resulting DKIM-Signature header field); any header field that
    describes the role of the signer (for example, the Sender or Resent-
    From header field if the signature is on behalf of the corresponding
    address and that address is different from the From address) MUST
    also be included.  The signed header fields SHOULD also include the
    [[Subjectt]] and Date header fields as well as all MIME header  
fields.

6.3  Compute the Verification

       INFORMATIVE IMPLEMENTATION NOTE:  Verifiers that truncate the  
body
       at the indicated body length might pass on a malformed MIME
       message if the signer used the "N-4" trick described in the
       informative note in Section 5.5.  Such verifiers may wish to  
check
       for this case and include a trailing "--CRLF" to avoid breaking
       the MIME structure.  A simple way to achieve this might be to
       append "--CRLF" to any "multipart" message with a body length; if
       the MIME structure is already correctly formed, this will appear
       in the postlude and will not be [[displayeed]] to the end user.

6.6  MUA Considerations

    This sort of [[addrress]] inconsistency is expected for mailing  
lists, but
    might be otherwise used to mislead the verifier, for example if a
    message supposedly from [email-masked] had a Sender
    address of [email-masked].

8.2  [[Misappropriateed]] Private Key

8.3  Key Server Denial-of-Service Attacks

    Since the key servers are distributed (potentially separate for each
    domain), the number of servers that would need to be attacked to
    defeat this mechanism on an Internet-wide basis is very large.
    Nevertheless, key servers for individual domains could be attacked,
    impeding the verification of messages from that domain.  This is not
    significantly different from the ability of an attacker to deny
    service to the mail exchangers for a given domain, [[aalthough]] it
    affects outgoing, not incoming, mail.

8.5  Replay Attacks

    In this attack, a spammer sends a message to be spammed to an
    accomplice, which results in the message being signed by the
    originating MTA.  The accomplice resends the message, including the
    original signature, to a large number of recipients, possibly by
    sending the message to many compromised machines that act as MTAs.
    The messages, not having been modified by the accomplice, have valid
    signatures.

    Partial solutions to this problem involve the use of reputation
    services to convey the fact that the specific email address is being
    used for spam, and that messages from that signer are likely to be
    spam.  This requires a real-time detection [[mechanissm]] in  
order to
    react quickly enough.  However, such measures might be prone to
    abuse, if for example an attacker resent a large number of messages
    received from a victim in order to make them appear to be a spammer.

B.1  Simple Message Forwarding

    In some cases the recipient may request forwarding of email messages
    from the original address [[tto]] another, through the use of a Unix
    .forward file or equivalent.

B.4  Mailing Lists

    There is a wide range of behavior in forwarders and mailing lists
    (collectively called "forwarders" below), ranging from those which
    make no modification to the message itself (other than to add a
    Received header field and change the envelope information) to those
    which may add header fields, change the Subject header field, add
    content to the body (typically at the end), or reformat the body in
    some manner.

    Forwarders which do [[noot]] modify the body or signed header  
fields of a
    message with a valid signature may re-sign the message as described
    below.

Appendix C.  Creating a public key (INFORMATIVE)

  This public-key data (without the BEGIN and END tags) is placed in
    the DNS.  With the signature, canonical email contents and  
[[puublic]]
    key, a verifying system can test the validity of the signature.  The
    openssl invocation to verify a signature looks like this:

-Doug

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html