Re: [dane] Question regarding RFC 8162

[Tawhidul Islam <[e-mail]>]

Hi Metin,

I’m Minar, an author of daneportal.net where we implement SMIMEA records in federated DANE cert provisioning. I’m happy to hear more DANE discussion! :)

You wrote:

So, for [e-mail]<mailto:[e-mail]> through [e-mail]<mailto:[e-mail]> , you would hit *.example.edu<http://secure-web.cisco.com/1m9sVPSr2H8pVH1HJOAF1RrIiLKJY3LofJCjye7q1iYK5IbIreyFPPI0SLhIjFKex1XPcUjIRbccOrw0hC2L5x5uLgtak3TqTOiaNlg_vivDAEt2s0j_ojpa2Zx2_9igqF6Np41tphXKyCDPUgG1Ucm6rahLlCjRvFvjbzyMIawyhcjURZFhaZ13yPe6vR9q5_KBZXpgON91R_9N8OUIlHzbmyyqmvYgfQwtmQtkF97iN5uJNI7Px1oNC-xw6SB-a1I83XYkwEBYnxWPxF9YciGZKXVXTHH2LpqUDgp4S4g32KfZNMOp5V9Ilas_RsMC2h1uEioyfQ21VBXr0IFO5mBfooMrApAmdMXEtJMebgokkA2G9-a8sgShgK41jx0dUW8R9OT8A7wucbfM5Ju1kp1jCu6Dj9mbtFd2I5gd5SEc4F-MxJBRzgEKD-teET4CN/http%3A%2F%2Fexample.edu%2F> SMIMEA, which would return the root cert.  Does that make sense?

However, it remained unclear to me if that is intended use? (And if so, how should anybody know as it is not mentioned in RFC 8162?)

I’m also curious about that. Maybe this merits a clarification update in an RFC?

It is recommended to use two separate certificates, one for encrypting and one for signing. If that recommendation is followed, how does RFC 8162 / RFC 6698 allow for this? Is it possible to have two records for the same user in the DNS (I’m not very familiar with the internals of DNS)?

It is totally possible to have many records for the same user. E.g. for [e-mail]<mailto:[e-mail]>, in the DNS this is as simple as serving multiple SMIMEA records for the “<jdoe_hashed>._smimecert.example.com” name.
Absurd example: Jane Doe could have 7 certificates all being served at the same time because she likes to change her signing key every day
DANE clients (e.g. using libCanute) could end up using any suitable cert for encrypting, and should try all suitable certs for verification (taking into account the USAGE field/related CA constraining SMIMEA records).

How could we identify which is which, unless the full certificate (not only the key) is stored in the DNS record? Even then, wouldn’t it be more practical to use different type values, so the client can specifically look for the the record it needs?

You’ve hit the mark -- the attributes are in the cert like usual if it is the full cert (SELECTOR=0). But that leaves the shortcoming that clients are doing extra processing/bigger DNS responses.

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 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”, and her 7 signature certs could all be in “<hash>._sign._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).

(Psst that old RFC draft that included this discussion is readable in the Canute docs: https://github.com/gmu-msl/canute/blob/main/docs/draft-ietf-dane-smime-02-srose.txt though the current resolver in that repo is strictly RFC compliant)

That’s my two cents – please do touch back with any more discussion / questions! I’d love to collaborate and increase the presence of DANE / SMIME implementations.

-Minar

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

________________________________
From: dane <[e-mail]> on behalf of Metin Savignano <[e-mail]>
Sent: Thursday, September 15, 2022 10:37:04 AM
To: Eric Osterweil <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [dane] Question regarding RFC 8162

Hi Eric, hi everyone,

I haven’t seen any reaction my last message yet. I had hoped to get some clarification.

You wrote:

So, for [e-mail]<mailto:[e-mail]> through [e-mail]<mailto:[e-mail]> , you would hit *.example.edu<http://secure-web.cisco.com/1m9sVPSr2H8pVH1HJOAF1RrIiLKJY3LofJCjye7q1iYK5IbIreyFPPI0SLhIjFKex1XPcUjIRbccOrw0hC2L5x5uLgtak3TqTOiaNlg_vivDAEt2s0j_ojpa2Zx2_9igqF6Np41tphXKyCDPUgG1Ucm6rahLlCjRvFvjbzyMIawyhcjURZFhaZ13yPe6vR9q5_KBZXpgON91R_9N8OUIlHzbmyyqmvYgfQwtmQtkF97iN5uJNI7Px1oNC-xw6SB-a1I83XYkwEBYnxWPxF9YciGZKXVXTHH2LpqUDgp4S4g32KfZNMOp5V9Ilas_RsMC2h1uEioyfQ21VBXr0IFO5mBfooMrApAmdMXEtJMebgokkA2G9-a8sgShgK41jx0dUW8R9OT8A7wucbfM5Ju1kp1jCu6Dj9mbtFd2I5gd5SEc4F-MxJBRzgEKD-teET4CN/http%3A%2F%2Fexample.edu%2F> SMIMEA, which would return the root cert.  Does that make sense?

However, it remained unclear to me if that is intended use? (And if so, how should anybody know as it is not mentioned in RFC 8162?)

And please let me ask a second question:

It is recommended to use two separate certificates, one for encrypting and one for signing. If that recommendation is followed, how does RFC 8162 / RFC 6698 allow for this? Is it possible to have two records for the same user in the DNS (I’m not very familiar with the internals of DNS)?

How could we identify which is which, unless the full certificate (not only the key) is stored in the DNS record? Even then, wouldn’t it be more practical to use different type values, so the client can specifically look for the the record it needs?

Please forgive me for dumb questions.

Thanks!
Metin