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 [email protected] https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
