Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5750-bis-02

From: Russ Housley <[email-masked]>
Date: Thu, 9 Mar 2017 12:42:48 -0500

I think that the document is in very good shape, and it is ready to go to the IESG.  I have a few minor suggestions for improvements.

I am not sure what this paragraph in Section 4.3 is trying to tell me:

   For 1024-bit through 3072-bit RSA with SHA-256 see [RFC4055] and
   [FIPS186-2] with Change Notice 1, and for 4096-bit RSA with SHA-256
   see [RFC4055] and [RFC3447].  In either case, the first reference
   provides the signature algorithm's object identifier and the second
   provides the signature algorithm's definition.

If I figured it out properly, I suggest:

   The signature algorithm object identifiers for RSA PKCS#1 v1.5 and
   RSASSA-PSS with SHA-256 using 1024-bit through 3072-bit public keys
   are specified in [RFC4055] and the signature algorithm definition is
   found in [FIPS186-2] with Change Notice 1.

   The signature algorithm object identifiers for RSA PKCS#1 v1.5 and
   RSASSA-PSS with SHA-256 using 4096-bit public keys are specified in
   [RFC4055] and the signature algorithm definition is found in
   [RFC3447].

The last paragraph of Section 4.3 says:

   For EdDSA see [I-D.ietf-curdle-pkix] and [I-D.irtf-cfrg-eddsa].  The
   first reference provides the signature algorithm's object identifier
   and the second provides the signature algorithm's definition.  Other
   curves than curve 25519 MAY be used as well.

There is only one other curve specified for EdDSA, so I suggest:

   For EdDSA see [I-D.ietf-curdle-pkix] and [I-D.irtf-cfrg-eddsa].  The
   first reference provides the signature algorithm's object identifier
   and the second provides the signature algorithm's definition.  In
   addition to curve 25519, curve 448 MAY be used as well.

For clarity, I think that we should change Section 4.3 as follows:

OLD
   MUST- support RSA with SHA-256.
NEW
   MUST- support RSA PKCS#1 v1.5 with SHA-256.

and

OLD
   The following are the RSA and RSASSA-PSS key size …
NEW
   The following are the RSA PKCS#1 v1.5  and RSASSA-PSS key size ...

Appendix C should also include S/MIME 4.0.

Appendix C should probably say something about the LAMPS WG too.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Thu, 9 Mar 2017 23:37:16 -0800

> -----Original Message-----
> From: Spasm [mailto:[email-masked]] On Behalf Of Russ Housley
> Sent: Thursday, March 9, 2017 9:43 AM
> To: SPASM <[email-masked]>
> Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5750-bis-02
> 
> I think that the document is in very good shape, and it is ready to go to the
> IESG.  I have a few minor suggestions for improvements.
> 

That matches my reading of the paragraph, but as this is original text added in RFC 5750, I defer to Sean for an opinion.

>    addition to curve 25519, curve 448 MAY be used as well.

Yes, today there is only one other curve that is defined.  I think that it is possible that others will be added I the future and did not want to close off that path by being explicit here.

>    The following are the RSA and RSASSA-PSS key size … NEW

I am not sure about this.  I think that if this is done then it needs to be done on a much larger basis that what you have suggested here.  I worry about this.  Would an additional terminology  item added to section 1.1 be sufficient?

> Appendix C should probably say something about the LAMPS WG too.

Yes - both of those will be added - probably the latter is missing from 5751-bis as well.

Jim

> 
> Russ
> 
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Fri, 10 Mar 2017 10:23:49 -0500

> Yes, today there is only one other curve that is defined.  I think that it is possible that others will be added I the future and did not want to close off that path by being explicit here.

The reference would need to change to allow other curves, right?

> I am not sure about this.  I think that if this is done then it needs to be done on a much larger basis that what you have suggested here.  I worry about this.  Would an additional terminology  ite…

Yes, that would be fine with me.

Russ

---

From: Sean Turner <[email-masked]>
Date: Fri, 10 Mar 2017 10:51:58 -0500

> On Mar 10, 2017, at 02:37, Jim Schaad <[email-masked]> wrote:
> 
>> 

You interpreted it correctly so the rewording lgtm.

spt

---

From: Jim Schaad <[email-masked]>
Date: Fri, 10 Mar 2017 21:31:41 -0800

> From: Russ Housley [mailto:[email-masked]]
> Sent: Friday, March 10, 2017 7:24 AM
> To: Jim Schaad <[email-masked]>
> Cc: Sean Turner <[email-masked]>; SPASM <[email-masked]>
> >> I think that the document is in very good shape, and it is ready to
> >> go to the IESG.  I have a few minor suggestions for improvements.
> >>

> > Yes, today there is only one other curve that is defined.  I think that it is
> possible that others will be added I the future and did not want to close off
> that path by being explicit here.
> 

I don't follow this line of reasoning.  I would not expect that the S/MIME document would need to have a specific reference for a new EdDSA algorithm w/ a new curve assuming such a document exists.  This would be the same as if you defined a new hash algorithm to with RSAPSS or defined a new curve with ECDSA.  The details do not need to be placed in this document nor, since they are not listed algorithms, do we need to have a reference to this potential document.  If the algorithm becomes standard, then a 4.1 version might need this.

Jim

---

From: Russ Housley <[email-masked]>
Date: Sat, 11 Mar 2017 10:47:35 -0500

> On Mar 11, 2017, at 12:31 AM, Jim Schaad <[email-masked]> wrote:
> 
> 
> 

The EdDSA with yet-to-be-named-hash-function would ned to be assigned an object identifier, and that would happen in some specification.  However, I agree that the S/MIME Message specification does not need to be updated for MAY implement it.

I withdraw this comment.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 14 Mar 2017 11:23:49 -0400

> Yes, that would be fine with me.

It looks like you made the text changes in Section 4.3.  The changes in -03 resolve my comment.

Russ