Re: [dane] draft-ietf-dane-smime

"Osterweil, Eric" <eosterweil@verisign.com> Sat, 01 November 2014 20:38 UTC

Return-Path: <eosterweil@verisign.com>
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 F01C11A00BF for <dane@ietfa.amsl.com>; Sat, 1 Nov 2014 13:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.079
X-Spam-Level:
X-Spam-Status: No, score=-3.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URI_HEX=1.122] 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 IDWwpjqMVuMA for <dane@ietfa.amsl.com>; Sat, 1 Nov 2014 13:38:47 -0700 (PDT)
Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59071A0016 for <dane@ietf.org>; Sat, 1 Nov 2014 13:38:46 -0700 (PDT)
Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKVFVE1qUv5XmPXpAHrHD61zgsFaElh58K@postini.com; Sat, 01 Nov 2014 13:38:46 PDT
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id sA1KcjCp031888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dane@ietf.org>; Sat, 1 Nov 2014 16:38:45 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Sat, 1 Nov 2014 16:38:44 -0400
From: "Osterweil, Eric" <eosterweil@verisign.com>
To: "dane@ietf.org" <dane@ietf.org>
Thread-Topic: [dane] draft-ietf-dane-smime
Thread-Index: AQHP2+CXduy9obN06UaH3lWvHXXI5ZxKvpuAgAAs6gCAAcejgA==
Date: Sat, 1 Nov 2014 20:38:44 +0000
Message-ID: <F6025049-7FEC-4286-AABF-AB1E47452742@verisign.com>
References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <39C76846-F695-435D-9A5C-6989D06E9573@verisign.com> <20141031172840.GM19103@mournblade.imrryr.org>
In-Reply-To: <20141031172840.GM19103@mournblade.imrryr.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <5A31BEFFB988AE4D87859BC899046FCC@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/QCD6YWKks_3la82kjIAO3NZWHNI
Subject: Re: [dane] draft-ietf-dane-smime
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: Sat, 01 Nov 2014 20:38:50 -0000

On Oct 31, 2014, at 1:28 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:

> On Fri, Oct 31, 2014 at 02:47:19PM +0000, Osterweil, Eric wrote:
> 
>>   4 or REJECT -- REJECT is used by the domain owner to assert that at
>>   the time of querying the DNS, this user's certificate MUST be considered
>>   invalid for the requested function (i.e. signature or encryption).
>>   This is a stronger assertion than a failed certificate validation check.
>>   Possible usage scenarios include de-authorizing stale employee
>>   credentials by selectively overriding TAs that are used to authorize
>>   entire organizations.
> 
> Which certificate is being invalidated? Why is this needed?  What's
> wrong with publishing a "3 1 1" association with an impossible key?

Thanks for sending this note!  The idea here is to say, ``this specific key (which an RP may or may not have used before) is not to be used for this inbox, at this time.''  An impossible key just means _that_ key can’t be used.  This idea isn’t trying to disable an email inbox, just ensure that a key that may pass (or may have passed, once upon a time) other verification is unambiguously de-authorized.

> 
>    $ openssl dgst -sha256 </dev/null
>    (stdin)= e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
> 
>    ;; User's public key cannot be empty, so will never match this record.
>    ;;
>    1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._sign._smimecert.example.com.  IN SMIMEA ( DANE-EE SPKI SHA2-256 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 )
> 
>> 2.1.4.  Certificate Access Field
>> 
>> This one octet value indicates an alternative method for certificate
>> discovery.  Some domain owners may not want to publish user
>> certificates via DNS but may want to use the DNS to advertise the
>> means to access them.  If full user certificates are not included in
>> the Certificate Association Data this field MAY be used to indicate
>> how the user's certificate can be obtained.  The RDATA certificate
>> association data MUST be used to validate certificates obtained by
>> the alternative method.
>> 
>>   0 or NO: No alternative method advertised.
>> 
>>   1 or NAPTR : NAPTR record available.  The same domain name used
>>   for this SMIMEA request MAY be used again with type NAPTR
>>   [RFC3403] to retrieve the URI for certificate access.
>> 
>>   2 or WF: X.509 certificates available in WebFinger [RFC7033].
> 
> Once this field is not "NO", what is the meaning of the associated
> data field carried with such a record?  Is it still providing a
> valid DANE association?

Yeah, I would say so.  I think this is the case most akin to the TLSA model.  I would say:
0 == use TLSA-style DANE
1 == look for info from a service that is described by NAPTR
2 == Look for info served from a WebFinger service.

> If so, when would one also need to use the "alternative access”?

I think this would allow the provisioning system to either put certs in DNS, or put them elsewhere and have DNS point to where.  I’m not sure I’m answering your question though?

> If not, how is this a DANE SMIMEA record?  At the very least changing
> the semantics of the associated data should lead to a new selector
> or usage, but more likely an entirely separate DNSSEC validated
> record, at which point the application can just query for these
> alternative records if it sees fit.  Why does SMIMEA need to
> explicitly signal the use of other mechanisms?

I don’t understand this comment, but I think it stems from a miscommunication above.  This field would be used to say, ``look over there for the cert.’’  If the cert info is encoded in SMIMEA, or its retrieval is outside of the DANE scope (i.e., the cert is included in an email message), then this field is left as 0 (not used).

Does that make more sense?

Eric