Reviewer: Carl Wallace Review result: Has Nits The draft defines four new object identifiers for use with the extended key usage extension defined in RFC 5280. The mechanism in the draft is fine and the security considerations section seem adequate but the draft could use some editing. A few suggestions are below. Intro - Expand ERJU - The first sentence is correct but perhaps should note the extension is defined there too. Maybe: RFC 5280 defines the ExtendedKeyUsage extension and several extended key purpose identifiers (KeyPurposeIds) for use with that extension in X.509 certificates. Section 1 - The first sentence of the fourth paragraph is not quite right. Suggest "specifies several extended key usages" instead of "specifies several key usage extensions." - In the second sentence replace "Key usage extensions" with "KeyPurposeIds." - s/management of trust anchor/management of trust anchors - s/if the file is signed/if the file is verified - Suggest adding "or in ExtendedKeyUsage extensions that have been marked critical" to the end of the second sentence in the next to last paragraph. Suggest dropping "or misusing" in the same sentence. - The last two sentences of the last paragraph are overly broad. As written, I could elect to use any of these KeyPurposeIds for any purpose I want to. That can't be the intention and it's in direct conflict with the first paragraph of Section 3. Suggest deleting those sentences. I suspect the point was to address combination of KeyPurposeIds. If this is correct, maybe: "This specification does not prohibit combining the KeyPurposeIds defined in this specification with any other KeyPurposeId. Such restrictions may be imposed by other technical standards or certificate policies." This point is already made in section 3, though, so deletion is fine too. Section 3 - s/keyPurposeId's/KeyPurposeIds - s/KeyPurposeId's/KeyPurposeIds - In the last paragraph, the should in the first sentence should probably be SHOULD. - Why are keyEncipherment and keyAgreement mentioned in this draft? All of the KeyPurposeIds are focused on signature usage. Suggest: All certificates containing one of the KeyPurposeIds defined in this specification MUST also feature a KeyUsage extension that asserts the digitalSignature value. Section 5 This section does not add much. Admonishing a CA to include "correct" values for EKU and KU extensions is not necessary. The point about combinations is already made in Section 3. Section 6 s/reduces existing/reduce existing -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
