Re: [lamps] Éric Vyncke's No Objection on draft-ietf-lamps-cms-shakes-15: (with COMMENT)

["Panos Kampanakis (pkampana)" <[e-mail]>]

Hello Eric, Alexey, 

To try to address the questions

> -- Section 4.1 --
> Can you check whether the begin and the end of this section are consistent ?
> I.e. "id-shake128 and id-shake256 OIDs" vs. "output length of SHA256 or SHAKE256" ? I must admit that my knowledge of crypto is not paramount but I find this weird.

Good catch. This was a nit. It now reads "length of SHAKE128 or SHAKE256..."

> -- Section 4.2.1 --
> Is there any reason why length are measured in bytes while in other sections it is in bits? Readers can do the math of course but why making the text more complex to parse?

When we are dealing with RSA and KMACs we had to keep output length in bits because that is how they are defined in these standards, so it would be confusing for implementers to convert the output sizes for these algorithms. Having said that I found 3 places where I changed from bits to bytes when talking about SHAKE output lengths for consistency. 

> -- Section 3 --
> Why are some object identifier are fully in lowercase and some are a mix of lower and uppercase characters?

The RSASSA-PSS OIDs kept SHAKE in capitals because it seemed unnatural to put it lowercase after the capitals of RSASSA-PSS. For ecdsa we kept it lowercase because that is how the OIDs looked in the past for ecdsa-sha2 OIDs. It is a little arbitrary, but that is why we made them look like that.

I will update the changes to these minor issue pretty soon. 

Thanks,
Panos 



-----Original Message-----
From: Spasm <[e-mail]> On Behalf Of Éric Vyncke via Datatracker
Sent: Monday, August 05, 2019 11:03 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: [lamps] Éric Vyncke's No Objection on draft-ietf-lamps-cms-shakes-15: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-lamps-cms-shakes-15: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Thank you for the work put into this document. I second Alexey's DISCUSS that is easy to fix.

Regards,

-éric

== COMMENTS ==

-- Section 4.1 --

Can you check whether the begin and the end of this section are consistent ?
I.e. "id-shake128 and id-shake256 OIDs" vs. "output length of SHA256 or SHAKE256" ? I must admit that my knowledge of crypto is not paramount but I find this weird.

-- Section 4.2.1 --

Is there any reason why length are measured in bytes while in other sections it is in bits? Readers can do the math of course but why making the text more complex to parse?

== NITS ==

-- Section 3 --

Why are some object identifier are fully in lowercase and some are a mix of lower and uppercase characters?


_______________________________________________
Spasm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/spasm