Subject: Re: [lamps] Proposed recharter text

From: Tadahiko Ito <[email-masked]>
Date: Tue, 16 Feb 2021 04:41:41 +0900

Hi Ryan

As far as can I see, RFC5280 is based on the directory system which seems
to be a general and ideal concept. As a result, 5280 seems to have become a
general and ideal "profile" for certificates. Since 5280 is general and
ideal (and too heavy), the actual implementations of PKI became a subset of
RFC5280.

I'm wondering if we can create some sort of a new Best Practice document
which assumes more specific use cases (e.g. webPKI, PKI with trust list and
without bridge, etc.) while making RFC5280 as an IS, which would fill in
the gaps.

(I am not sure if other forks will agree on such a document but ) doesn't
it solve your concern?

Regards Tadahiko Ito

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 15 Feb 2021 17:25:36 -0500

> (I am not sure if other forks will agree on such a document but ) doesn't

I think, in the context of an Internet Standard, that approach wouldn’t
work unless we had sub-profiles that exercised all the bits that the
(other) sub-profiles excised. Otherwise, we’re still leaving unimplemented
dead weight in.

Don’t get me wrong, I think there is potential value in working to reflect
the rough consensus and running code, given the now three decades of X.509
experience, but my concern was and remains that the proposed charter
language doesn’t provide any guidance or prioritization on how to resolve
the questions necessary to advance to an Internet Standard, which we know
have been contentious and uninteroperbale.

We can:

A) accept it as-is, but lack an objective or reliable way to resolve these
disputes that (to this day) are unresolved among different communities

B) Try to find agreement on narrowing the community in the charter, such
that we have a rubric to evaluate options against

C) Attempt to progress to an Internet Standard, but not actually define the
interoperable profile that is robust and reliable. Instead, the goal is to
rather document the building blocks and semantics that communities are
expect to further profile down, including forbidding such features. The
distinction between A and C is largely that A attempts to exclude to “a
sensible, implemented set”, while C accepts all as valid for purposes of
documentation.

I don’t have strong opinions on these - they’re all a lot of work. And I am
certainly not trying to argue for an inherent superiority of Web PKI vs
other PKIs. My observation was and is merely that the “one size fits all”
attempt that 5280 captures/inherited from its ITU and IETF spec forbears
doesn’t really reflect the operational reality, in code or practice.  Such
dissonance means it would be a considerable work item to resolve, and we
should figure out early, during chartering, where the preferred path of the
WG is leaning to, so we can resolve concerns consistently and expeditiously.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 15 Feb 2021 18:05:57 -0500

Tadahiko Ito <[email-masked]> wrote:
    > As far as can I see, RFC5280 is based on the directory system which
    > seems to be a general and ideal concept. As a result, 5280 seems to
    > have become a general and ideal "profile" for certificates. Since 5280
    > is general and ideal (and too heavy), the actual implementations of PKI
    > became a subset of RFC5280.

If you mean, the X.500 directory, then I think that RFC5280 is way beyond
those days.

    > I'm wondering if we can create some sort of a new Best Practice
    > document which assumes more specific use cases (e.g. webPKI, PKI with
    > trust list and without bridge, etc.) while making RFC5280 as an IS,
    > which would fill in the gaps.

Well, the problem is that the parts of 5280 which we don't use, which would
be omitted from this Best Practice document, are the parts that we need to
cut out of 5280 for it to advance to IS.

That's why I think that a (12-18 month) pause to get some of the PQC
work out of the way, and then a respin to make 5280bis would make sense.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Russ Housley <[email-masked]>
Date: Tue, 16 Feb 2021 10:31:04 -0500

I am hearing a lot of pushback against item 6 in the draft text.

I have not heard any concern about any other part of the draft text.

I suggest that we drop item 6 off the list for now, and get to work on the other items.  We can get some advice from the Security ADs prior to any future re-charter.

Russ

= = = = = = = =

The PKIX and S/MIME Working Groups have been closed for some time. Some
updates have been proposed to the X.509 certificate documents produced 
by the PKIX Working Group and the electronic mail security documents 
produced by the S/MIME Working Group.

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.

The LAMPS WG is now tackling these topics:

1. Specify the use of short-lived X.509 certificates for which no
revocation information is made available by the Certification Authority.
Short-lived certificates have a lifespan that is shorter than the time
needed to detect, report, and distribute revocation information.  As a
result, revoking short-lived certificates is unnecessary and pointless.

2. Update the specification for the cryptographic protection of email
headers -- both for signatures and encryption -- to improve the
implementation situation with respect to privacy, security, usability
and interoperability in cryptographically-protected electronic mail.
Most current implementations of cryptographically-protected electronic
mail protect only the body of the message, which leaves significant 
room for attacks against otherwise-protected messages.

3. The Certificate Management Protocol (CMP) is specified in RFC 4210, 
and it offers a vast range of certificate management options.  CMP is 
currently being used in many different industrial environments, but it 
needs to be tailored to the specific needs of such machine-to-machine 
scenarios and communication among PKI management entities.  The LAMPS 
WG will develop a "lightweight" profile of CMP to more efficiently 
support of these environments and better facilitate interoperable 
implementation, while preserving cryptographic algorithm agility.  In 
addition, necessary updates and clarifications to CMP will be 
specified in a separate document.  This work will be coordinated with 
the LWIG WG.

4. Provide concrete guidance for implementers of email user agents
to promote interoperability of end-to-end cryptographic protection
of email messages.  This may include guidance about the generation,
interpretation, and handling of protected messages; management of the
relevant certificates; documentation of how to avoid common failure
modes; strategies for deployment in a mixed environment; as well as
test vectors and examples that can be used by implementers and
interoperability testing.  The resulting robust consensus among email
user agent implementers is expected to provide more usable and useful
cryptographic security for email users.

5. Recent progress in the development of quantum computers pose a threat
to widely deployed public key algorithms.  As a result, there is a need
to prepare for a day when cryptosystems such as RSA, Diffie-Hellman,
ECDSA, ECDH, and EdDSA cannot be depended upon.  As a result, there are
efforts to develop standards for post-quantum cryptosystem (PQC)
algorithms that that will be secure if large-scale quantum computers
are ever developed.

a. Specify the use of PQC public key algorithms with the PKIX
certificates and the Cryptographic Message Syntax (CMS).

b. Develop specifications to facilitate a lengthy transition from
today's public key algorithms to PQC public key algorithms.  Unlike
previous algorithm transitions, time will be needed before there is
full confidence in the PQC public key algorithms.  Therefore,
transition mechanisms that combine traditional algorithms with PQC
algorithms will be needed for "hybrid key establishment" and "dual
signatures".  NIST defines "hybrid key establishment" as any key
establishment scheme that is a combination of two or more components
that are themselves cryptographic key-establishment schemes.  NIST
defines "dual signatures" as any signature scheme that consists of
two or more signatures on a common message.  The specifications
developed will enable PKIX and S/MIME protocols to support hybrid key
establishment and dual signature mechanisms.

In addition, the LAMPS WG may investigate other updates to documents
produced by the PKIX and S/MIME WG. The LAMPS WG may produce
clarifications where needed, but the LAMPS WG shall not adopt
anything beyond clarifications without rechartering.