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

[Viktor Dukhovni <[e-mail]>]

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.