Am 06.07.16 um 16:02 schrieb Dr. Stephen Henson:
> On Wed, Jul 06, 2016, Dr. Stephen Henson wrote:
>
>> On Fri, Jul 01, 2016, Stephan M?hlstrasser wrote:
>>
>>>
>>> First the AlgorithmIdentifier includes the EC curve name:
>>>
>>> 40 19: SEQUENCE {
>>> 42 7: OBJECT IDENTIFIER ecPublicKey (1 2 840
>>> 10045 2 1)
>>> 51 8: OBJECT IDENTIFIER ansiX9p256r1 (1 2 840
>>> 10045 3 1 7)
>>> : }
>>>
>>> In CMS objects created with OpenSSL with the same recipient
>>> certificate, the curve name is always omitted. Is it possible to
>>> make OpenSSL emit the curve name as well?
>>>
>>
>> No as this is a violation of the standards. From RFC3278:
>>
>> originator MUST be the alternative originatorKey. The
>> originatorKey algorithm field MUST contain the id-ecPublicKey
>> object identifier (see Section 8.1) with NULL parameters. The
>> originatorKey publicKey field MUST contain the DER-encoding of a
>> value of the ASN.1 type ECPoint (see Section 8.2), which
>> represents the sending agent's ephemeral EC public key.
>>
>
> Correction... that is not allowed by RFC3278 but is allowed in RFC5753 but
> OpenSSL doesn't currently generate that format. It's not clear what purpose it
> serves as the EC parameters are specified in the recipient's key and
> certificate anyway.
So do I understand it correctly that OpenSSL currentls only supports
RFC3278? Does that mean that it can't process CMS enveloped data objects
that are created according to RFC5753?
In my other thread titled "Unable to decrypt CMS object encrypted with
EC prime256v1 certificate" the CMS object that cannot be decrypted with
OpenSSL does contain the EC parameters. Can that be related to the problem?
--
Stephan
