On Wed, Apr 17, 2013 at 09:40:59AM -0700, Paul Hoffman wrote:
> All of what you say about the IETF needing more input from
> implementers is true. And it is also irrelevant to the discussion
> of trying to jam that input into the errata for an RFC. You don't
> seem inclined to write down your implementation experience in
> operational RFCs, but it sounds like Viktor is.
Though I don't much mind what ultimate form the operational
requirements for TLSA "2 ? [12]" take, I'd strongly prefer to see
this discussed in 6698 itself, rather than a new operational RFC.
A separate RFC will be easily missed, and the operational requirement
will be less well publicized.
If the text is not changed to "MUST" per the erratum, the right
thing IMHO is to add a subsection somewhere, that explains the
practical need to provide the TA cert in most circumstances.
Something along the lines of:
4.2 TLSA certificate usage 2 digest associations.
Since with certificate usage "2" the client cannot generally
be presumed to have its own independent copy of the associated
trust-anchor certificate or public key, when publishing TLSA
certificate usage 2 associations with a digest matching type
(e.g. "1" or "2"), a server that communicates with clients
outside a small set known by the server operator to be
pre-configured with any required trust-anchor certificates must
provide a corresponding trust-anchor certificate to the client
via the SSL server certificate message "certificate_list" (
https://tools.ietf.org/html/rfc2246#section-7.4.2) Failure to
provide the certificate in the server "certificate_list" will
lead to interoperability problems.
I wrote "must" in lower-case, in its informal natural language
sense, predicated on the servers need to interoperate on the public
Internet, not a home LAN. Can we find a reasonable home for such
language in 6698? My guess is that Section 4 is not a bad place,
but I am open to other suggestions.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
