[secdir] Secdir last call review of draft-ietf-lamps-automation-keyusages-04

[Carl Wallace via Datatracker <[e-mail]>]

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