Re: [lamps] LAMPS sample keys and certificates

On Mon, Nov 18, 2019 at 5:52 PM Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:

> Hi all--
>
> I've just published:
>
>    https://www.ietf.org/id/draft-dkg-lamps-samples-00.html
>
> This draft contains sample X.509v3 certificates, and corresponding
> secret keys for a sample CA, and for two e-mail users, Alice and Bob.
> It provides the certificates and keys in PEM-encoded form and (for Alice
> and Bob) in PKCS#12 bundles, so they should be relatively easy to
> import.
>
> My hope is that they are useful for generating and interpreting sample
> S/MIME (CMS) messages, and part of a larger plan to generate test
> vectors that will be useful in demonstrating protected header behavior
> on existing clients.
>
> I'd appreciate any feedback or suggestions on the draft and the sample
> keys and certificates and PKCS#12 files.
>
> I'm currently building the draft from the git repo at
> https://gitlab.com/dkg/lamps-samples -- editorial patches, issues, etc
> are welcome at the gitlab interface, though i would prefer if any
> substantive issues are also addressed to the list here.
>
>    --dkg
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm

Overall, I’m wildly supportive of examples and test vectors that help build
interop, whether in I-D form or otherwise. PKITS, for all its flaws, has
been profoundly useful in this space.

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.

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?

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.

Just $.02 of feedback, since I suspect the cost to switch, if it does turn
out to be useful, will grow as more examples are added.

<https://www.ietf.org/mailman/listinfo/spasm>