On Thu, May 07, 2015 at 03:12:36PM +0200, nudge wrote:
> Perhaps it's just me, but doesn't this section have a rather obvious error
> in it ?
>
> 2.1. Example TLSA record
>
> In the example TLSA record below:
>
> _25._tcp.mail.example.com. IN TLSA PKIX-TA Cert SHA2-256 (
> E8B54E0B4BAA815B06D3462D65FBC7C0
> CF556ECCF9F5303EBFBB77D022F834C0 )
>
> The TLSA Certificate Usage is DANE-TA(2), the selector is Cert(0) and
> the matching type is SHA2-256(1). The last field is the Certificate
> Association Data Field, which in this case contains the SHA2-256
> digest of the server certificate.
Thanks, a typo. Likely introduced when the numbers were made
symbolic. Are there yet (or expected to be) any DNS zone file
parsers that consume the symbolic TLSA paramter names? Similarly
any wire DNS record decoders that present the human-readable output
with TLSA parameters in symbolic form?
That is, should the examples use the symbolic names in the record
syntax, and not just in the text?
--
Viktor.
Patch below:
--- a/draft-ietf-dane-ops
+++ b/draft-ietf-dane-ops
@@ -306,7 +306,7 @@
<figure>
<artwork>
-_25._tcp.mail.example.com. IN TLSA PKIX-TA Cert SHA2-256 (
+_25._tcp.mail.example.com. IN TLSA DANE-TA Cert SHA2-256 (
E8B54E0B4BAA815B06D3462D65FBC7C0
CF556ECCF9F5303EBFBB77D022F834C0 )
</artwork>
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
