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.
--
Wes Hardaker
Parsons
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
