x509-cert: add certificate builder

[baloo]

This is an attempt at a certificate builder.

See: #418

[baloo]

This is very much a work in progress, but sharing early to get feedback. I think I want to attached the extensions to the CertificateVersion::V3.

I don't exactly know how much we want to force in that API. I'm inclined to force the inclusion of:

• X509v3 CRL Distribution Points
• X509v3 Extended Key Usage
• X509v3 Key Usage (make it critical)
• X509v3 Basic Constraints (make it critical)
• X509v3 Subject Alternative Name (probably needs a builder itself)

I'm not sure about:

• Authority Information Access (ocsp uri)
• X509v3 Certificate Policies (not sure if that's expected for a private CA).
• X509v3 Subject Key Identifier / X509v3 Authority Key Identifier (not sure how they are built)

Pretty convinced I can't force:

• CT Precertificate SCTs
  the CT infrastructure is unlikely for a private ca.

[tarcieri]

@baloo there was a little bit of previous discussion on iqlusioninc/yubikey.rs#348 as linked from #418.

One thing I'd recommend is running the generated certificates through a tool like certlint or zlint (probably zlint these days?). I can help out with automating CI setup for that as need be.

[tarcieri]

Also @str4d's x509 crate includes a certificate builder and might provide some inspiration here.

I think if we make a good enough replacement he'll also give us the x509 crate name.

[baloo]

I've started a zlint integration, but it's not as easy as I thought (need to parse the output json, I can't just rely on the status code), I also need to remember how to setup github actions and pull a binary. Got the integration for it in nixos already (to run on my machine): NixOS/nixpkgs#201537

What are your thoughts on https://docs.rs/ouroboros/latest/ouroboros/attr.self_referencing.html. Wondering whether I should keep both the UIntRef and it's backing buffer (Vec<u8>) in the builder as to not have the fn build have to "reparse" from buffer.

[tarcieri]

I also need to remember how to setup github actions and pull a binary.

There's a binary here:

https://github.com/zmap/zlint/releases/download/v3.4.0/zlint_3.4.0_Linux_x86_64.tar.gz

You can look at this as an example for how to download it in a GitHub Actions workflow:

https://github.com/RustCrypto/actions/blob/master/cargo-hack-install/action.yml

It's fine to just put it in the x509-cert workflow for now.

What are your thoughts on https://docs.rs/ouroboros/latest/ouroboros/attr.self_referencing.html.

I played with trying to integrate ouroboros into der in the past. I don't think it was a good fit.

See #734 where I proposed yoke as an alternative.

Alternatively we could eliminate the lifetimes on the various types and move to entirely owned types. I opened #765 to discuss that.

[baloo]

I think I like the yoke a bit better than going to owned types.

[tarcieri]

The owned types are actually nice when decoding from PEM, since they avoid an intermediate PEM -> DER pass and allow the DER to be decoded from PEM on-the-fly as needed to parse document.

[baloo]

test basic_certificate ... ok

Got the root CA profile to work with zero lint error on zlint.
I guess now I need to get the other profiles working and then clean up that whole mess I made.

[baloo]

(minimal-versions error is a regression in nightly: rust-lang/rust#104759)

[brandonweeks]

I don't exactly know how much we want to force in that API. I'm inclined to force the inclusion of:

• X509v3 CRL Distribution Points
• X509v3 Extended Key Usage
• X509v3 Key Usage (make it critical)
• X509v3 Basic Constraints (make it critical)
• X509v3 Subject Alternative Name (probably needs a builder itself)

It feels like doing so would inhibit the usage of this API for use cases other than Web PKI. Which would be a shame because I suspect Web PKI will be one of the last environments where this crate will be adopted.

Go's crypto/x509 offers one of the best APIs for parsing and generating X.509 certificate for arbitrary use cases. It'd be great if this crate could analogous functionality.

[baloo]

I don't exactly know how much we want to force in that API. I'm inclined to force the inclusion of:

• X509v3 CRL Distribution Points
• X509v3 Extended Key Usage
• X509v3 Key Usage (make it critical)
• X509v3 Basic Constraints (make it critical)
• X509v3 Subject Alternative Name (probably needs a builder itself)

It feels like doing so would inhibit the usage of this API for use cases other than Web PKI. Which would be a shame because I suspect Web PKI will be one of the last environments where this crate will be adopted.

Go's crypto/x509 offers one of the best APIs for parsing and generating X.509 certificate for arbitrary use cases. It'd be great if this crate could analogous functionality.

@brandonweeks I implemented an hazmat feature that let you opt out of the default extensions (via Profile::Manual) and that allows you to build your own certificate without webpki extensions.

[tarcieri]

Finished a readthrough pass. Looking good so far. It's a lot of code!

[tarcieri]

FYI, I snagged https://crates.io/crates/zlint

Might be interesting to extract this into a separate crate (after landing this PR perhaps)

[tarcieri]

Going to go ahead and land this