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

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 31 October 2014 17:28 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 BF41A1A0102 for <dane@ietfa.amsl.com>; Fri, 31 Oct 2014 10:28:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.778
X-Spam-Level:
X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URI_HEX=1.122] autolearn=no
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 y_s_Iug8LnpX for <dane@ietfa.amsl.com>; Fri, 31 Oct 2014 10:28:41 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6E71A001C for <dane@ietf.org>; Fri, 31 Oct 2014 10:28:41 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7E08A2AAD9C; Fri, 31 Oct 2014 17:28:40 +0000 (UTC)
Date: Fri, 31 Oct 2014 17:28:40 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20141031172840.GM19103@mournblade.imrryr.org>
References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <39C76846-F695-435D-9A5C-6989D06E9573@verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <39C76846-F695-435D-9A5C-6989D06E9573@verisign.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/GS6zrML1v0YpTCH5Of1RA6c8LGw
Subject: Re: [dane] draft-ietf-dane-smime
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
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: Fri, 31 Oct 2014 17:28:43 -0000

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?

    $ 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?

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

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?

-- 
	Viktor.