PLEASE NOTE: Upcoming changes in Let's Encrypt issuer certificates

[Viktor Dukhovni]

On Mon, Sep 21, 2020 at 03:50:32AM -0400, Viktor Dukhovni wrote:

> Therefore the full list of DANE-TA(2) digests to publish (when relying
> on these rather than "3 1 1" records) is:
> 
>     ; (These can be retired soon, but not just yet)
>     ;
>     ; letsencryptauthorityx3.pem
>     ; letsencryptauthorityx4.pem 
>     ;
>     _25._tcp.smtp.example.org. IN TLSA 2 1 1 60B87575447DCBA2A36B7D11AC09FB24A9DB406FEE12D2CC90180517616E8A18
>     _25._tcp.smtp.example.org. IN TLSA 2 1 1 B111DD8A1C2091A89BD4FD60C57F0716CCE50FEEFF8137CDBEE0326E02CF362B
> 
>     ; (May not be needed if your leaf cert is RSA, ECDSA certs
>     ; will I expect be soon signed with one of these).
>     ;
>     ; lets-encrypt-e1.pem
>     ; lets-encrypt-e2.pem
>     ;
>     _25._tcp.smtp.example.org. IN TLSA 2 1 1 276FE8A8C4EC7611565BF9FCE6DCACE9BE320C1B5BEA27596B2204071ED04F10
>     _25._tcp.smtp.example.org. IN TLSA 2 1 1 BD936E72B212EF6F773102C6B77D38F94297322EFC25396BC3279422E0C89270
> 
>     ; (May not be needed if your leaf cert is ECDSA, once 
>     ; ECDSA certificate issuance cuts over to e1/e2).
>     ;
>     ; lets-encrypt-r3.pem
>     ; lets-encrypt-r4.pem

It seems I failed to paste in the "r3/r4" hashes (which of course
you should not take only from my messages, but check against a
trusted source).  That said, the missing hashes are:

    _25._tcp.smtp.example.com. IN TLSA 2 1 1 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D
    _25._tcp.smtp.example.com. IN TLSA 2 1 1 E5545E211347241891C554A03934CDE9B749664A59D26D615FE58F77990F2D03

On Thu, Sep 24, 2020 at 11:48:23PM +0200, Björn Jacke wrote:

> your follow up mail on this topic is a bit confusing because you quote
> the two *upcoming* E1/E2 cert hashes but the 2 *current* X3/X4 and not
> the also the *upcoming* R3/R4 hashes here.

Thanks for noticing.  In case you want all the values, here's the bit of
PostgreSQL I use to count usage of these in DANE survey TLSA records,
this finds the hashes for all the combinations of selector (Cert(0)
and SPKI(1)) and hashed matching type (SHA2-256(1) and SHA2-512(2)):

    WITH le(n, issuer, s, m, ihash) as (
        VALUES
        ( 1, 'X3', 1, 1, '\x60B87575447DCBA2A36B7D11AC09FB24A9DB406FEE12D2CC90180517616E8A18' :: bytea),
        ( 1, 'X3', 1, 2, '\x774FAD8C9A6AFC2BDB44FABA8390D213AE592FB0D56C5DFAB152284E334D7CD6ABD05799236E7AA6266EDF81907C60404C57EE54C10A3A82FCC2A9146629B140' ),
        ( 1, 'X3', 0, 1, '\x731D3D9CFAA061487A1D71445A42F67DF0AFCA2A6C2D2F98FF7B3CE112B1F568' ),
        ( 1, 'X3', 0, 2, '\x5EC5B0783C6E667E0965DF772943A06326768DE0F75DC0BD2FE378F02CCCA7D56C987656174CBE158CC29ECD763F8BDA3454332CC7D47FB934691409C5FB8686' ),
        ( 2, 'X4', 1, 1, '\xB111DD8A1C2091A89BD4FD60C57F0716CCE50FEEFF8137CDBEE0326E02CF362B' ),
        ( 2, 'X4', 1, 2, '\xA0F5D1333BC90BCEA0B0B5F401160B6E7F28A1256BC5B5D65F04B06B0BB0C96270AA81D8E2726394D385BF3E9EE46EB4AB7548C782D5688CC16D0CDFFEFB8594' ),
        ( 2, 'X4', 0, 1, '\x5DE9152BED31FA0515DD1FC746133F1327562EF72A84CF2D2403E748A604D0D4' ),
        ( 2, 'X4', 0, 2, '\x74DDAD9F8CDFA0FE6F6B70301B557A63A58B87FC2C17FAE0F65E47D141226C062A74FA14861DC47A720BD8699B99091A06BD695CDDE51222F837B9DECFC270C5' ),
        ( 3, 'R3', 1, 1, '\x8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D' ),
        ( 3, 'R3', 1, 2, '\x0F644C9A1DCB8C04BE6B385A60DBE4FDF7E2B81E335C9AD8C7CD0ABE2FF9E7E5BBFBB68B38DD0216F17808F48BDF6AF8C6347659C1F41A9858032C31F436D12C' ),
        ( 3, 'R3', 0, 1, '\x67ADD1166B020AE61B8F5FC96813C04C2AA589960796865572A3C7E737613DFD' ),
        ( 3, 'R3', 0, 2, '\x96C5793B2B57D8DF5891C94015720960E0DA4C2CF8CE1FC5707A0B46E5DB8CE3761FB5FDB430F619D1579F13E80FBDD973EF6A024129ED039AA193273158FCAD' ),
        ( 4, 'R4', 1, 1, '\xE5545E211347241891C554A03934CDE9B749664A59D26D615FE58F77990F2D03' ),
        ( 4, 'R4', 1, 2, '\x59A91D97D81980951D0EF3C6D849B31606AF9AB2B0F7DCFAC93A53AE3263EB8902C3B7C564F33FF496F2D07C750B1B6924968C243882AF9E3532797EEF596F27' ),
        ( 4, 'R4', 0, 1, '\x1A07529A8B3F01D231DFAD2ABDF71899200BB65CD7E03C59FA82272533355B74' ),
        ( 4, 'R4', 0, 2, '\x0F0B4DD77EE99D8ED5724DA618B56017D08B757884796D087BF656E62D2717B5C913CB1E2EDA07AACBFDBFDCB1BA5BA52114D54C000E05B0CB755256A61C0C37' ),
        ( 5, 'E1', 1, 1, '\x276FE8A8C4EC7611565BF9FCE6DCACE9BE320C1B5BEA27596B2204071ED04F10' ),
        ( 5, 'E1', 1, 2, '\x3561540FBF182BCE7749ACC131B421E691F083569C053E78F20274714C5E801226FF6EDB60641DDF70E71BD3A90DFE25DDD6464BE78106B77DECE4F6A3BFF13D' ),
        ( 5, 'E1', 0, 1, '\x46494E30379059DF18BE52124305E606FC59070E5B21076CE113954B60517CDA' ),
        ( 5, 'E1', 0, 2, '\x0FC8BDB5B93D95BB016BB543BD74B859E4C18930964D59CFC305B93EF3212C0C20F3084BA98FBF7AAC55D0D22C5B35566ED75BEBE6D5A7C53CA1F949C45C3C8E' ),
        ( 6, 'E2', 1, 1, '\xBD936E72B212EF6F773102C6B77D38F94297322EFC25396BC3279422E0C89270' ),
        ( 6, 'E2', 1, 2, '\x23A30BD3B617652E97224E1FAF673C4E09F1C197E4994274E676F2490893E9560D99F00A8859E399B2C65219CE2EB9B76784A0EC775AB4973A14FC1437AC7D9F' ),
        ( 6, 'E2', 0, 1, '\xBACDE0463053CE1D62F8BE74370BBAE79D4FCAF19FC07643AEF195E6A59BD578' ),
        ( 6, 'E2', 0, 2, '\xE8EC8405AB45605AE6E4A54EFD6D626F663CB7E61A10D9A6A6A08B118E0D35763D0118E263A6DB64516CA9F4E7F64FCD2B5DBF9E7A7BA265870606AF26F4D855' )
        )
    select count(distinct t.qname) as "#", le.issuer as "CA"
    from le
    join tlsa t on t.usage = 2 and t.selector = le.s and t.mtype = le.m and t.data = le.ihash
    join tlsabase b on b.tbase = t.qname
    join mx m on m.exch = b.qname
    group by le.n, le.issuer
    order by le.n;

Updates to add the new hashes are happening more slowly than I'd hoped:

      #  | CA
    -----+----
     978 | X3
      32 | X4
      15 | R3
       9 | R4
      15 | E1
      10 | E2

If you're relying on "2 1 1" (or other Let's Encrypt DANE-TA(2)) TLSA
records, please make the necessary changes promptly.

-- 
    Viktor.