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

[Sean Turner <[e-mail]>]

> On Jul 13, 2022, at 16:42, Roman Danyliw <[e-mail]> wrote:
> 
> Hi!

Finally getting around to this. I believe we made changes that address all of these. New version should be posted tonight.

> 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].  

adpoted

> ** 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 ...

adpoted

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

We dropped the reference - it was a reference to the trust list programs.

> ** 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.  

adopted

> ** 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.

done

> 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/

fixed

> ** 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."

adopted

> ** 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.

We added this text to provide a concrete example where this EKU would be used. You’re right that there was no changes proposed for RFC 8358. We decided to drop this paragraph.

> ** 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:"?

I think we made changes to address all of these.

> ** 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)?

We made some minor wording tweaks to hopefully address this.

spt