On Thu, Jan 16, 2014 at 06:08:10PM +0000, Viktor Dukhovni wrote:
> I'll strive to avoid publishing examples that are likely to fail
> interoperability tests. For what it is worth, OpenSSL does not
> mind empty subject and issuer DNs even without a SAN extension, if
> the application layer does not object. The DANE verification code
> I wrote on top of OpenSSL likewise does not object with usage
> DANE-EE(3).
My updated code for essentially anonymous self-signed certificates
now generates certificates with subject and issuer set to "CN=*",
in the hope that this will encounter less friction from strict
parsers. The extra 24 useless octets in the DER encoding of the
certificate are not prohibitive:
issuer= /CN=*
notBefore=Jan 17 05:29:38 2014 GMT
notAfter=Jan 16 05:29:38 2014 GMT
subject= /CN=*
-----BEGIN CERTIFICATE-----
MIIBBTCBq6ADAgECAgEBMAoGCCqGSM49BAMCMAwxCjAIBgNVBAMMASowHhcNMTQw
MTE3MDUyOTM4WhcNMTQwMTE2MDUyOTM4WjAMMQowCAYDVQQDDAEqMFkwEwYHKoZI
zj0CAQYIKoZIzj0DAQcDQgAEa3wTPD7Pnc0r5Jq5pwWVtOJMpDOGjfhPe3Ger2hr
r9XTMJt8gKo+qPbvokID/sqEmqf1cwh/VJtdiEaEw8f2uDAKBggqhkjOPQQDAgNJ
ADBGAiEAjTtBubyqCqIoOFArwZ/imA483U4+zSKZEgEFMTqqS9MCIQClkwwlavTu
mjagje1TSlDYuScRRstmZc9wp2bsmA1Ljg==
-----END CERTIFICATE-----
Yes I know that one can't yet field only an EC certificate even
for SMTP. Many pre-DANE opportunistic TLS clients will have older
TLS implementations that don't support EC, but insist on a compatible
(i.e. RSA with SHA1) certificate which they promptly ignore. The
requisite RSA-2048 certificate is ~400 octets longer:
issuer= /CN=*
notBefore=Jan 17 06:18:09 2014 GMT
notAfter=Jan 16 06:18:09 2014 GMT
subject= /CN=*
-----BEGIN CERTIFICATE-----
MIICkTCCAXmgAwIBAgIBATANBgkqhkiG9w0BAQUFADAMMQowCAYDVQQDDAEqMB4X
DTE0MDExNzA2MTgwOVoXDTE0MDExNjA2MTgwOVowDDEKMAgGA1UEAwwBKjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM60J1M9a5M8SB5kGvWuWSHgI9GV
lcUmufkjhBnN7lUSEgCKjIPWolnH/4JhoIrmMyqtbLAXEbkt64LcvVE2QQxY625S
/om7JJTb/VO3OmY/ae8hWWtgkaBlprg5YDHSGPdCdMLqKb1cjyUYbWzjHZ/vXDGF
tWhA/oW1tEBOVXDvyNJITF22epk3U6SORqOCkKixWQ4W/yKc4wH1ybFtfpdZxPPy
rx+0arWHaw5fbf82D3f55Ox9f+a7AZDKkce32ONqEruGhyTG6m6DHlbzdiiEc6xc
Fklomr8xn+jyf/jyi5YpzylFPBZiF11GVHPMYIUEFscnbLXyvKA88Ud3h9cCAwEA
ATANBgkqhkiG9w0BAQUFAAOCAQEAVu8qwguTCyMQ2rIYVZQvQTY+XYJZxUkwI2RS
4RfTqyJVina9Bi+o2iueWA5dTAqthWMpt0n4XVCuZlrcg82ZP5sJYwIs2FUX9Syk
gRFMG3TtHfrRoFrxylD+qjNdb74vZb1JtLSo4eqnEFUUMpYm3YvocoCkuJJrfsyF
TD2Tjj9Kv/rYMiRUFUU/NwK1+i49OI70L+Lr5nOwE/jxSjLpHUzsdhPGt4Rw7cNs
Eo5yX33tSShARTGFHW8SHZicMBQjbOTEVFslaCFv+qFH10n8W8PZ5romFbyqx9DD
VLlFSW+/4dXJDIFG8F27xWV3kl6Hi+zn49IoTHV7tWB2YtDXkg==
-----END CERTIFICATE-----
With DANE it will finally be practical to field multiple certificates,
one an with an RSA key, for clients that don't support ECDSA, and
another with an ECDSA key for those that do. The TLSA RRset can
then list both digests.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
