Subject: [dane] 5280 section 6 and DANE usage etc.

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Feb 2012 20:43:40 +0000

Hi,

Martin's mail just now reminded me of something else I
meant to bring up.

I think there's a bit of work to be done to compare each
of the various DANE usage, selector and matching rules
(well matching rule 0 vs. 1 or 2) against section 6 of
5280. (Mostly, or maybe completely, related to the
"new" usage 2 if all those +1's keep coming for the "add
usage 3" idea.)

This is not really something that's easy enough to do
as a group in a few mails, but is rather something where
one or more people need to go off and sit down for a
few hours to look at the problem and come back with a
reasoned analysis.

I'm worried there are corner cases we might need to
document or prevent that we won't see if we just try to
figure this out by arguing. (Much as I like arguing:-)

Scott mentioned some cases related to private CAs
where different clients have different sets of TA
configured.

I'm also a little uneasy with oddities like policy
mappings and name constraints that have negative
restrictions that "pass down" a cert chain where
the TLSA value matches the middle of the chain. In
particular if usage 2 (the new variety) means treating
the TLSA RR as a TA, then that could generate
unexpected behaviour.

Note - I don't think this needs to or should lead to a
100 page essay for inclusion in the protocol draft.
While the analysis does need to be done, it might well
result in a very few new words in the document. And
those might be guidance (e.g. "Patient: doctor doctor it
hurts when I do this. Doctor: don't do that then.) or
maybe some 2119 language, or a mixture. I don't think
we'll know until someone's done that analysis.

And if someone has already done the work, great!
And if they posted it to the list, even better (except
it'll make me look dumb;-)

Cheers,
S

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 2 Feb 2012 23:20:54 +0200

> figure this out by arguing. (Much as I like arguing:-)

What about the following:

What does "comparison data for a certificate is malformed"
in section 4.4 mean? For matching type 0? For matching types
1 and 2?

Searching for "malformed" gets only 1 hit, in section 4.4.

I think that for types 1 and 2, comparision data is malformed
if and only if it is not the right length for matching type.

But for type 0? Never malformed? Malformed iff ASN.1 decoding
fails? Malformed if some PKIX checks don't pass (what checks)?

-Ilari

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Feb 2012 21:43:15 +0000

> What about the following:

I wasn't really asking about good or bad encoding.

More about the logically possible combinations given
DANE -14 and 5280 section 6.

S