Re: [lamps] Proposed addition of hash-based signature algorithms for certificates to the LAMPS charter

[Adam Langley <[e-mail]>]

On Tue, Nov 13, 2018 at 5:44 PM Benjamin Kaduk <[e-mail]> wrote:
>
> On Tue, Nov 13, 2018 at 11:10:52AM -0800, Adam Langley wrote:
> > On Tue, Nov 13, 2018 at 10:17 AM Daniel Van Geest <[e-mail]>
> > wrote:
> >
> > > You’re right that handling state needs to be done carefully and use of
> > > these signature schemes would not be appropriate in many contexts.  My
> > > presentation of this draft to LAMPS and SECDISPATCH pointed this out and
> > > gave some examples where they would and would not be appropriate.
> > >
> > (Are there slides or a recording of that presentation? Happy to be
> > persuaded by a compelling use-case.)
> >
>
> Recording of secdispatch: 22:25 into
> https://www.youtube.com/watch?v=VawLLztFWOI and slides at
> https://datatracker.ietf.org/meeting/103/materials/slides-103-secdispatch-algorithm-identifiers-for-hss-and-xmss-for-use-in-the-internet-x509-public-key-infrastructure-draft-vangeest-x509-hash-sigs-01-00
> (from the "meeting materials" ('x') button at
> https://datatracker.ietf.org/meeting/103/agenda.html .
> Retrieving the LAMPS analogues is left as an exercise for the reader.

Thank you for the pointers. The examples of where they might be
appropriate from the slides were "CA certs in interactive protocols"
and "CA certs in non-interactive protocols, code signing certs". I
don't think there's anything unexpected there and I disagree for the
reasons given above. (In contrast, I think /stateless/, hash-based
signatures make a whole lot of sense for code-signing.)

> > CAs, nearly all of whom presumably believed that they were being
> > sufficiently contentious in their operations: revoking their own live
>
> (I assume this is supposed to be "conscientious"?)

Yes, thank you.

> > certificates, getting ASN.1 encoding wrong, losing track of their key
> > material, etc.)
>
> I think I'm missing some steps in how the IETF provided procedures that the
> CA operators were following and thought were sufficient (but were actually
> insufficient).

I'm aiming to point out that X.509 has assumed competencies that CAs
have failed to meet before. Perhaps more applicably, X.509 assumes
that serial numbers under a given issuer are unique. But, even without
searching, I've personally dealt with one case where a WebPKI CA was
unable to revoke an intermediate because its (non-trivial) serial
number was duplicated in another, still active, intermediate.

There has been a heartening and positive move by the IETF in recent
years towards primitives that are harder to misuse. I think this moves
in the other direction.


Cheers

AGL