Joe, Max, Kent and I worked through your comments, and this will result in a version -06 shortly. (06 will also include changes to CMS)
On 10/04/17 13:39, Joe Clarke wrote: > In terms of revocation tests, it might be worth mentioning (from an operator > perspective) that doing this may require broader internet connectivity than a > bootstrapping device may typically have. Opening up that connectivity may be > problematic from a security standpoint. There might, therefore, be some > requirements or recommendations put on the bootstrapping services to make sure > a device is both protected and can verify the validity of a cert. In general, the need for connectivity to check revocation is why we prefer short-lived vouchers. > >From a terminology standpoint, the use of the word "pledge" seems odd. The use > of this word may not translate as clearly outside of the US. Why not > something > like candidate? That's an interesting suggestion. It has a slightly different connotation and implies some kind of contest. We picked pledge based upon the traditions of fraternities, with inspiration from movies like Animal House. Dictionary definitions of Pledge reinforce our usage. > Below are my section-by-section reviews: > > Section 1: > > There is a reference to a "second category" of vouchers, but this is not > referenced anywhere else. I'm not sure what the "categories" of vouchers > are. > More explanation (or rephrasing) is required here. We have clarified the "second category". Also removed the word ephemeral in the intro as being confusing here. The categories are essentially: "nonce" (freshness by being online, and containing data from the pledge), and "time-based" (freshness by having a useful real-time clock and paying attention to the expires-on attribute). So we changed that paragraph to: The lifetimes of vouchers may vary. In some bootstrapping protocols the vouchers may include a nonce restricting them to a single use, whereas in others the vouchers may have an indicated lifetime. In order to support long lifetimes this document recommends using short lifetimes with programatic renewal, see Section 7.1. > Section 6.1: > > Is this needed? Can you simply refer to draft-ietf-netmod-yang-tree-diagrams? We ripped out section 4, and referenced the document informatively, and hope that it will get published.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
