Extending x509 with PKCS#11 (delegated signing) operations

[Paul van Brouwershaven]

I'm currently extending the "crypto/x509" package to work with key materials stored on a HSM via the "github.com/miekg/pkcs11" package.

While all the internal structs as 'tbsCertificate', 'nameConstraints' and many others stay the same it's the handling in 'CreateCertificate' or 'CreateCRL' that is slightly different, in PKCS#11 you don't have access to the private key and you delegate the signing operation to the to cryptographic tokens, such as hardware security modules or smart cards. I don't want copy all the internal structs and helper functions but as far I understand it's not possible to simply extend the functionality of the x509 package. 

Signing via PKCS#11 requires some other parameters as the library/driver, slot, password, key identifiers and mechanism.

As the private key reference is currently an interface anyway I can imagine that we add a pkcs11.Config (or ....) that would hold the PKCS#11 context, session and CKA_ID (key identifier) that can be used for a different handling and establish an external signing operation.

switch priv := priv.(type) {

case *rsa.PrivateKey:

//

case *ecdsa.PrivateKey:

//

case *pkcs11.Config:

//

default:

panic("internal error")

}

 

 http://golang.org/src/pkg/crypto/x509/x509.go#L1496

The problem is that the PKCS#11 package is not part of the GO core. Implement something like a PKCS#11 in GO could be interesting but I have no time for a big project like that. 

I'm currently thinking about a package independent delegated signature system but have currently no idea how this could be implemented following the GO principles.

All suggestions or alternative ideas are welcome!

Thanks,

Paul

[a...@google.com]

On Friday, September 12, 2014 1:18:03 AM UTC-7, Paul van Brouwershaven wrote:

I'm currently thinking about a package independent delegated signature system but have currently no idea how this could be implemented following the GO principles.

NSS adopted PKCS#11 and it destroyed them. That's why you'll find me very wary of it.

But if you want a generic signer, how about https://code.google.com/p/go/source/detail?spec=svnd0331dfbc0539eae77723d8bc0bdb4c42a8b0c15&r=40906c63a04eeb1fc292cd559e57bfcdeff64e7f

If that doesn't work for you, let me know and it might be changeable before 1.4.

If CreateCertificate used a Signer then you would be free to create a PKCS#11 wrapping Signer and I think that would work.

Cheers

AGL 

[Paul van Brouwershaven]

Hi Adam,

I think this generic signer will work for me, I will give it a try soon.

Thanks,

Paul

[Paul van Brouwershaven]

Looking at the Signer interface and it's implementation again I noticed that it's currently not implemented in the crypto/x509 package (CreateCertificate, CreateCRL)

Is this something that is worked on currently?

On Saturday, 13 September 2014 17:11:29 UTC+2, a...@google.com wrote:

[Adam Langley]

On Wed, Sep 17, 2014 at 7:41 AM, Paul van Brouwershaven
<pa...@vanbrouwershaven.com> wrote:
> Is this something that is worked on currently?

It's not something that I'm doing, but it's a small change that would
be reasonable for 1.5.


Cheers

AGL

[Paul van Brouwershaven]

I created an implementation of crypto.Signer in the x509 package:

https://codereview.appspot.com/145910043/

The function signingParamsForPrivateKey is renamed to signingParamsForPublicKey, this also required me to remove the two text that are using mix private/public keys:

{"RSA/ECDSA", &rsaPriv.PublicKey, ecdsaPriv, false, ECDSAWithSHA},

{"ECDSA/RSA", &ecdsaPriv.PublicKey, rsaPriv, false, SHA256WithRSA},