Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-07.txt

From: Francis Dupont <[email-masked]>
Date: Fri, 01 Mar 2013 13:11:59 +0100

In your previous mail you wrote:

>  > Minor issues:

=> BTW I received a side comment stating the document is too long
and should be split into 3 parts (maths, mechanisms, application).
Of course you may answer it is too late...

>  >  - section 2 is not enough accurate, for instance:
>  >   * the critical [k1:k2] notation is introduced after its first use, IMHO
>  >    it is the primary one, i.e., [n] is a short hand for [0:n]
>  
>  Notation is rather tricky here, but I don't think that saying D[n] is
>  shorthand for D[0:n] adds clarity. This is because D[k:n] becomes
>  D[n-k] on recursion. Saying D[k:n] is the same as D[0:n-k] is just
>  confusing (and, indeed, wrong).

=> I don't say D[k:n] is the same as D[0:n-k], just that D[0:n-k]
is the same than D[n-k]. But this is a matter of taste and I have
no good proposal to make this section very clear...

>  >   * the largest power of two must be strictly smaller, not just smaller.
>  
>  There is no difference between "strictly smaller" and "smaller" (in
>  contrast to "decreasing" and "strictly decreasing").

=> it is a language problem: I leave it to native English speaker.

>  >  - 1 page 4: it is a general mechanism but what are its constraints at
>  >   the exception of the intended usage. For instance is the mechanism
>  >   applicable to any end entity public key certificate? or larger??
>  
>  I don't know what this comment refers to.

=> you have a mechanism which can be applied to more than public TLS
server certificates. IMHO it should be fine to put a few words about
the technical (vs usage) scope of the mechanism. Note the term "general"
before mechanism and the very limited scope are both at the end of
the first paragraph of section 1.

>  >  - 1 page 5: misbehaviours -> misbehaviors
>  >   (and 3.3 page 16, and others too)
>  
>  I am not American.

=> nor I am: I just applied an american English spell checker and
reported what it considered as spelling errors. Note that RFCs are
supposed to be written in american English (even it is not a strict
rule at all), and what I did is a good practice when they are many
authors from different countries (i.e., in the general case).

>  >  - 2.1.1 page 7 and 2.1.2 page 8: the wording "the length (k2 - k1) list"
>  >   is IMHO a bit uncommon even I can understand it.
>  
>  It's maths.

=> I am clearly under the Bourbaki's influence (i.e., maths should be
written in the best possible wording :-).

>  >  - 2.1.4 page 10: using a key of at least 2048 bits. ->
>  >   using a public key of at least 2048 bits. (or a modulus as it is for RSA
>  ?)
>  
>  The public and private keys are the same length in RSA (and the length
>  is the length of the modulus).

=> as keys in RSA are not integers but tuples of integers they have
no length by themselves. Now I agree the common meaning is what
you say so I remove my comment (i.e., to be more accurate will be
pedantic without a clear benefit).

>  >  - 3 pages 13, 14, etc: what is the language used for ASN.1? It is not
>  >   ASN.1 itself, nor C?
>  
>  The format of certificates is defined elsewhere. The name ASN.1Cert
>  (which is what I assume you refer to) is taken from RFC 5246.

=> oops, I missed the 1.2 where this was stated.

>  >  - 3.1 page 13: parenthesis around 65535 are not necessary (i.e, they
>  >   are insipid and stupid :-)
>  
>  I love you, too.

=> I thought you know the LISP programming language acronym...
(I was a LISP programmer so I know all jokes about LISP :-)

>  In fact, they are required, see section 4.5 of RFC 5246.

=> I see. But in this case there are spurious 255 (not (255)
as the default is one byte?). RFC 5246 uses (255) so
I suggest to change all 255 at the end of enums into (255)
*if* you have the opportunity to do this.

>  > BTW if the document creates new OID perhaps they should be put
>  > in an annex?
>  
>  I am not aware of a requirement to do so.

=> nor I am (this is why I put a question mark)

>  > PS: I noted there are still some LC comments in the ML.
>  
>  I am not aware of any I have missed.

=> it was just a reminder to the LC comment statement
at the beginning of the standard gen-art template, and
an indication to other gen-art ML readers.

Thanks

[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 01 Mar 2013 12:15:58 +0000

> authors from different countries (i.e., in the general case).

I believe the RFC editor allows either English or American
spellings so long as the document is consistent.

S.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 1 Mar 2013 12:22:55 +0000

> Of course you may answer it is too late...

I do. Way too late. :-)

Also, I'd observe that increasing the number of documents will not
decrease the amount of reading.

> => it is a language problem: I leave it to native English speaker.

This was explained to me offlist. Certainly there is no problem in
English, but I understand other languages don't work as well. So, I
added mathematical notation for clarity.

> authors from different countries (i.e., in the general case).

The style guide (http://www.rfc-editor.org/rfc-style-guide/rfc-style)
says English.

> written in the best possible wording :-).

I changed it anyway :-)

> (I was a LISP programmer so I know all jokes about LISP :-)

Heh. I always thought it was irritating, not insipid.

> *if* you have the opportunity to do this.

You are right, I will change them.

> an indication to other gen-art ML readers.

I see.

Thanks!