On Oct 3, 2013, at 4:31 PM, Wes Hardaker <[email protected]> wrote:
> Warren Kumari <[email protected]> writes: > > Looks like a good start and thanks for writing it Olafur! But it's not > ready for publication without some cleanup. Too many standard-things > are missing, such as acronym expansion and I'd feel guilty passing it > to the RFCEditors without us having caught such things. > > Nits: > > 1) > handle any case use in the input> The expectation is that by using > ^^^^^^ > ?????? > > 2) my alternate suggested should descriptions (I like the acronyms > themselves): > > +-------+----------+-------------------------------------+-----------+ > | Value | Acronym | Short Description | Reference | > +-------+----------+-------------------------------------+-----------+ > | 0 | PKIX-TA | PKIX Validated CA Reference | [RFC6698] | > | 1 | PKIX-EE | PKIX Validated End-Entity Reference | [RFC6698] | > | 2 | DANE-TA | Validation TA Reference | [RFC6698] | > | 3 | DANE-EE | Domain-issued certificate Reference | [RFC6698] | > | 4-254 | | Unassigned | | > | 255 | PrivCert | Reserved for Private Use | [RFC6698] | > +-------+----------+-------------------------------------+-------------+ > > Table 1: TLSA Certificate Usages > > 3) intro text (1 sentence?) to sections needed and expansion of other > acronyms earlier in the document (PKIX, EE, ) > > 4) ideally space align the section 3 records > > inserted one space here > v > _666._tcp.first.example. TLSA PKIX-CA CERT SHA2-512 {blob} > _666._tcp.second.example. TLSA DANE-TA SPKI SHA2-256 {blob} > > 5) security considerations > > There is definitely something to consider if someone publishes both > name records along with number records, and the client only parses > number records. What happens with this: > > _666._tcp.first.example. TLSA 3 1 1 {blob} > _666._tcp.first.example. TLSA DANE-TA SPKI SHA2-256 {blob} > > Something needs to be said for that case; what would an existing > implementation do? drop both? take one? Either way, it should be > discussed/mentioned. > <no hats> Um, I'm a little confused (or you are, but probably it is me…) I'm not quite sure what you are menacing by client here. If it is something like a stub resolver / application, it doesn't really see either of the above -- it just gets a big bag-o-bits. If you are talking about someone putting this in a zone file, whatever eats the zone file would continue to do what it does with any other record. Example: example TYPE16 "foo" example TXT "bar" These are two text records, one with content "foo" and one with content "bar" If someone does: _666._tcp.first.example. TLSA 3 1 1 {blob} _666._tcp.first.example. TLSA DANE-TA SPKI SHA2-256 {blob} it is the same as if they had entered: _666._tcp.first.example. TLSA 3 1 1 {blob} _666._tcp.first.example. TLSA 2 1 1 {blob} (or, if they have the same usage / selector / selector / match and {blob} then it is the same as if they had just entered the info twice). If whatever eats the zone file is too old to understand the new enums / names, then it will continue to do what it does now with unknown garbage: _666._tcp TLSA COOKIEMONSTER BARNIE FRED 1234… wkumari@vimes:~/tmp$ named-checkzone example.com example.com dns_rdata_fromtext: example.com:26: near 'COOKIEMONSTER': not a valid number example.com: file does not end with newline zone example.com/IN: loading from master file example.com failed: not a valid number zone example.com/IN: not loaded due to errors. I suspect that I'm missing something / we are talking past each other… W > -- > Wes Hardaker > Parsons > -- "Let's just say that if complete and utter chaos was lightning, he'd be the sort to stand on a hilltop in a thunderstorm wearing wet copper armour and shouting 'All gods are bastards'." -- Rincewind discussing Twoflower (Terry Pratchett, The Colour of Magic) _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
