On Wed, Aug 22, 2018 at 01:55:47AM +0000, Peter Gutmann wrote:
> Viktor Dukhovni <ietf-d...@dukhovni.org> writes:
>
> >I've not yet seen raw public key support in any mainstream TLS libraries,
> >though admittedly my focus is primarily on OpenSSL. Do any of NSS, GnuTLS,
> >BoringSSL, LibreSSL, ... support raw public keys?
>
> I've never seen it either. My code does actually support them, but not in the
> way you think, for devices that don't have the ability to deal with certs
> there's the memcpy()-into-send() certificate implementation I've mentioned
> before, you memcpy() a pre-encoded cert chain onto the network, and for
> receiving memcpy() the data in and pick out the SPKI. So in effect it's raw
> public keys, but to anyone watching it looks like it's certificates. There
> are other embedded implementations that do this too, it's a pretty obvious
> optimisation (in other words I'm not trying to claim credit for inventing it).
Some DANE users have reached similar conclusions, though a bit of
ASN.1 parsing is still required to "seek" to the SPKI, which is not
at a fixed offset in the certificate. Here is one DANE-authenticated
certificate seen on a live SMTP server:
serial=C3262B13CAB13672
issuer=
notBefore=Jul 27 14:59:59 2014 GMT
notAfter=Nov 27 14:59:59 3013 GMT
subject=
-----BEGIN CERTIFICATE-----
MIIE1TCCAr2gAwIBAgIJAMMmKxPKsTZyMA0GCSqGSIb3DQEBCwUAMAAwIBcNMTQw
NzI3MTQ1OTU5WhgPMzAxMzExMjcxNDU5NTlaMAAwggIiMA0GCSqGSIb3DQEBAQUA
A4ICDwAwggIKAoICAQC200I1aOkqnrr48PS/MLULQM0QSyCUqvzo07G4Fcwkun+V
tYWS6dWXcNP9s8mRutWFXcZtmIvDs3l0p0HG9N8UU7uQIXJxuuJWAwoLqdvVktOQ
WE7rpItRgNtfVibPmyaoLkLfVBSGTh+tspxXVBZ6OSWjs5CX63CSBCcQtv2ecE+y
AuL6bZDrmgxkPDGGTJiZRwB1ttC7gAITx0OXJOwePrEc1se33vzou8bYIHQWCSct
FxelpEHQ9mDeooT65I3dHph+GXWkh1IYRdltOT4ssmQaEzcmP3KMff4u1ibXzDeq
Bkov6rwPAF/VMHnoESFkA7mR5dpHa31D5l4g6B0dHj24V2IBmBNbzKifa9I04G+G
uKydifHpJ7n4Vc6iijMrrDplwPsSuPdaR6bqg4CID8rU1dxiXAjZz+bK/jIAnuPA
U5kho8lPZgf8YeIgGAF/Yd3hcrX9w5cjKlG/QlhkDStOzIWgXgFSK3tG8GMZm6Ne
LHAjNqOpOrNgLq14aJbOpEzqE3cCl8RVgvP9O/P0ZU7dO/7S3dDaKeg+3anjxhbb
6/iQctxUNxcVyUMf3p1bAl4DqT54dRVNvIS/oH5KaH0rxsW12gmL80VugiuLvuld
t7Pw6A0EjOO4yiMd3BAJCS4evyNMZ75kwZD9YlcX1DPmHUxw11j2F17SS9UfmwID
AQABo1AwTjAdBgNVHQ4EFgQUmMab1SBcHagxOb14ETf/va1bvVkwHwYDVR0jBBgw
FoAUmMab1SBcHagxOb14ETf/va1bvVkwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0B
AQsFAAOCAgEAjUcd319j7Nt7o6OmUNB29RqG2iG/eE1Mq++vob7ppSkgawWjiIUO
Vxec5oz1h8cHo3vtffQDB1putL+c220zJK5NDjkGVJ5xaPZdWOkZ/+/i5Xypudoh
3RQZ2MFrq679L4YUuY+/d3W4B8wKYooAmMT7Duzv9xGICgUO75vAmOA5R8CDr1r2
qj2PLF2xlbSToYa/HbFFkeV/b2OrWc8DTsA3/s6fLc1koYFiAHkyTbBDLlhux3n3
tnS+yWXGL9DpuFZg1EZI2G3asoFZqfSUjMSf9qsWb/EE5+kquwQfTcXC4AuwYNgc
MVnaxjJsd4vb53eITRVFyeq4lVrT1l8Z7c1dhA0wdXCso5ptg/68YPq7K0jXEutK
40C/AVapDdT8SYhwawokNujC3epsZ89e0gp6MbiSk3z1jJGO6dk57B/ymAw91TMz
U72xY7YY4yDGUCrxCVBdiGl2kTihwUdxCRJ1baAXcq3meEAY0wQEcDq/dEUMSHp7
/gr9/8uu94VQ+uIjc4dU6oB+yV/agD+vBDpY2EskdVigxZQKuI5iFX4+2kGoooAb
xkMDriyM/MeD3zjfuBLSrMEQtGZ1d8ilb0kWxCcEwv5SpO9ihiUA584C501syGCD
H0y62RuD2sxdv4k3BKeFYt5NLE7QE8TNgVFKsAdTlW9Cni4yEnscwcM=
-----END CERTIFICATE-----
Basically, just the public key, and self-signature, authenticated
via:
_25._tcp.<mx-hostname>. IN TLSA 3 1 2 (
1b97b159e9835555d568841b623cf14a
626ccf56fc70b82849cfeb0e802ffc95
c4e6620f5848d3d58f6d9ef8cf6b0402
55093e7ac946d209d7d72639bd917d92
)
It does not stricly comply with RFC5280, which forbids empty RDN
sequences for the issuer field, but this does not seem to be a
problem in practice.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
