https://codereview.appspot.com/6767045/diff/8001/src/pkg/crypto/x509/sec1.go
File src/pkg/crypto/x509/sec1.go (right):
https://codereview.appspot.com/6767045/diff/8001/src/pkg/crypto/x509/sec1.go#newcode32
src/pkg/crypto/x509/sec1.go:32: func ParseSEC1PrivateKey(der []byte) (key
*ecdsa.PrivateKey, err error) {
concatenated,*ecdsa.PrivateKey, err error) {
On 2012/10/25 15:20:58, jsing wrote:
On 2012/10/25 14:19:03, agl1 wrote:
Where is this format from? It's odd to have two ASN.1 values
Where is this format from? It's odd to have two ASN.1 values
rather than in a SEQUENCE and SEC1 C.2 doesn't seem to specify
Agreed. It appears that 'openssl ecparam' writes out an
immediately followed by the ECPrivateKey structure. This is similar
does in the PEM case, where there are two PEM blocks in the same
first
case of aan 'EC PARAMS' block, the second an 'EC PRIVATE KEY' block). In the
named curve, the ASN.1 can simply be an OID. I'm not entirely sure
should
problem with
OpenSSL. It makes sense in the PEM case, but it's nonsense for DER.
Apologies for the delay in getting back to this.handle this...
I don't think that we should handle it. I think it's basically aproblem with
OpenSSL. It makes sense in the PEM case, but it's nonsense for DER.
Generally speaking, I agree with your sentiment. OpenSSL seems to take
the approach that EC keys can be generated with non-named parameters,
which means that the curve parameters need to be included separately.
This is obvious in the PEM case where there are two PEM blocks, however
their DER output also includes two ASN.1 values (this occurs even in the
named curve case). If we choose not support this then we will not be
able to load DER EC keys as currently generated by OpenSSL.
If we eliminate this method, we can remove the current
ParseECPrivateKey wrapper
too, right?
Yes.ParseECPrivateKey wrapper
too, right?
https://codereview.appspot.com/6767045/
