Subject: [lamps] LAMPS sample keys and certificates

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 19 Nov 2019 03:45:20 +0800

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

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 18 Nov 2019 18:32:22 -0500

On Mon, Nov 18, 2019 at 5:52 PM Daniel Kahn Gillmor <[email-masked]>
wrote:

> _______________________________________________
> Spasm mailing list
> [email-masked]
> 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>

---

From: Carl Wallace <[email-masked]>
Date: Mon, 18 Nov 2019 18:51:42 -0500

FWIW, there are a pile of sample artifacts here: https://github.com/GSA/ficam-scvp-testing/tree/master/artifacts. The MFPKI (Mock Federal PKI) was generated by cloning a pile of certs with names obfuscated. Many of these are likely expired by now though. Something like this could offer some diversity to the certification paths (in support of sample S/MIME, etc).

On 11/18/19, 5:52 PM, "Spasm on behalf of Daniel Kahn Gillmor" <[email-masked] on behalf of [email-masked]> wrote:

    Hi all--
    
    I've just published:

    

    
       --dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 19 Nov 2019 00:44:27 +0000

This is very cool.

I don't think it matters what tooling is used since it's most important to get test vectors published than to allow for easier generation of future test vectors.

(I won't be at LAMPS, since it already happened because I had to go to gendispatch.)

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 19 Nov 2019 09:21:08 +0800

Hi Ryan--

thanks for the supportive note and the interesting pointers.

> 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.

> 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!

> “mangled-but-well-formed” and “garbage-but-reflective-of-real-world”

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

---

From: Sean Turner <[email-masked]>
Date: Thu, 21 Nov 2019 23:21:57 +0800

Showing signs of age based on algorithm choices, but there is also:

https://datatracker.ietf.org/doc/rfc4134/

spt

> On Nov 19, 2019, at 07:51, Carl Wallace <[email-masked]> wrote:
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 22 Nov 2019 04:14:16 +0800

> https://datatracker.ietf.org/doc/rfc4134/

Thanks for this pointer!  I had looked for something like this, and even
cornered Paul to ask him if he remembered writing such a thing, but came
up empty.

I now see why i missed it in my earlier searches -- i was assuming that
there would be a PEM-encoded form of the key and certificate objects,
and had searched for PEM headers but did not find them.  It's
interesting that there are no PEM-encoded objects here, just the output
of dumpasn1 and a weird custom base64-encoded form in appendix B!

I agree with you that the algorithm choices are on the weaker side here
(1024-bit RSA and DSS!), so i'm inclined to continue work on the new
document, to have relatively modern certs to use for newer examples.

I'll definitely include a reference to this earlier work, though.

     --dkg

PS i've updated draft-dkg-lamps-sample-certs to use RSA (i'd originally
tried to use RSA-PSS, but ran into trouble with using that in some
tests), and to have the keyEncipherment flag set (rather than the
dataEncipherment flag, which i had mistakenly set).

---

From: Russ Housley <[email-masked]>
Date: Thu, 21 Nov 2019 19:34:12 -0500

DKG:

The perl script does yield the binary data, but the document does not use PEM format.

Russ

> On Nov 21, 2019, at 3:14 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 
> Signed PGP part