On Feb 6, 2014, at 11: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/ +1 > 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. I agree that we should discuss this. With PGP, I can use a key with a diff email than the account from which I send it (for ex, I can use my spam account and rely on my full name and friends who know me to make the logical leap), do we all want DANE to outlaw this for S/MIME? > 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. > > 3. Section 2, para 1: First sentence - see the last item. It may be not > an EE certificate that is being associated. > > 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. > > 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. > > If problem B is what the document is trying to solve, then there are a > number of issues that need to be addressed: > > a) The set of certificate usages needs to be restricted to 1 and 3 so that > one will get a certificate about the EE > b) The set of certificates selectors needs to be restricted to 0 so that the > certificate is always present > c) The matching type needs to be restricted to 0 so that the certificate is > always present. Actually, Scott Rose's suggestions on this draft cover a mechanism to overcome this, by pointing at a place to learn certs. I think this commentary helps to further underscore the utility of that. Eric _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
