On Feb 6, 2014, at 8:01 PM, Jim Schaad <[email protected]> wrote:
> 1. Section 1, para 1: The first two sentences imply that a single > certificate is going to be present in a message. While this is true in a > large number of cases, there are many times in which more than one > certificate may be present. These include having different signing an > encrypting keys or intermediate certificates for chain building. I would > request that the first two sentences be modified to make certificate be > plural. s/a certificate. This certificate assists/certificates. These > certificates assist/ Done. > 2. Section 1, para 1: The last sentence is missing a step in the description > of the process of validating that certificate is bound to a purported > sender. The current text just looks at the validation process and does not > talk about what is necessary to check the binding itself. In most cases, > but not all, this involves looking for the senders email address in the > certificate itself. (In other cases some type of external database would be > required or one could say that the sender and the signer may not be the same > person even though the signature itself validates.) > > One thing about this document that I don't remember having seen on the list > is the question of doing the binding check between the senders address and > the contents of a certificate. Is it going to be considered sufficient if > one does the DNS look up for the certificates? Is it only a sufficient > check for some types of SMIMEA records but not for others? I.e. EE > certificate vs CA or TA certificate. > > The document needs to distinguish between the steps of validating and > trusting a certificate and doing the binding between an email address and a > certificate. While it is possible to both in some cases, in others these > need to be distinct steps. Nope, that's out of scope (and we have added a sentence to that effect). This document should *not* change, nor even repeat, the identity-binding rules for S/MIME. > 3. Section 2, para 1: First sentence - see the last item. It may be not > an EE certificate that is being associated. It is *always* an EE cert that is being associated. It may not be an EE cert that was gotten through SMIMEA. I have added wording to that effect. > 4. Section 3, step 1: It would be nice to be explicit that you are doing a > UTF8 Unicode string to octet string transformation before doing the Base32 > conversion. The referenced document says that this is the case for SMTP > submission in one mode, but it is not clear that the SMTP submission format > is what we are doing here. Being explicit would be helpful. Yep. > There are two general problems that people are looking to solve with this > document. > > A) I have an email address and a certificate, I want to validate the > certificate and check the association between the certificate and the email > address. > > B) I have an email address, I need to find a certificate. > > At present I believe that this document is addressing problem A and not > problem B. It would be good to state that problem B is out of scope in the > introduction if this is the case. As this is the debate that has happened later in the WG, we have not added that to the new draft, but we expect to have to address this in a later draft. It is a WG-wide issue, not related just to SMIMEA. I have added a placeholder in the introduction for this topic. I'll post the new draft after PaulW posts his with the new hash-of-LHS text. --Paul Hoffman _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
