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

"Larsen, Todd" <todd.larsen@nist.gov> Thu, 06 February 2014 17:28 UTC

Return-Path: <todd.larsen@nist.gov>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0BB1A0145 for <dane@ietfa.amsl.com>; Thu, 6 Feb 2014 09:28:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oT85Zdn1WLvq for <dane@ietfa.amsl.com>; Thu, 6 Feb 2014 09:28:55 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id DC2AE1A00F0 for <dane@ietf.org>; Thu, 6 Feb 2014 09:28:54 -0800 (PST)
Received: from BY2PR09MB029.namprd09.prod.outlook.com (10.242.35.139) by BY2PR09MB031.namprd09.prod.outlook.com (10.242.35.151) with Microsoft SMTP Server (TLS) id 15.0.868.8; Thu, 6 Feb 2014 17:28:52 +0000
Received: from BY2PR09MB029.namprd09.prod.outlook.com ([169.254.8.238]) by BY2PR09MB029.namprd09.prod.outlook.com ([169.254.8.162]) with mapi id 15.00.0868.013; Thu, 6 Feb 2014 17:28:51 +0000
From: "Larsen, Todd" <todd.larsen@nist.gov>
To: "'viktor1dane@dukhovni.org'" <viktor1dane@dukhovni.org>
Thread-Topic: [dane] I-D Action: draft-ietf-dane-smime-03.txt
Thread-Index: Ac8jWg0qKEAZ9sLQQESqk0FDFqbpnA==
Date: Thu, 6 Feb 2014 17:28:51 +0000
Message-ID: <41938fd202ba460285b59132c29ac826@BY2PR09MB029.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [129.6.140.15]
x-forefront-prvs: 0114FF88F6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(51704005)(24454002)(79102001)(85852003)(56776001)(80022001)(81342001)(81542001)(83072002)(87936001)(69226001)(46102001)(90146001)(54316002)(94316002)(2656002)(51856001)(47976001)(66066001)(49866001)(4396001)(50986001)(87266001)(47736001)(86362001)(56816005)(95416001)(53806001)(74366001)(80976001)(19580395003)(15975445006)(76176001)(81816001)(85306002)(47446002)(54356001)(92566001)(74662001)(76576001)(77982001)(76786001)(59766001)(74876001)(74316001)(63696002)(94946001)(74706001)(65816001)(77096001)(83322001)(93516002)(76482001)(33646001)(74502001)(31966008)(19580405001)(93136001)(76796001)(81686001)(24736002)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR09MB031; H:BY2PR09MB029.namprd09.prod.outlook.com; CLIP:129.6.140.15; FPR:5C9CF5B7.AF268441.6ECF7FB7.4EE552FD.20339; InfoNoRecordsA:1; MX:1; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
Cc: "'dane@ietf.org'" <dane@ietf.org>
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 17:28:58 -0000

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