On Thu, Dec 19, 2013 at 08:07:10AM -0800, [email protected] wrote:
> Filename : draft-ietf-dane-srv-03.txt
> Date : 2013-12-13
Section 5 (no exception for usage 3):
Section 7 (MUST and SHOULD on server name are too strong):
Section 10.3 (no exception for usage 3):
This still conflicts with the smtp-with-dane and ops drafts with
respect to name checks (server identity checks) in usage 3. In
the two conflicting documents usage 3 certificates are validated
exclusively by matching against DANE TLSA RRs. No name checks,
key usage checks, expiration checks, ... apply with usage 3. Rather,
the binding of the EE certificate to the service end-point is
entirely established by the DNSSEC TLSA record (also its validity
lifetime is the lifetime of the TLSA record).
Correspondingly, all requirements on the content of the server
certificate are relaxed with usage 3, it may, if desired, contain
no identity information. For example, given the following TLSA
record:
_25._tcp.mail.example. IN TLSA 3 1 1 \
4D8CC746810AB5C7D7D24EE2A78AA6D5 \
687E5CCA54A85846DAACD71E1B172F00
the below would be a valid certificate (which is, absent DANE,
anonymous and never valid):
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: ecdsa-with-SHA256
Issuer:
Validity
Not Before: Dec 19 17:16:51 2013 GMT
Not After : Dec 18 17:16:51 2013 GMT
Subject:
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
...
ASN1 OID: prime256v1
Signature Algorithm: ecdsa-with-SHA256
...
-----BEGIN CERTIFICATE-----
MIHsMIGToAMCAQICAQEwCgYIKoZIzj0EAwIwADAeFw0xMzEyMTkxNzE2NTFaFw0x
MzEyMTgxNzE2NTFaMAAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAARIR1J5ykq+
0/4O7VBur2Sv9tgrMvql0kzZzuaMxyFWxbL9bNtkT3zcjrXHVxdhZOZLZo9Fs5AI
MW+zRCwxNcbbMAoGCCqGSM49BAMCA0gAMEUCIFkPVySlkXTbg6mlEUbDGrABN+a2
V9aZR87f+1X+JKydAiEAwlccNJAVHQmkU5kVelXbx8UsVc66Q8Qt6QrT1L5Xg10=
-----END CERTIFICATE-----
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
