On Fri, Nov 15, 2013 at 05:45:04AM +0000, Viktor Dukhovni wrote:
> Basically, when all the RRs for a particular mtype (that would otherwise
> be considered strongest present) are a-priori unusable due to malformed
> data, we can't be sure whether even the "selector" and "mtype" are valid,
> after all the record is junk. So it seems reasonable to not impute any
> meaning to such a record's meta-data in the face of broken data.
A closer reading of 6698 seems to support the above:
https://tools.ietf.org/html/rfc6698#appendix-B.2
before any processing of the TLSA RRset, we see:
for each R in TLSArecords {
// unusable records include unknown certUsage, unknown
// selectorType, unknown matchingType, erroneous RDATA, and
// prohibited by local policy
if (R is unusable) {
remove R from TLSArecords
}
}
with supporting language in https://tools.ietf.org/html/rfc6698#section-4.1
If a certificate association contains a certificate usage, selector,
or matching type that is not understood by the TLS client, that
certificate association MUST be considered unusable. If the
comparison data for a certificate is malformed, the certificate
association MUST be considered unusable.
so certainly the malformed "X Y 0" cases are explicitly out of
scope, and I think so are the cases where the digest length is
absurd.
So if the rest of the digest agility proposal is acceptable, the
semantics of unusable records in this case are perhaps already
defined the way I thought most natural.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
