Re: [dane] Question regarding RFC 8162

[Metin Savignano <[e-mail]>]

Hi Minar, 

I appreciate your response, and I hope these suggestions are going to be considered in the RFC.
 
> I’m happy to hear you bring this up, since I also agree that we are missing an important mechanism for clients to specifically search for a signature vs encrypting cert record on DNS -- it’s unfortunate the current RFC did not address this.
>  
> There was an older idea bounced around that we implemented for daneportal.net <http://daneportal.net/> of having dedicated meta domains for those two:
> E.g. Jane Doe’s encrypting cert would be an SMIMEA record under “<hash>._encr._smimecert.example.com <http://smimecert.example.com/>”, and her 7 signature certs could all be in “<hash>._sign._smimecert.example.com <http://smimecert.example.com/>”.
> For the basic RFC compliance, this is done in addition to putting a copy of all those records in the usual <hash>._smimecert zone.
> Clients that are wise to that non-standard _encr/_sign domains could speed up cert resolution with that pathway, but could always fallback to the standard _smimecert domain. The cert attributes are only considered if the USAGE calls for it (PKIX-CA/EE constrained).

Shouldn’t this become part of the standard? 

Due to the relatively large size of SMIMEA records (if they hold the full certificate), I think it should be avoided to generate unnecessary traffic. If separate certificates are used for encrypting and signing, then it may desirable to transfer only the one that is needed. On the other the MUA will probably need both sooner or later, so perhaps it’s not so much of real world problem as I was thinking.

I guess I understand that your approach is a bit different than our scenario. Our original idea was that it should be possible to retrieve a company’s own root certificate from the DNS, so to verify any S/MIME certificate that has been issued by it. This idea implies that the S/MIME certificate itself has already been received by the MUA in a signed email and only needs to be verified.

Your approach seems to go a step further by trying to enable the MUA to send an encrypted email to some other user of whom it does not have received a certificate at all yet, right?

I think both scenarios are absolutely valid and should be considered by this RFC.

Metin