Subject: Re: [lamps] [EXTERNAL] Call for adoption for draft-ito-documentsigning-eku

From: Mike Ounsworth <[email-masked]>
Date: Wed, 11 Aug 2021 18:37:58 +0000

Entrust supports the direction of creating a reserved EKU OID which can be used to indicate that a CA issues document signing certificates or that a subscriber certificate is a document signing certificate. RFC 5280 provides EKU OIDs for the other public trust certificates which we issue. It would make sense to have another OID for document signing.

I have not followed the complete discussion on this draft, but we support the general concept.

---
Mike Ounsworth
Software Security Architect, Entrust

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: July 26, 2021 5:13 PM
To: LAMPS WG <[email-masked]>
Subject: [EXTERNAL] [lamps] Call for adoption for draft-ito-documentsigning-eku

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________
We have already discussing the assignment of an object identifier for document signing, and we had a presentation at IETF 111.  Following the IETF 111 presentation, no one spoke against against adoption of this work.  This call is to see if there is rough consensus for the LAMPS WG to proceed with this work.

Please send your reply about whether you support adopting draft-ito-documentsigning-eku as a WG document.  Please voice your support or raise concerns by 14 August 2021.

For the LAMPS WG Chairs,
Russ
_______________________________________________
Spasm mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!NfhmBW_ewUS5UbfURRsf2Wx62pnE3Ez00rdlztPQHgBvFHmO24tDxxb-ul-ujJjLWY2pVm4xbA$

---

From: Russ Housley <[email-masked]>
Date: Mon, 16 Aug 2021 16:39:01 -0400

Many people have spoken in support of this document, and two have spoken against.

If it is to be adopted, an addition to the chart is needed:

   The LAMPS WG will support new definitions of objects registered in the following
   IANA registries: SMI Security for S/MIME Mail Security (1.2.840.113549.1.9.16)
   and SMI Security for PKIX (1.3.6.1.5.5.7).

What do people think about this approach?

Russ

> On Jul 28, 2021, at 5:13 PM, Russ Housley <[email-masked]> wrote:
> 
> After consultation with the Security AD for this group, a small recharter is necessary to adopt this document.
> 
> So, I amend this call for adoption as follows:
> 
> Please send your reply about whether you support adopting draft-ito-documentsigning-eku as a WG document after a recharter.  Please voice your support or raise concerns by 14 August 2021.
> 
> For the LAMPS WG Chairs,
> Russ
> 
> 
>> On Jul 26, 2021, at 6:13 PM, Russ Housley <[email-masked]> wrote:
>> 
>> https://www.ietf.org/mailman/listinfo/spasm
> 
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 17 Aug 2021 12:45:26 -0400

> What do people think about this approach?

The above strikes me as an extremely broad change to the charter,
permitting apparently arbitrary work within LAMPS as long as it manages
to touch those IANA registries.

Both objectors to and supporters of the proposed document-signing work
appear to be concerned about proliferation of Extended Key Usage (EKU)
OIDs with semantics that are ill-defined enough to produce interop
failures, and to potentially increase the costs of certificate
management.

I can see the need for a document-signing EKU that is neither for code
nor e-mail messages, and if relying party (RP) implementers are
interested in implementing an EKU check in specific contexts, i can see
the reason to adopt this work in LAMPS -- so long as the document under
WG control grows sufficient details to actually promote sensible
patterns of interoperability.  (though if the RP implementers are mostly
found somewhere else, i have no objection to them coordinating in a
different standards-body setting to specify a doc-signing EKU)

But opening the charter wide to encompass any work that happens to touch
one of the arcs mentioned above seems like writing a blank check.  Maybe
that's what the WG wants to do, but it doesn't look like it will help
the WG stay focused.

I'm not sure why the charter needs this particular update.  Would adding
"… in the direct service of the other goals in this charter" to the
proposed text satisfy the charter revision needs to consider this
document for adoption?  If so, it would help avoid looking like we're a
dumping ground for anyone who wants to try to claim a point in either of
these arcs for any particular topic.

      --dkg

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Aug 2021 14:08:10 -0400

Daniel Kahn Gillmor <[email-masked]> wrote:
    >> The LAMPS WG will support new definitions of objects registered in the
    >> following IANA registries: SMI Security for S/MIME Mail Security
    >> (1.2.840.113549.1.9.16) and SMI Security for PKIX (1.3.6.1.5.5.7).
    >>

    > failures, and to potentially increase the costs of certificate

Being charted to be able to make a billion EKUs doesn't mean that the WG or
the IESG will sign off on doing that.

    > But opening the charter wide to encompass any work that happens to
    > touch one of the arcs mentioned above seems like writing a blank check.
    > Maybe that's what the WG wants to do, but it doesn't look like it will
    > help the WG stay focused.

I want to avoid stopping work every 4 weeks to revise the charter.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Russ Housley <[email-masked]>
Date: Tue, 17 Aug 2021 16:57:36 -0400

DKG:

I suppose it does allow many OIDs to be assigned.  I was trying to come up with a way to allow simple documents that assign an OID and achieve WG consensus to move along without too much administrative overhead.

All of the other approaches that I considered allowed the assignment of a single OID for one specific purpose.  I'm open to alternatives.

Russ

> On Aug 17, 2021, at 2:08 PM, Michael Richardson <[email-masked]> wrote:
>

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 19 Aug 2021 12:34:59 -0400

On Tue, Aug 17, 2021 at 4:57 PM Russ Housley <[email-masked]> wrote:

> DKG:
>
> I suppose it does allow many OIDs to be assigned.  I was trying to come up
> with a way to allow simple documents that assign an OID and achieve WG
> consensus to move along without too much administrative overhead.

Is that the goal of LAMPS? That is, such generic assignment seems to run
counter to the (present) charter of being Limited, with known
constituencies interested in real deployment with at least one sufficiently
well-specified approach. The generic OID assignment seems to run counter to
that, and reintroduce the issues of PKIX.

Assigning new OIDs equally seems to run counter to simplify clarify
existing PKIX and S/MIME WG documents; typically, a new OID would be used
to describe new functionality, rather than clarify existing.

That's not to say we can't charter to become PKIX 2.0, if that's the
explicit goal, but it does seem to be a shift from a closed set to a very
open set, as flagged by DKG.

While Michael mentions wanting to avoid stopping work every 4 weeks for a
recharter, I'd be remiss if I didn't mention my goal is to ensure we don't
become PKIX 2.0 where we continue to add to the ever growing, ever
unnecessary, ever uninteroperable set of features that we call PKIX, and I
worry this language would.

---

From: Russ Housley <[email-masked]>
Date: Tue, 24 Aug 2021 15:10:38 -0400

All:

Obviously any document that would make an assignment in any of the PKIX or S/MIME registries needs consensus, with the possible exception of the module OIDs, which have no impact on interoperability.

I agree that we want the WG to only make new assignments where there is intent to implement.  How about the following?

  The LAMPS WG will support new definitions of objects registered in the following
  IANA registries when there is a known constituency interested in real deployment
  of the new registration: SMI Security for S/MIME Mail Security (1.2.840.113549.1.9.16)
  and SMI Security for PKIX (1.3.6.1.5.5.7).

To be clear about the scope, I have copied the topic associate with these registries below.

The PKIX OID registry covers:

SMI Security for PKIX Module Identifier
SMI Security for PKIX Certificate Extension
SMI Security for PKIX Policy Qualifier
SMI Security for PKIX Extended Key Purpose
SMI Security for PKIX CMP Information Types
SMI Security for PKIX CRMF Registration
SMI Security for PKIX CRMF Registration Controls
SMI Security for PKIX CRMF Registration Information
SMI Security for PKIX Algorithms
SMI Security for PKIX CMC Controls
SMI Security for PKIX CMC GLA Requests and Responses
SMI Security for PKIX Other Name Forms
SMI Security for PKIX Personal Data Attributes
SMI Security for PKIX Attribute Certificate Attributes
SMI Security for PKIX Qualified Certificate Statements
SMI Security for PKIX CMC Content Types
SMI Security for PKIX OIDs Used Only for Testing
SMI Security for PKIX Certificate Policies
SMI Security for PKIX CMC Error Types
SMI Security for PKIX Revocation Information Types
SMI Security for PKIX SCVP Check Types
SMI Security for PKIX SCVP Want Back Types
SMI Security for PKIX SCVP Validation Policies and Algorithms
SMI Security for PKIX SCVP Name Validation Policy Errors
SMI Security for PKIX SCVP Basic Validation Policy Errors
SMI Security for PKIX SCVP Distinguished Name Validation Policy Errors
SMI Security for PKIX Other Logotype Identifiers
SMI Security for PKIX Proxy Certificate Policy Languages
SMI Security for PKIX Proxy Matching Rules
SMI Security for PKIX Subject Key Identifier Semantics 

The S/MIME OID Registry covers:

SMI Security for S/MIME Module Identifier
SMI Security for S/MIME CMS Content Type
SMI Security for S/MIME Attributes
SMI Security for S/MIME Algorithms
SMI Security for S/MIME Certificate Distribution Mechanisms
SMI Security for S/MIME Signature Policy Qualifier 
SMI Security for S/MIME Commitment Type Identifier
SMI Security for S/MIME Test Security Policies 
SMI Security for S/MIME Control Attributes for Symmetric Key Distribution 
SMI Security for S/MIME Signature Type Identifiers 
SMI Security for X.400 Encoded Information Types (EIT) for S/MIME objects 
SMI Security for S/MIME Capabilities (other than cryptographic algorithms)
SMI Security for S/MIME Portable Symmetric Key Container (PSKC) Attributes
SMI Security for S/MIME Other Recipient Info Identifiers 

Russ

> On Aug 19, 2021, at 12:34 PM, Ryan Sleevi <[email-masked]> wrote:
> 
> 
> 
> On Tue, Aug 17, 2021 at 4:57 PM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> DKG:
> 
> Is that the goal of LAMPS? That is, such generic assignment seems to run counter to the (present) charter of being Limited, with known constituencies interested in real deployment with at least one sufficiently well-specified approach. The generic OID assignment seems to run counter to that, and reintroduce the issues of PKIX.
> 
> Assigning new OIDs equally seems to run counter to simplify clarify existing PKIX and S/MIME WG documents; typically, a new OID would be used to describe new functionality, rather than clarify existing.
> 
> That's not to say we can't charter to become PKIX 2.0, if that's the explicit goal, but it does seem to be a shift from a closed set to a very open set, as flagged by DKG.
> 
> While Michael mentions wanting to avoid stopping work every 4 weeks for a recharter, I'd be remiss if I didn't mention my goal is to ensure we don't become PKIX 2.0 where we continue to add to the ever growing, ever unnecessary, ever uninteroperable set of features that we call PKIX, and I worry this language would.

---

From: Mike Ounsworth <[email-masked]>
Date: Tue, 24 Aug 2021 19:15:35 +0000

Do you need a critical mass of interested implementors, or is a single constituent enough?

---
Mike Ounsworth

From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: August 24, 2021 2:11 PM
To: LAMPS WG <[email-masked]>
Subject: [EXTERNAL] Re: [lamps] Call for adoption for draft-ito-documentsigning-eku

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
All:

Russ

On Aug 19, 2021, at 12:34 PM, Ryan Sleevi <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Aug 17, 2021 at 4:57 PM Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:
DKG:

Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

---

From: Russ Housley <[email-masked]>
Date: Tue, 24 Aug 2021 15:19:54 -0400

Remember that to top of the charter says:

   The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working 
   Group is chartered to make updates where there is a known constituency 
   interested in real deployment and there is at least one sufficiently 
   well specified approach to the update so that the working group can 
   sensibly evaluate whether to adopt a proposal.

I was trying to align with that context.

The traditional definition for rough consensus for the document is adequate from my perspective.

Russ

> On Aug 24, 2021, at 3:15 PM, Mike Ounsworth <[email-masked]> wrote:
> 
> From: Spasm <[email-masked] <mailto:[email-masked]>> On Behalf Of Russ Housley
> To: LAMPS WG <[email-masked] <mailto:[email-masked]>>
> On Aug 19, 2021, at 12:34 PM, Ryan Sleevi <[email-masked] <mailto:[email-masked]>> wrote:
>  
>  
>

---

From: Mike Ounsworth <[email-masked]>
Date: Tue, 24 Aug 2021 19:23:59 +0000

Makes sense.

I'm sure that over the years, LAMPS has had no lack of submissions that smell like proprietary solutions.

---
Mike Ounsworth

From: Russ Housley <[email-masked]>
Sent: August 24, 2021 2:20 PM
To: Mike Ounsworth <[email-masked]>
Cc: LAMPS WG <[email-masked]>
Subject: Re: [EXTERNAL] Re: [lamps] Call for adoption for draft-ito-documentsigning-eku

Russ

On Aug 24, 2021, at 3:15 PM, Mike Ounsworth <[email-masked]<mailto:[email-masked]>> wrote:

---
Mike Ounsworth

From: Spasm <[email-masked]<mailto:[email-masked]>> On Behalf Of Russ Housley
Sent: August 24, 2021 2:11 PM
To: LAMPS WG <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [lamps] Call for adoption for draft-ito-documentsigning-eku

Russ

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Aug 2021 21:18:20 -0400

Russ Housley <[email-masked]> wrote:
    > Obviously any document that would make an assignment in any of the PKIX
    > or S/MIME registries needs consensus, with the possible exception of
    > the module OIDs, which have no impact on interoperability.

    > I agree that we want the WG to only make new assignments where there is
    > intent to implement.  How about the following?

    > To be clear about the scope, I have copied the topic associate with

I have no problem with the charter text.

I have a problem with the WG seeming to continuing to spend more time arguing over
changes to charter text than working on the actual documents.  Maybe it's a
bikeshed situation (arguing over charter text is easier than getting involved).
This is a complaint to the IESG.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [