On Dec 3, 2013, at 7:17 PM, Peter Saint-Andre <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In RFC 6125, Jeff Hodges and I tried hard to define some terminology
> related to certificate checking in TLS. That terminology might not be
> ideal, but I'd like to see if we can align draft-ogud-dane-vocabulary
> with the RFC 6125 terms.
>
> In particular, RFC 6125 uses the term "source domain" to refer to the
> fully qualified domain name that a TLS client expects to find in the
> certificate (or, in DANE, potentially the key) that is presented by
> the TLS server. RFC 6125 also uses the term "derived domain" to refer
> to a domain name (or host name) that the client has derived from the
> source domain in an automated fashion (e.g., via a DNS SRV record).
>
> As far as I can determine, draft-ogud-dane-vocabulary uses the terms
> "Query [Name]" and "Final [Name]" for something like "source domain"
> and "derived domain". However, draft-ogud-dane-vocabulary also uses
> the terms "Service Specification Records" and "Service Address
> Records" in a way that might be similar, although I confess that I
> don't really grok draft-ogud-dane-vocabulary in fullness and the
> latter two terms are unclear to me.
Peter,
Thanks asking this question,
You made me read RFC6125 and to my horror the vocabulary there is attempting
similar things as I'm doing in my draft, but in section 1.8 I realized that you
might have taken a
shortcut that leads to a incomplete specification i.e. you are not taking into
account the effects of
CNAME and DNAME records on the resolution, in particular DNAME requires careful
rules
as to the names used to present to the servers. (my guess is this is where the
"i don't really grok"
comment comes from) (I think NAPTR has similar effects).
"Source domain" definition is a good example of this. In -vocabulary- draft
the application issues query for "query name" where it is expecting to find the
"Service Specification Records".
but DNAME/NAPTER/CNAME rules may rewrite the name sent to application server
to the "resulting name" from the query
thus the term "Offered Name".
For HTTP Service Specification Records == Service Address records i.e. address
record is the service specification,
but Jabber uses SRV records for the Service Specification Records
and the Service Address Records are associated with the servers listed in the
SRV RRset.
To a large extent I think the differences we see are due to the different
approaches, i.e. you are attempting to word rules for existing applications.
I'm defining rules that are general and ignore the names existing applications
have used an concentrate on concepts that then can be used
by application specifications.
I wanted to create definitions that allow minimal DNS related text inside a
DANE application specification
(not sure I'm there yet).
>
> Naming is hard, and I hope we can get it right.
>
Naming of concepts is hard, definitions are hard,
understanding the nuances of interaction of multiple protocols is even harder
:-)
Olafur
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSnnSIAAoJEOoGpJErxa2pIPcP/3ynoIh5Xn1oBXMtf1Tj4yyZ
> sJc2kEoA1r49CLCz3TsqHaQonB/lK6tZP0WGYoNobj/C6Vd9U8RQW2TElWM7fVo1
> ltZmBA0Tx6KHv/XQmnNsrKVbiueqMui5tWvyHDE/x/Wt18lJPM1n4LdY+xkR4O62
> en7PCNTLNxAjkpjPKrEqbp0YYiI67rsnKxNOEJkjry3l+j9FOYlPyBtHAyRZISgV
> YKy6eIyIEGYOfIXtiiEYPx3UNgIuOLpozu5OWAmypdP6xTfXYmHpAX9HVD7lPPqK
> ZOGzz61RYDSid186uBQGizahaAabRvIwayQ8ZZTr7C+JYW//CckRRrC04R12h9K+
> qNfnzSzf11x01VMfEK2V7muD2uqi28LBXsC/vY2E/r6FRxAp7BS1OZccFK224NnK
> xI+ETnMsl/ZaWIOKhyJk44bWODWr6ij1Gxen3UoEIsU90akFmzCuCEdbdgf0lATr
> wX71rVUi5O/ytHQZ/YfhOtc2j7qbrnfSc7KZcgr7X7IkhexP3/nVKtuziqdrbL4U
> i7pVh5xlgyTszEyowyKWIjr0+J98Llbdz0Xs1hTOTwEONW4cx7TsUd05cwdmoc4G
> KLabfuUTYKp4NslfIV4smBIl2uzrYUaz0ACjLQSrzk4dNGZAj0L6IlyS92g211Pl
> WEIrV0m+zIhv6K1ffWiS
> =VUnT
> -----END PGP SIGNATURE-----
> _______________________________________________
> dane mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dane
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
