Re: [lamps] LAMPS sample keys and certificates

[Daniel Kahn Gillmor <[e-mail]>]

Hi Ryan--

thanks for the supportive note and the interesting pointers.

On Mon 2019-11-18 18:32:22 -0500, Ryan Sleevi wrote:

> One of the challenges with such approaches is ensuring deterministic
> outputs as well as negative cases. I noticed your approach, using certtool,
> makes it a bit difficult on both of those dimensions. That is, the encoding
> may change due to the version or certtool, and that it’s (rightfully)
> increasingly hard to have good tools do bad things.

sure, the approach for building the examples is present but i was
intending this document would ultimately exist as a document with static
objects, rather than a programmatic test suite.

that is, it's (hopefully) input to a test suite, but not a test suite
itself.

I haven't even contemplated negative cases here, as you rightly observe.

I confess i was surprised in searching the IETF's archive of I-Ds that
there was no such set of simple positive examples, so this is an attempt
to just fix that gap, rather than trying to provide a programmatic or
exhaustive corpus.

> In the spirit of how many in the TLS-WG have found tools like BoGo (
>  https://github.com/google/boringssl/blob/master/ssl/test/PORTING.md
>  ) helpful in building consensus and interop, and at the risk of suggesting
> a blue bikeshed, have you considered adopting something similar in tooling?

I really like the idea of doing this, but it's more ambitious than i was
intending this draft to be.  I certainly wouldn't block someone from
trying to do it, of course!

> Over in Chrome, one of the tools we use for both positive and negative
> testing, with deterministic output, is
> https://github.com/google/der-ascii . I realize the complexities of CMS and
> BER make this a more nuanced situation, but I highlight as a possible
> foundation to build deterministic “good” inputs, as well as
> “mangled-but-well-formed” and “garbage-but-reflective-of-real-world”
> scenarios.

good point!  none of what i've done in this draft is sophisticated
enough to warrant der-ascii right now, but i'll put it in my toolbox for
future experimentation.

Regards,

        --dkg