In message <[email protected]>,
nudge writes:
> On Mon, 4 May 2015, at 07:37 AM, Viktor Dukhovni wrote:
> >
> > Really, nobody has any comments? Surely the document is not that
> > perfect. :-) If at all possible, please provide feedback soon!
> >
> > --
> > Viktor.
>
> Hi,
>
> 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 )
Which is a invalid TLSA record. "PKIX-TA", "Cert" and "SHA2-256"
should all be numbers.
RFC6698 2.2. TLSA RR Presentation Format
The presentation format of the RDATA portion (as defined in
[RFC1035]) is as follows:
o The certificate usage field MUST be represented as an 8-bit
unsigned integer.
o The selector field MUST be represented as an 8-bit unsigned
integer.
o The matching type field MUST be represented as an 8-bit unsigned
integer.
o The certificate association data field MUST be represented as a
string of hexadecimal characters. Whitespace is allowed within
the string of hexadecimal characters, as described in [RFC1035].
This is how named parses TLSA records. Note there is *no* handling of
non numbers. There is *no* intention to change this.
/*
* Certificate Usage.
*/
RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number,
ISC_FALSE));
if (token.value.as_ulong > 0xffU)
RETTOK(ISC_R_RANGE);
RETERR(uint8_tobuffer(token.value.as_ulong, target));
/*
* Selector.
*/
RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number,
ISC_FALSE));
if (token.value.as_ulong > 0xffU)
RETTOK(ISC_R_RANGE);
RETERR(uint8_tobuffer(token.value.as_ulong, target));
/*
* Matching type.
*/
RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number,
ISC_FALSE));
if (token.value.as_ulong > 0xffU)
RETTOK(ISC_R_RANGE);
RETERR(uint8_tobuffer(token.value.as_ulong, target));
Now if you want to have descriptions then do something like this:
_25._tcp.mail.example.com. IN TLSA (
0 ; PKIX-TA
0 ; Cert
1 ; SHA2-256
E8B54E0B4BAA815B06D3462D65FBC7C0
CF556ECCF9F5303EBFBB77D022F834C0 )
Don't have unparsable records.
Mark
> 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.
>
>
>
> ---- Ian Maddison
>
> _______________________________________________
> dane mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dane
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
