Ugly workaround for golang err/mismatch that loses subject elements

[syncsynchalt]

For example, without this change an emailAddress (oid 1.2.840.113549.1.9)
that is present in the CSR's subject will not be present in the subject
of the signed and returned certificate.

This is a workaround for #91

[jessepeterson]

I would prefer this to be configurable. I'm not sure every CA wants to blindly copy other attributes.

[syncsynchalt]

I'm happy to backburner it forever, I just wanted to capture the info in case it saves someone some time later. I'm playing with my own fork so I can live off the workaround as long as needed.

I should note that the current protection from arbitrary subject elements is only a side effect, I could see golang changing this behavior someday and it would be lost.

[groob]

the CSR should be generated with the scepclient tool, and we should update the template with users needs IMO.

[jessepeterson]

@groob is the template something the CA/SCEP server side checks for which attributes to use? that'd be an interesting way to do it - copy all attributes over that are present in a configured CSR

[groob]

sorry I thought this was about the CA cert.
given that we're talking about the csr in the scep request, we should honor what the client sends.

We could make it configurable with a startup option.

[jessepeterson]

Ah okay. Yeah I was saying it shouldn't necessarily honor what the client requests. Especially with regard to certificate attributes like CA and signing capabilities. Control over which attributes and subject name OIDs are signed in the resulting certificate is definitely something any CA operator wants control over. Or not — which is why it should be configurable. :)

[syncsynchalt]

And to make it clear I was only thinking about CSR/cert subjects... any use of "attributes" implying things like CA=true is not intended, I just mean the oid=value subject components (e.g. C=US,L=CO,OU=Company,CN=username,E=[email protected])

[syncsynchalt]

(And to address the first concern of limiting what can be in a signed subject, an admin can also write a -csrverifierexec script that can prevent creation of certs that don't fit a desired pattern)

[jessepeterson]

Sure, I understand. That workaround can work. But it's not just a allow/deny: I'd also like the option of silently dropping CSR-provided attributes and signing just the attributes I care about. This is fairly standard practice I think — most large public web CAs do this, for example.

[jessepeterson]

We've since changed how CSR signing happens in e.g. #113. And with a new PR in #150 I hope to make the signing functionality a bit more configurable. I'd be happy to take a look another PR that addresses this. Maybe something along the lines of a depot.WithCopiedSubjectOID() Option on the Signer which can copy over specific custom attributes like email address. Feel free to re-open this PR or submit a new one with adjustments.