[lamps] AD review of draft-ietf-lamps-documentsigning-eku-03

[Roman Danyliw <[e-mail]>]

Hi!

I conducted an AD review of draft-ietf-lamps-documentsigning-eku-03.  Thanks for the work on this document.  My feedback is below:

** Section 1. Editorial.
   In addition, several
   KeyPurposeIds have been added [RFC7299] under the IANA repository
   "SMI Security for PKIX Extended Key Purpose".  

The reference to [RFC7299] seems like an odd place.  Why not: 

NEW
In addition, several KeyPurposeIds have been added under the IANA repository "SMI Security for PKIX Extended Key Purpose" [RFC7299].  

** Section 1.  Editorial.

As were talking about hypothetical changes, recommend the following:

OLD
In circumstances where code signing and S/MIME certificates are also
   widely used for document signing, the technical or policy changes
   that are made to code signing and S/MIME certificates may cause
   unexpected behaviors

NEW
In circumstances where code signing and S/MIME certificates are also    used for document signing, technical or policy changes made to the code signing and S/MIME ecosystem may cause unexpected behaviors ...

** Section 1.  What is a "trust program"?

** Section 1.

Recommend removing the colloquial "become out of control" as this isn't specific.  Below is alternative text.  Please review if it captures the intent.

OLD
   There is no issue if the vendor-defined KeyPurposeIds are used in a
   PKI (or a trust program) governed by the vendor.  However, if the
   KeyPurposeId is used outside of vendor governance, the usage can
   easily become out of control 

NEW
There is no issue if vendor-defined KeyPurposeIds are used in a PKI (or a trust program) governed by a given vendor.  However, if the   KeyPurposeId is used outside of this vendor's governance, the usage can cause interoperability issues.  

** Section 1.

(e.g. - When the end user encounters
   vendor-defined KeyPurposeIds, they might want to ask that vendor
   about use of the certificate, however, the vendor may not know about
   the particular use. - If the issuance of the cert is not under the
   control of the KeyPurposeId owner, there is no way for the
   KeyPurposeId owner to know what the impact will be if any change is
   made to the KeyPurposeId in question, and it would restrict vendor's
   choice of OID management. etc.).

Editorially, please split this large "(e.g.," text block into distinct sentences.

I had difficulty understanding these use cases.

-- The setup on the first example seems to be that a user has acquired credentials with a vendor-define KeyPurposeId, then checks this credential to find a vendor-defined KeyPurposeId, and then confirms back with the vendor (who is not the issuer) that it's acceptable to use for an alternative use case.  If the validation stack will accept the vendor's KeyPurposeId, why does the vendors input matter?  Per the direction of the text in Section 4, I thought the implementation's parsing logic was set by local policy.

-- To the second example, can these potential breaking "changes ... made to the KeyPurposeId" be explained a bit more?

** Section 1.  Editorial. s/a extended key purpose/an extended key purpose/

** Section 3. Editorial.
   As described in [RFC5280], If the Extended Key Usage extension is
   present, then the certificate MUST only be used for one of the
   purposes indicated.  [RFC5280] also describes that If multiple key
   purposes are indicated the application need not recognize all
   purposes indicated, as long as the intended purpose is present.

Words are being added to the direct quotes from RFC5280.  Please make that clearer.

NEW
As described in [RFC5280], "[i]f the [Extended Key Usage] extension is    present, then the certificate MUST only be used for one of the    purposes indicated.  [RFC5280] also describes that "[i]f multiple [key] purposes are indicated the application need not recognize all    purposes indicated, as long as the intended purpose is present."

** Section 4.  I don't follow why there are references to RFC8358 in this section.  It seems like a very detailed example but by my read the take away from the text is that there is no change in the prescribed behavior for RFC8358.

** Section 4.   I'm confused by the complexity of the validation guidance being provided.  I was interpreting the text from the previous sections as (a) the community currently uses a variety of EKUs, both public and vendor specific, to sign human-read content/documents; (b) this document is defining a public EKU for this specific human-read content use case; (c) it's hoped that by defining this EKU there will be adoption; and (d) specific document signing workflows/applications will need to decide how to incorporate new EKU (if at all) but that is out of scope.  Put in another way, there is a new EKU and document-signing ecosystems/workflow will need to decide, in an out-of-scope way, how to use it in their workflows, likely captured by some policy. 

To be more specific about the text:

-- Given that the setup for the validation steps is two "MAY statements", how are interoperable solutions expected?

-- The second MAY statement indicate that it is optional.  The numbered steps below it seem conditional on this check though.

-- What is the derivation being noted and where is this policy coming from in the second sentence?

-- Editorially, why is there both a numbered list and the text after "... as follows:"?

** Section 6.
   This extended key purpose does not introduce new
   security risks but instead reduces existing security risks by
   providing means to separate other extended key purposes used for
   communication protocols namely, TLS or S/MIME etc. in order to
   minimize the risk of cross-protocol attacks

I'm following the link to S/MIME (id-kp-emailProtection), but not the link to TLS (id-kp-serverAuth and id-kp-clientAuth)?

Regards,
Roman