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

2021-04-13 Thread Michael Richardson

Rob Wilton \(rwilton\)  wrote:
> 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.

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. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


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

2021-04-12 Thread bortzmeyer+i...@nic.fr
On Mon, Apr 12, 2021 at 06:06:09PM +,
 Rob Wilton (rwilton)  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.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


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

2021-04-12 Thread Rob Wilton (rwilton)
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


> -Original Message-
> From: Joe Clarke (jclarke) 
> Sent: 12 April 2021 18:37
> To: Rob Wilton (rwilton) ; RFC Errata System  edi...@rfc-editor.org>; war...@kumari.net; cdo...@juniper.net;
> henk.birkh...@sit.fraunhofer.de; zhoutian...@huawei.com
> Cc: bortzmeyer+i...@nic.fr; opsawg@ietf.org
> Subject: Re: [Technical Errata Reported] RFC8886 (6299)
> 
> 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
> 
> On 4/12/21 11:19, Rob Wilton (rwilton) wrote:
> > 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 
> >> Sent: 05 October 2020 20:25
> >> To: war...@kumari.net; cdo...@juniper.net; war...@kumari.net; Rob
> Wilton
> >> (rwilton) ; henk.birkh...@sit.fraunhofer.de; Joe
> Clarke
> >> (jclarke) ; zhoutian...@huawei.com
> >> Cc: bortzmeyer+i...@nic.fr; opsawg@ietf.org; rfc-edi...@rfc-editor.org
> >> 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 
> >>
> >> 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

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


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

2021-04-12 Thread Joe Clarke (jclarke)
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

On 4/12/21 11:19, Rob Wilton (rwilton) wrote:
> 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 
>> Sent: 05 October 2020 20:25
>> To: war...@kumari.net; cdo...@juniper.net; war...@kumari.net; Rob Wilton
>> (rwilton) ; henk.birkh...@sit.fraunhofer.de; Joe Clarke
>> (jclarke) ; zhoutian...@huawei.com
>> Cc: bortzmeyer+i...@nic.fr; opsawg@ietf.org; rfc-edi...@rfc-editor.org
>> 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 
>>
>> 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


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


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

2021-04-12 Thread Rob Wilton (rwilton)
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 
> Sent: 05 October 2020 20:25
> To: war...@kumari.net; cdo...@juniper.net; war...@kumari.net; Rob Wilton
> (rwilton) ; henk.birkh...@sit.fraunhofer.de; Joe Clarke
> (jclarke) ; zhoutian...@huawei.com
> Cc: bortzmeyer+i...@nic.fr; opsawg@ietf.org; rfc-edi...@rfc-editor.org
> 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 
> 
> 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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


[OPSAWG] [Technical Errata Reported] RFC8886 (6299)

2020-10-05 Thread RFC Errata System
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 

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

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg