Subject: [lamps] I-D Action: draft-ietf-lamps-documentsigning-eku-00.txt

From: [email-masked]
Date: Fri, 14 Jan 2022 05:13:36 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF.

        Title           : General Purpose Extended Key Usage (EKU) for Document Signing X.509 Certificates
        Authors         : Tadahiko Ito
                          Tomofumi Okubo
                          Sean Turner
	Filename        : draft-ietf-lamps-documentsigning-eku-00.txt
	Pages           : 8
	Date            : 2022-01-12

Abstract:
   [RFC5280] specifies several extended key usages for X.509
   certificates.  This document defines a general purpose document
   signing extended key usage for X.509 public key certificates which
   restricts the usage of the certificates for document signing.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lamps-documentsigning-eku/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-lamps-documentsigning-eku-00.html

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Russ Housley <[email-masked]>
Date: Fri, 14 Jan 2022 10:24:21 -0500

I just read the document, and I offer a few comments to get the discussion going.

SECTION 4:

I am missing something.  I understand the goal is to prevent a certificate from having both code-signing and document-siging EKU OIDs, and that you are being abstract so accommodate the handling of yet-to-be-defined EKU OIDs.  However, where do the restrictions come from?  Should there be a registry to hold the values?  If not, will different implementers make different choices?

NITS:

Abstract: References should not appear in the Abstract, so:
	s/[RFC5280]/RFC 5280/

Section 4: s/prohibit conbinations/xxclude combinations/

Section 4: s/anyEKU/anyExtendedKeyUsage/

Section 6: s/none-email purposes/purposes other than email/

> On Jan 14, 2022, at 8:13 AM, [email-masked] wrote:
> 
>

---

From: Sean Turner <[email-masked]>
Date: Fri, 14 Jan 2022 11:55:46 -0500

I meant to send this earlier, but this version is technically identical to the draft-ito-documentsigning-eku-02.txt:
http://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-ito-documentsigning-eku-02.txt&url2=https://www.ietf.org/archive/id/draft-ietf-lamps-documentsigning-eku-00.txt

The editorial changes include:

- Added an "About This Document” - by adding “venue” tags to .md you get this section, which I like.

- Moved the Acknowledgments after the ASN.1 module.

- Updated dates & filename.

Will now get to addressing Wendy’s comments on draft-ito-documentsigning-eku-02 as well the I-D nits complaints. Oh and I see Russ’s now.

spt

> On Jan 14, 2022, at 08:13, [email-masked] wrote:
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Tadahiko Ito <[email-masked]>
Date: Sat, 15 Jan 2022 04:15:05 +0900

Thanks Russ

> SECTION 4:
> I am missing something.  I understand the goal is to prevent a
certificate from having both code-signing and document-siging EKU OIDs,
> and that you are being abstract so accommodate the handling of
yet-to-be-defined EKU OIDs.  However,
> where do the restrictions come from?  Should there be a registry to hold
the values?
> If not, will different implementers make different choices?

I was imagining that,
restrictions set is derived and implemented from (or configured with) the
policy to which the implementation conforms.
I believe it should be clearer with that sentence.

I believe the policy could serve as the registry, but can be done through
other mechanisms.
However, if we want to restrict some combination of KeyPurposeID with
interoperable manner, we should agree on some mechanism (we believe is
beyond scope of this I-D).

In addition, I noticed that it might be confusing becouse of words
"Excluded EKUs ", "permitted EKU", etc.. I was thinking that we had better
to fix "Excluded KeyPurposeIds", "Permitted KeyPurposeIds", etc..

Regards Tadahiko Ito

---

From: Sean Turner <[email-masked]>
Date: Tue, 18 Jan 2022 10:51:16 -0500

Hi Russ,

I addressed the nits as part of this PR:
https://github.com/lamps-wg/documentsigning-eku/pull/7

The changes are mixed in with a lot of other formatting tweaks, but they are there.

spt

> On Jan 14, 2022, at 10:24, Russ Housley <[email-masked]> wrote:
> 
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm