Subject: Re: [OPSAWG] [Technical Errata Reported] RFC8886 (6299)

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 12 Apr 2021 15:19:41 +0000

Hi,

Speaking to Warren offline, he suggests (as an author) that this errata should be verified.

Please let me know this week if anyone feels differently, otherwise I'll verify this at the end of the week.

Thanks,
Rob

> -----Original Message-----
> From: RFC Errata System <[email-masked]>
> Sent: 05 October 2020 20:25
> To: [email-masked]; [email-masked]; [email-masked]; Rob Wilton
> (rwilton) <[email-masked]>; [email-masked]; Joe Clarke
> (jclarke) <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Technical Errata Reported] RFC8886 (6299)
> 
> The following errata report has been submitted for RFC8886,
> "Secure Device Install".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6299
> 
> --------------------------------------
> Type: Technical
> Reported by: Stéphane Bortzmeyer <[email-masked]>
> 
> Section: A.2.2
> 
> Original Text
> -------------
>  openssl smime -encrypt -aes-256-cbc -in SN19842256.cfg \
>  -out SN19842256.enc \
>  -outform PEM SN19842256.crt
> 
> Corrected Text
> --------------
> No corrected text, I think it requires more changes in the previous
> command.
> 
> 
> Notes
> -----
> The command in the RFC fails with:
> 
> Error creating PKCS#7 structure
> 140616744621440:error:21082096:PKCS7
> routines:PKCS7_RECIP_INFO_set:encryption not supported for this key
> type:crypto/pkcs7/pk7_lib.c:487:
> 140616744621440:error:21073078:PKCS7 routines:PKCS7_encrypt:error adding
> recipient:crypto/pkcs7/pk7_smime.c:458:
> 
> A rapid glance in some online discussions seem to indicate that you cannot
> S/MIME encrypt with elliptic curves.
> 
> With RSA for the key, the command in the RFC works fine.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC8886 (draft-ietf-opsawg-sdi-13)
> --------------------------------------
> Title               : Secure Device Install
> Publication Date    : September 2020
> Author(s)           : W. Kumari, C. Doyle
> Category            : INFORMATIONAL
> Source              : Operations and Management Area Working Group
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 12 Apr 2021 17:36:55 +0000

I'm confused here.  What is the the correction?  Seems like a fixed
version of the command using RSA instead of EC is correct, but I'm not
clear what the exact verification will be.

Joe

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 12 Apr 2021 18:06:09 +0000

Stephane or Warren can probably can correct me as a butcher the explanation, but ...
... I think that the issue is that the appendix is given as sequence of steps to follow, and in Step 1 (A.1), the certificate is generated using an elliptical curve algorithm, which means that by the time that you get to the step in A 2.2 ,the openssl command fails because openssl doesn't allow you to S/MIME encrypt with the certificate generated in A.1 that is based on an elliptic curve algorithm.

The solution to fix this would be to change the type of algorithm used in Step 1 (A.1) to RSA, in which case this step would succeed.

Perhaps the explanation text needs a bit more clarity (that's presuming that my explanation is on the right track).

Thanks,
Rob

> From: Joe Clarke (jclarke) <[email-masked]>
> Sent: 12 April 2021 18:37
> To: Rob Wilton (rwilton) <[email-masked]>; RFC Errata System <rfc-
> [email-masked]>; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Technical Errata Reported] RFC8886 (6299)
>

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 12 Apr 2021 20:55:39 +0200

On Mon, Apr 12, 2021 at 06:06:09PM +0000,
 Rob Wilton (rwilton) <[email-masked]> wrote 
 a message of 120 lines which said:

> Perhaps the explanation text needs a bit more clarity (that's
> presuming that my explanation is on the right track).

Yes, perfectly correct. Sorry, I did not provide a copy-and-paste fix
because I'm not a S/MIME expert.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 13 Apr 2021 14:00:04 -0400

Rob Wilton \(rwilton\) <rwilton=[email-masked]> wrote:
    > ... I think that the issue is that the appendix is given as sequence of
    > steps to follow, and in Step 1 (A.1), the certificate is generated
    > using an elliptical curve algorithm, which means that by the time that
    > you get to the step in A 2.2 ,the openssl command fails because openssl
    > doesn't allow you to S/MIME encrypt with the certificate generated in
    > A.1 that is based on an elliptic curve algorithm.

    > The solution to fix this would be to change the type of algorithm used
    > in Step 1 (A.1) to RSA, in which case this step would succeed.

That's one way to do it.
ECIES would also work, but maybe openssl CMS can't do that.

Given that
a) it's non-normative example.
b) in practice doing this with openssl shell commands is not a good solution
   (error handling, database access, etc.)

I suggest that we acknowledge the error (should use RSA), but that there
isn't a simple text change.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide