Re: [dane] I-D Action: draft-ietf-dane-srv-04.txt

[Matt Miller <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2/12/14, 12:54 PM, Viktor Dukhovni wrote:
> On Wed, Feb 12, 2014 at 10:32:03AM -0700, Matt Miller wrote:
> 
>>> DANE-EE(3) CU records need to have meaningful semantics for the
>>>  publisher.  For example for a publisher to use the same 
>>> certificate for many SRV hosts or without worrying about using
>>> a matching name, the use of non-use of name checks must be
>>> specified precisely.
> 
>>> Therefore I would suggest that the "MAY be ignored" in the
>>> second paragraph of section 5, should be changed to "MUST be
>>> ignored". Otherwise, the published TLSA records have unknown
>>> semantics.
>> 
>> Thank you for the feedback, Viktor.  These comments make sense to
>> me. We'll try to get an update out before the cutoff to address
>> them.
> 
> Thanks.  You could mention that both name checks and key usage are 
> effectively handled by the TLSA record for DANE-EE(3).  The TLSA 
> record binds the certificate or public key to the requested port 
> and protocol at the TLSA base domain, the binding is clearly for a
> TLS server, so there is an implicit key usage of TLS server. 
> Finally, the RRSIG expiration date sets the expiration time of the 
> TLSA "pseudo-certificate".  A requirement to ignore the
> certificate content gives the publisher flexibility (e.g. same
> certificate for multiple SRV hosts, ...).
> 

Section 5 (after I change the "MAY" to a "MUST") already states that
matching a DANE-EE(3) TLSA bypasses the rest of the certificate checks
(paragraph 2), but the current wording might be too clumsy.  I'll see
what I can wordsmith to make it more explicit.

I could also add something about the RRSIG expiration, but isn't that
already covered by RFC4035 § 5.3.1 (bullet 5)?

> There will be some overlap between the SRV draft and the SMTP
> draft. I expect that's not a problem, provided they agree.
> 


- -- 
- - m&m

Matt Miller < [e-mail] >
Cisco Systems, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJS+9v2AAoJEDWi+S0W7cO1vDcH/0JiXQus5YsClSbmhjT3/DbR
ILJiUcKYY79yJ1bKDdcsTPF8TaNTuTDN/wtK/ABMfoggD76pJaQ0iCyQLTaL/J61
pkshzeWBKqm2kyfgrwV2hRMOxSsGBc7jWZlrBnHwkOcsxXspJCAFwYUI8X7gzbWc
1L1TCN2+7NCyPz00oj9V7fRN3mDkVFfHPwfI7X87ZihO3dbGA4HSm/DttAmrxbvY
xgk7RUOznaW5SHXU6fRxeWb2DEXsYaPRmrxckauEuI8h52zjszBbAfyOr1XcRG3m
eLHqpLs1yiNQ5x9cqdPHwvm/OhXqDc+BrAftsDrsgMq/Saqb47Q3w0a2vwp6cYM=
=4HNk
-----END PGP SIGNATURE-----