Limited Additional Mechanisms for PKIX and SMIME
charter-ietf-lamps-03

Note: This ballot was opened for revision 02-00 and is now closed.

Ballot question: "Is this charter ready for external review?"

Alexey Melnikov (was No Objection) Yes

Eric Rescorla Yes

Ignas Bagdonas No Objection

Ben Campbell No Objection

Alissa Cooper No Objection

Comment (2018-05-24 for -02-00)
No email
send info
The milestones look aggressive but I'm unfamiliar with how mature the existing drafts are.

s/in some environments, such a the/in some environments, such as the/

s/6. Specifies a certificate extension/6. Specify a certificate extension/

Spencer Dawkins No Objection

Comment (2018-05-23 for -02-00)
No email
send info
I am, of course, curious about Warren's BLOCKing comment, but assuming that conversation goes well ...

I had some editorial comments, of course.

The last sentence in this list item is borked, as Warren noted ...

3. Specify the use of short-lived X.509 certificates for which no
revocation information is made available by the Certification Authority.
Short-lived certificates have a lifespan that is shorter than the time
needed to detect, report, and distribute revocation information, as a
result revoking them pointless.

Perhaps something like 

3. Specify the use of short-lived X.509 certificates for which no
revocation information is made available by the Certification Authority.
Short-lived certificates have a lifespan that is shorter than the time
needed to detect, report, and distribute revocation information. As a
result, revoking such short-lived certificates is unnecessary and would be pointless.

I'm not sure that "near-term" is necessary in the first sentence of this list item. 
	 	
4. Specify the use of a pre-shared key (PSK) along with other key	
management techniques with supported by the Cryptographic Message	
Syntax (CMS) as a near-term mechanism to protect present day	
communication from the future invention of a large-scale quantum	
computer. 

I found it confusing because "near-term" isn't "near-term from now", it's "near-term after the invention of quantum computing destroys civilization. If you want an adjective, perhaps something like "proactive" would be closer. 

In this text, 

5. Specify the use of hash-based signatures with the Cryptographic	
 Message Syntax (CMS).  A hash-based signature uses small private and	
 public keys, and it has low computational cost; however, the signature	
 values are quite large.  For this reason they might not be used for	
 signing X.509 certificates or S/MIME messages, but they are secure	
 even if a large-scale quantum computer is invented.  These properties	
 make hash-based signatures useful in some environments, such a the	
 distribution of software updates.

I wasn't sure from this description whether quantum computing resistance was the only "environment" where these are applicable. As a nit, s/such a/such as/.

Benjamin Kaduk No Objection

Comment (2018-05-24 for -02-00)
No email
send info
All of the comments I would have had have already been made by others.
It does seem likely that the text for item (3) can be tightened up some.

Suresh Krishnan No Objection

Warren Kumari (was Block) No Objection

Comment (2018-05-23 for -02-00)
No email
send info
Thank you for educating me - it sounds like my concerns have been considered, clearing my Block position.

----


Also, "revoking them pointless" does not parse - perhaps "revoking them is pointless"?


Original Block position (for archeology):
"3. Specify the use of short-lived X.509 certificates for which no
revocation information is made available by the Certification Authority.
Short-lived certificates have a lifespan that is shorter than the time
needed to detect, report, and distribute revocation information, as a
result revoking them pointless."

This makes me twitch -- how short is "short"? And how long is the time to "detect, report, and distribute revocation information"? 
With e.g: CT, misissued certificates may be visible before they are used in an attack, decreasing the detection time.

Also, I would figure that it is still useful to know that a certificate was revoked and didn't just expire -- if I see a certificate which expired 10 minutes ago I may be willing (after some consideration, checking my clock, etc) to decide to trust it anyway (even if that's a bad idea!), but a revoked certificate is a clear indication that something bad happened, and changes my risk assessment.

It's entirely possible that there is a really good reason why I'm wrong / that this argument doesn't make sense in some use cases (or just that I'm nuts!)

Terry Manderson No Objection

Alvaro Retana No Objection

Comment (2018-05-23 for -02-00)
No email
send info
I support Warren's BLOCK and would like to see more details in the Charter about item 3.

Adam Roach No Objection

Martin Vigoureux No Objection