Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto/x509: RSAES-OAEP support #30416

Open
DenisKarch opened this issue Feb 26, 2019 · 5 comments
Open

crypto/x509: RSAES-OAEP support #30416

DenisKarch opened this issue Feb 26, 2019 · 5 comments
Labels
FeatureRequest NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@DenisKarch
Copy link

x509 currently does not support parsing rsaesoap pub keys.
Use case is calling x509 to extract the public EK from TPMs for verification purposes.
There are many old TPM units that use this key type.

@agnivade
Copy link
Contributor

/cc @FiloSottile

@bcmills bcmills added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. FeatureRequest labels Feb 27, 2019
@bcmills bcmills added this to the Unplanned milestone Feb 27, 2019
@bcmills
Copy link
Contributor

bcmills commented Feb 27, 2019

CC @agl

@FiloSottile FiloSottile changed the title crypto/x509: rsaesoap support crypto/x509: RSAES-OAEP support Mar 1, 2019
@FiloSottile
Copy link
Contributor

I'm assuming this is about RSAES-OAEP public keys, specified in RFC 4055 and 5756.

I imagine these keys are encryption only, so not very useful for TLS.

Note that we don't even support certificate keys with id-RSASSA-PSS OID at the moment.

@DenisKarch
Copy link
Author

Yes both your assumptions are correct. TPM manufacturers have since switched to using rsaEncryption keys, however a significant portion of machines still have TPMs whose public keys are RSAES-OAEP. From what I can gather the difficulty with adding proper support for RSAES-OAEP public keys is that their parameters have non-integer default values (which is not currently supported). For our purposes we do not need to parse the parameters so leaving them as a RawValue is fine.
(I currently have a "working" hack in place that parses the parameters somewhat successfully)

@FiloSottile
Copy link
Contributor

The main problem with id-RSASSA-PSS and id-RSAES-OAEP keys is that if we parse them into a *rsa.PublicKey, all current crypto/x509 users (including crypto/tls) will accept them and treat them as if they were rsaEncryption, which might be incorrect and unexpected, so we need some other wrapper time or something like that.

For parsing we can use golang.org/x/crypto/cryptobyte if encoding/asn1 does not fit.

daviddrysdale pushed a commit to google/certificate-transparency-go that referenced this issue Mar 12, 2019
)

This currently populates an *rsa.PublicKey value, but it does not
return or expose the associated hashing and masking algorithms,
so the key can't be used to validate signatures.

Upstream `crypto/x509` issue for support is:
golang/go#30416
DenisKarch added a commit to DenisKarch/go-tspi that referenced this issue Mar 12, 2019
crypto/x509 now enforces that rsa public keys must have NULL parameters.
The old no longer solves the issue and instead will silently fail when
parsing the key, ultimately causing a null pointer dereference at
(pubkey := cert.PublicKey.(*rsa.PublicKey)).
Currently working with crypto/x509 to add support for RSAES-OAEP keys
golang/go#30416
DenisKarch added a commit to DenisKarch/go-tspi that referenced this issue Mar 12, 2019
crypto/x509 now enforces that rsa public keys must have NULL parameters.
The old no longer solves the issue and instead will silently fail when
parsing the key, ultimately causing a null pointer dereference at
(pubkey := cert.PublicKey.(*rsa.PublicKey)).
Currently working with crypto/x509 to add support for RSAES-OAEP keys
golang/go#30416
DenisKarch added a commit to DenisKarch/go-tspi that referenced this issue Mar 12, 2019
crypto/x509 now enforces that rsa public keys must have NULL parameters.
The old fix no longer solves the issue and instead will silently fail when
parsing the key, ultimately causing a null pointer dereference at
(pubkey := cert.PublicKey.(*rsa.PublicKey)).
Currently working with crypto/x509 to add support for RSAES-OAEP keys
golang/go#30416

For certificate-transparency-go have accepted a temporary fix to /x509
google/certificate-transparency-go#470
so we will be building against them for the time being.
DenisKarch added a commit to DenisKarch/go-tspi that referenced this issue Mar 12, 2019
crypto/x509 now enforces that rsa public keys must have NULL parameters.
The old fix no longer solves the issue and instead will silently fail when
parsing the key, ultimately causing a null pointer dereference at
(pubkey := cert.PublicKey.(*rsa.PublicKey)).
Currently working with crypto/x509 to add support for RSAES-OAEP keys
golang/go#30416

certificate-transparency-go have accepted a temporary fix to /x509
google/certificate-transparency-go#470
so we will be building against them for the time being.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants