Subject: Re: [saag] Please review draft-iab-crypto-alg-agility-00.txt

From: [email-masked]
Date: Fri, 7 Mar 2014 23:27:14 +0100

Hello Russ, hello all,

I guess my first question is: does feedback on the draft go here, in the general saag mailing list? (I am a first time participant with mailing list feedback...)

I'd like to say that I think this topic is very relevant and would like it if this could be "made official" as a BCP document soon.

Now, moving on to my feedback (WARNING: pretty much all of this concerns formal aspects or structure, not content).

All the content so far looks good to me, I'm just not sure I understand the structure:

- Section 3 is named "Algorithm Agility Considerations", is that a default section name like "Security Considerations"? If not, how is this distinguished from the rest of the document?

- Section 2 is named "Guidelines". It feels to me like section 3 might be giving guidelines as well. Or does the distinction lie in the fact that section 2 contains "SHOULD" etc. statements and section 3 does not?

- If this is the case (and indeed it kind of looks like 2.1 and 2.2 give advice on problems described in 3.1 and 3.2, respectively; 2.1 and 3.1 even share the same name), then I feel like perhaps section 3 should come first. What are your thoughts on that?

- At the end of subsection 2.2 (Mandatory to Implement Algorithms), there are three paragraphs about key sizes. should these go into their own subsection (which might for example be named "Key Sizes")? Or does this really apply only to algorithms which are mandatory to implement?

On a side note, I think I spotted a few typos (stuff between underscores denotes stuff that is there in the document, but shouldn't be there in my opinion):

Section 1:

- there is a comma without a space afterwards ("properly,communicating")

Subsection 2.2:

- "but others allow_s_"

Subsection 3.1:

- "but it may still necessary to handle" is missing a "be"

- "the transition _to_ from unprotected to protected"

Subsection 3.3:

- "some environments will restrict_ion_ the key management approaches"

That's it, at least for today. I hope some of this is helpful, although none of it is directly content-related.

I need to get some sleep now.

Good night/safe travels (for those who still need to fly back home).

Kristof

On 03/06/2014 01:59 PM, Russ Housley wrote:
> I gave a presentation in the SAAG session today.  Once we get the
> content right, the Security ADs have agreed to sponsor it for BCP.
> So, please review and comment so that we can get the content right
> soon.

And its short!

S

> Thanks, Russ

---

From: [email-masked]
Date: Mon, 10 Mar 2014 09:16:14 +0100

(I'm re-sending my mail written on friday, because it seems to have had an
HTML attachment)
Hello Russ, hello all,

I guess my first question is: does feedback on the draft go here, in
the general saag mailing list? (I am a first time participant with
mailing list feedback...)
I'd like to say that I think this topic is very relevant and would
like it if this could be "made official" as a BCP document soon.

Now, moving on to my feedback (WARNING: pretty much all of this
concerns formal aspects or structure, not content).

All the content so far looks good to me, I'm just not sure I
understand the structure:
 - Section 3 is named "Algorithm Agility Considerations", is that a
default section name like "Security Considerations"? If not, how is
this distinguished from the rest of the document?
 - Section 2 is named "Guidelines". It feels to me like section 3
might be giving guidelines as well. Or does the distinction lie in
the fact that section 2 contains "SHOULD" etc. statements and
section 3 does not?
 - If this is the case (and indeed it kind of looks like 2.1 and 2.2
give advice on problems described in 3.1 and 3.2, respectively; 2.1
and 3.1 even share the same name), then I feel like perhaps section
3 should come first. What are your thoughts on that?
 - At the end of subsection 2.2 (Mandatory to Implement Algorithms),
there are three paragraphs about key sizes. should these go into
their own subsection (which might for example be named "Key Sizes")?
Or does this really apply only to algorithms which are mandatory to
implement?

On a side note, I think I spotted a few typos
(stuff between underscores denotes stuff that is there in the document, but

shouldn't be there in my opinion):
Section 1:

That's it, at least for today. I hope some of this is helpful,
although none of it is directly content-related.
I need to get some sleep now.
Good night/safe travels (for those who still need to fly back home).

Kristof