Mostly 3.

The main difference is how TLSA records are located, right?  Something like 
"lhs._at.rhs" instead of "_port._proto.name".  The validation rules are 
PKIX-based, not TLS-based, so they can be re-used for S/MIME. 

So it seems like the S/MIME draft should just say something like:
1. Here's how you find a TLSA record for an email address (replaces Section 3 
of RFC 6698)
2. Everything else is the same as in RFC 6698.




On Sep 4, 2012, at 11:07 AM, Paul Hoffman wrote:

> Greetings again. As those of you who were at the IETF meeting in Vancouver 
> (or those who read the minutes at 
> http://www.ietf.org/proceedings/84/minutes/minutes-84-dane) know, Jakob and I 
> are unsure about how the WG might want our draft to look. The current version 
> of the draft expires in a few days, so we have an opportunity to make major 
> changes now.
> 
> From our presentation:
> What should be in the doc?
> 1.  Copy whole DANE-for-TLS RFC and make needed changes
> 2.  Copy structure of DANE-for-TLS RFC and point to it but don’t copy much
> 3.  Say “we assume you read and understood DANE-for-TLS, and here are the 
> relevant differences”
> 
> If the WG can come to rough consensus in the next few days, we'll try to get 
> the changes in before the doc expires; otherwise, we'll do an uninteresting 
> bump draft and make the content changes later.
> 
> --Paul hoffman
> _______________________________________________
> dane mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dane

_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane

Reply via email to