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

[Russ Housley <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> 
> On Tue, Aug 17, 2021 at 4:57 PM Russ Housley <[e-mail] <mailto:[e-mail]>> 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.