Subject: [Gen-art] review of draft-laurie-pki-sunlight-07.txt

From: Francis Dupont <[email-masked]>
Date: Mon, 18 Feb 2013 15:53:43 +0100

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-laurie-pki-sunlight-07.txt
Reviewer: Francis Dupont
Review Date: 20130208
IETF LC End Date: 20130226
IESG Telechat date: unknown

Summary: Almost Ready

Major issues: None

Minor issues:
 - 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]
  * the largest power of two must be strictly smaller, not just smaller.
   Without this critical detail recursion rules don't work for n = 2^m
 Unfortunately there is no wikipedia or equivalent web page where to refer to
 so the document is the place where all gory details have to be...

 - the Maximum Merge Delay (MMD) is an important parameter but I can't find
  where is the way users get its value, nor any recommendation for it.

Nits/editorial comments:
 - 1 page 4: CA is not a well known abbrev so please introduce it
  (cf http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt)

 - 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??

 - 1 page 5: misbehaviours -> misbehaviors
  (and 3.3 page 16, and others too)

 - 1 page 5: e.g. -> e.g.,

 - 2.1.1 page 6: i.e. -> i.e.,

 - 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.

 - 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?)

 - 3 pages 13, 14, etc: what is the language used for ASN.1? It is not
  ASN.1 itself, nor C?

 - 3.1 page 12: accomodate -> accommodate

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

 - 3.1 page 13: submmited -> submitted

 - 3.2 page 14: opaque TBSCertificate<1..2^16-1> add final ';'

 - 4.6 page 22: honour -> honor

 - 4.6 page 22: convering -> covering? 

BTW if the document creates new OID perhaps they should be put in an annex?

Regards

[email-masked]

PS: I noted there are still some LC comments in the ML.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 22 Feb 2013 11:17:51 +0000

>    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).

>   * 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").

>   where is the way users get its value, nor any recommendation for it.

We anticipate that this will be published in some kind of human readable policy.

>   (cf http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt)

Fixed.

>   applicable to any end entity public key certificate? or larger??

I don't know what this comment refers to.

>   (and 3.3 page 16, and others too)

I am not American.

>  - 1 page 5: e.g. -> e.g.,

Fixed.

>  - 2.1.1 page 6: i.e. -> i.e.,

Fixed.

>   is IMHO a bit uncommon even I can understand it.

It's maths.

>   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).

>  - 3 pages 13, 14, etc: what is the language used for ASN.1? It is not

The format of certificates is defined elsewhere. The name ASN.1Cert
(which is what I assume you refer to) is taken from RFC 5246.

>  - 3.1 page 12: accomodate -> accommodate

Fixed.

>   are insipid and stupid :-)

I love you, too.

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

>  - 3.1 page 13: submmited -> submitted

Fixed.

>  - 3.2 page 14: opaque TBSCertificate<1..2^16-1> add final ';'

Fixed.

>  - 4.6 page 22: honour -> honor

No.

>  - 4.6 page 22: convering -> covering?

Fixed.

> 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.

Thanks for your comments!

> PS: I noted there are still some LC comments in the ML.

I am not aware of any I have missed.