On Sep 25, 2012, at 8:41 AM, Ben Laurie <[email protected]> wrote: > On 25 September 2012 16:09, Paul Hoffman <[email protected]> wrote: >> >> On Sep 25, 2012, at 8:00 AM, Ben Laurie <[email protected]> wrote: >> >>> On 25 September 2012 15:44, Henry Story <[email protected]> wrote: >>>> What I don't understand yet looking at draft-hoffman-dane-smime, is what >>>> key is going to be placed in DNS. Is it the signing key? The key that will >>>> sign the certificates? If so that could indeed be worthwhile putting in >>>> DNS. ( Though one could just as easily put that in http space ). If it is >>>> to put the client certificates themselves in DNS, then that seems much >>>> less of a good idea. >>> >>> Its pretty clear it could be either of those, though I have to say the >>> I-D doesn't really work properly in this respect. >> >> Can you say more? I'm not seeing why the signing or encrypting key would be >> different, but I could be missing something obvious. >> >>> It inherits the Certificate Usage field from 6698 - but 6698 >>> references TLS and TLS servers and things like that. I fear the I-D >>> really needs to redefine the usages in an S/MIME context. >> >> Why? Nothing in RFC 6698 says that the certificate or bare-ish key are only >> for signing. In fact, signing/encrypting isn't mentioned at all. > > Not even by me! > > But what is mentioned is, e.g. > > "Certificate usage 0 is used to specify a CA certificate, or > the public key of such a certificate, that MUST be found in any of > the PKIX certification paths for the end entity certificate given > by the server in TLS. " >
Ahhh, good point. We will definitely deal with that in our document. It appears more subtly in a few other places in 6698 as well. --Paul Hoffman _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
