Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt

Victor,

Good questions. Here are my answers. 
Not advocating a position.

> On Thu, Feb 06, 2014 at 03:36:57PM +0000, Larsen, Todd wrote:
>
>> Agreeing with Eric's point to ensure the UC 4 discussion doesn't focus 
>> on certificate revocation.
>> 
>> Use case 4 for SMIMEA does not revoke a certificate. Rather, the 
>> domain revokes an S/MIME user. In contrast to any evidence the user 
>> has to claim association, the domain is positively stating that user X 
>> is not valid for SMIME applications. I consider that substantially 
>> different from the absence of a DANE record (or addition of a bogus 
>> record to force validation failure).
>
>This is problematic because I expect that SMIMEA like TLSA generally yields 
>an RRset, not a single record. What would be the semantics of an RRset with 
>two RRs one with CU=4 and another with CU=2?
>

CU=4 trumps CU=2. Other records present with CU=4 would clearly 
indicate a misconfiguration, but must be accounted.

This complicates validation logic. It means checking for CU=4 in entire RRSET 
instead of declaring valid on first match.

One example of use could be for a domain to wildcard CU=2 record so
all certificates signed by the organization are considered valid by default. 
Disallowed users receive CU=4 for lifetime of TA cert. NSEC3 may not be 
necessary as public knowledge of CU=4 list might be desirable. 

(Not suggesting this in lieu of CNAMEs to CU=2 record(s), just presenting possible use case)

>It still seems simplest to list no RRs for a user to indicate that there are no 
>keys for that user.
>
>If CU=4 is supposed to disavow all keys for a user, what is the meaning of the 
>selector, matching type and associated data, ...

selector, matching type and associated data have no meaning for CU=4. The fields
are present solely to maintain consistency with the SMIMEA format

--
 Viktor.
_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane