Subject: [lamps] Draft LAMPS Recharter

From: Russ Housley <[email-masked]>
Date: Wed, 2 May 2018 10:41:44 -0400

Based on the discussion in London and the "Potential Topics for LAMPS Recharter" mail thread.  We propose the attached charter text.  Please review and comment.

Russ & Tim

= = = = = = = = =

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 a discovery mechanism for CAA records to replace the one
described in RFC 6844.  Implementation experience has demonstrated an
ambiguity in the handling of CNAME and DNAME records during discovery
in RFC 6844, and subsequent discussion has suggested that a different
discovery approach would resolve limitations inherent in that approach.

2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME.
Unlike the previous hashing standards, the SHA-3 family of functions are
the outcome of an open competition.  They have a clear design rationale
and have received a lot of public analysis, giving great confidence that
the SHA-3 family of functions are secure.  Also, since SHA-3 uses a very
different construction from SHA-2, the SHA-3 family of functions offers
an excellent alternative.  In particular, SHAKE128/256 and SHAKE256/512
offer security and performance benefits.

3. 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 them pointless.

4. Specify the use of a pre-shared key (PSK) along with other key 
management techniques with supported by the Cryptographic Message
Syntax (CMS) as a near-term mechanism to protect present day
communication from the future invention of a large-scale quantum
computer.  The invention of a such a quantum computer would pose a
serious challenge for the key management algorithms that are widely
deployed, especially the key transport and key agreement algorithms
used today with the CMS to protect S/MIME messages.

5. Specify the use of hash-based signatures with the Cryptographic
Message Syntax (CMS).  A hash-based signature uses small private and
public keys, and it has low computational cost; however, the signature
values are quite large.  For this reason they will probably not be used
for signing X.509 certificates or S/MIME messages, but they are secure
even if a large-scale quantum computer is invented.  These properties
make hash-based signatures useful in some environments, such a the
distribution of software updates.

6. Specifies a certificate extension that is carried in a self-signed
certificate for a trust anchor, which is often called a Root
Certification Authority (CA) certificate, to identify the next
public key that will be used by the trust anchor.

In addition, the LAMPS WG may investigate other updates to documents
produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt
any of these potential work items without rechartering.

MILESTONES

Mar 2018: Adopt a draft for rfc6844bis
Apr 2018: Adopt a PKIX draft for SHAKE128/256 and SHAKE256/512
Apr 2018: Adopt a S/MIME draft for SHAKE128/256 and SHAKE256/512
Jun 2018: Adopt a draft for short-lived certificate conventions
Jun 2018: Adopt a draft for the CMS with PSK 
Jun 2018: Adopt a draft for hash-based signatures with the CMS
Jun 2018: Adopt a draft for root key rollover certificate extension 
Jul 2018: rfc6844bis sent to IESG for standards track publication
Aug 2018: Root key rollover certificate extension sent to IESG for
            informational publication
Sep 2018: SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for
            standards track publication
Sep 2018: SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for
            standards track publication
Oct 2018: Short-lived certificate conventions sent to IESG for BCP
            publication
Oct 2018: The CMS with PSK sent to IESG for standards track publication
Dec 2018: Hash-based signatures with the CMS sent to IESG for standards
            track publication

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 2 May 2018 20:36:19 +0000

Hi Russ,

Looks great. One minor correction:
s/they will probably not be used for signing X.509 certificates or S/MIME messages,/they might not be used for signing X.509 certificates or S/MIME messages,

And one question about 4. I think I didn't see many comments on this one in the recharter email thread. I have a concern that draft-housley-cms-mix-with-psk will not see great deployment. draft-ietf-ipsecme-qr-ikev2 is similar, but given the existing IKEv2 wide deployment, draft-ietf-ipsecme-qr-ikev2 had to exist as temporary solution in order to prevent downgrades to IKEv1 because of QC concerns. I don't see the same issue for CMS. And given the challenge with establishing the PSK, it will likely not see wide adoption before the NIST PQ Project standardizes on PQ algorithms that can go into CMS.

Rgs,
Panos

From: Spasm [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Wednesday, May 02, 2018 10:42 AM
To: LAMPS <[email-masked]>
Subject: [lamps] Draft LAMPS Recharter

Russ & Tim

= = = = = = = = =

MILESTONES

---

From: Russ Housley <[email-masked]>
Date: Wed, 2 May 2018 16:45:23 -0400

> On May 2, 2018, at 4:36 PM, Panos Kampanakis (pkampana) <[email-masked]> wrote:
> 
> Hi Russ,
> 

Sure.

>  
> And one question about 4. I think I didn’t see many comments on this one in the recharter email thread. I have a concern that draft-housley-cms-mix-with-psk will not see great deployment. draft-ietf-ipsecme-qr-ikev2 is similar, but given the existing IKEv2 wide deployment, draft-ietf-ipsecme-qr-ikev2 had to exist as temporary solution in order to prevent downgrades to IKEv1 because of QC concerns. I don’t see the same issue for CMS. And given the challenge with establishing the PSK, it will likely not see wide adoption before the NIST PQ Project standardizes on PQ algorithms that can go into CMS.

I asked our AD about this, and he felt that a near-term CMS solution was worth discussing.  The IKE environment is somewhat different, and it is worth discussing the size of the group that would need access to the PSK for this to be viable.  Obviously, it is not a PSK if everyone on the public Internet has access to it.

Russ

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 2 May 2018 17:06:18 -0400

On Wed, May 2, 2018 at 10:41 AM, Russ Housley <[email-masked]> wrote:

> Based on the discussion in London and the "Potential Topics for LAMPS
> Recharter" mail thread.  We propose the attached charter text.  Please
> review and comment.
>
> Russ & Tim
>
> = = = = = = = = =
>

I didn't see much discussion on the list in support for this, but
apologies, I missed the discussion in SECDISPATCH when this draft was
discussed.

Is this being envisioned for the use in the PKI typically called the "Web
PKI", or is this being seen as a draft for private use cases? I have read
the draft, and do not feel this was clearly and unambiguously answered.

I ask because, for various policy reasons, I would expect that undertaking
this work may result in policies that explicitly prohibit it from being
deployed on the Web PKI.

As a practical matter, the draft acknowledges an alternative design
(namely, OCSP stapling), but its two objections to this work do not hold.
As a consequence, I have concerns about the motivations for and the
alternatives considered, and thus don't think LAMPS needs to consider such
work in scope at this time.

---

From: Russ Housley <[email-masked]>
Date: Wed, 2 May 2018 17:13:17 -0400

> On May 2, 2018, at 5:06 PM, Ryan Sleevi <[email-masked]> wrote:
> 
> 
> 
> On Wed, May 2, 2018 at 10:41 AM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> I didn't see much discussion on the list in support for this, but apologies, I missed the discussion in SECDISPATCH when this draft was discussed.
> 
> Is this being envisioned for the use in the PKI typically called the "Web PKI", or is this being seen as a draft for private use cases? I have read the draft, and do not feel this was clearly and unambiguously answered.
> 
> I ask because, for various policy reasons, I would expect that undertaking this work may result in policies that explicitly prohibit it from being deployed on the Web PKI.
> 
> As a practical matter, the draft acknowledges an alternative design (namely, OCSP stapling), but its two objections to this work do not hold. As a consequence, I have concerns about the motivations for and the alternatives considered, and thus don't think LAMPS needs to consider such work in scope at this time.

I was in the room for the SECDISPATCH discussion.  I'll share my view at the end of that discussion.  Many people were interested in short-lived certificates, and not just for the Web PKI.  Some people understood that the Web PKI might not be able to use short-lived certificates right away, but if this work isn't done, then the Web PKI will not ever be able to use them.  So, other PKI environments might be able to make immediate use of short-lived certificates, and the Web PKI might also make use of them someday.

Russ

---

From: Yoav Nir <[email-masked]>
Date: Thu, 3 May 2018 00:20:42 +0300

> On 3 May 2018, at 0:06, Ryan Sleevi <[email-masked]> wrote:
> 
> 
> 

Hi, Ryan.

The main motivation for me is things other than the Web PKI. There is nothing in the draft that makes it not work for the Web PKI, but I would like to leave it to the group to decide whether the Web PKI is explicitly excluded.

There is a short-term certificate document that *is* for the Web PKI. It is in the ACME working group.
https://tools.ietf.org/html/draft-ietf-acme-star-03 <https://tools.ietf.org/html/draft-ietf-acme-star-03>

Despite having some authors in common, the use cases are different.

HTH

Yoav

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 03 May 2018 02:19:47 +0000

On Wed, May 2, 2018 at 5:20 PM Yoav Nir <[email-masked]> wrote:

> The main motivation for me is things other than the Web PKI. There is
> nothing in the draft that makes it not work for the Web PKI, but I would
> like to leave it to the group to decide whether the Web PKI is explicitly
> excluded.
>
> https://tools.ietf.org/html/draft-ietf-acme-star-03
>
<https://tools.ietf.org/html/draft-ietf-acme-star-03>
> Despite having some authors in common, the use cases are different.

I’m curious to understand more of these use cases, as to understand the
presumed implementors for the running code. I’m guessing that, given the
goal just presented, these are going to be locally managed CAs and/or for
server-to-server mutual auth scenarios?

My biggest qualm is that the draft seems predicated on two statements about
why existing technology is insufficient:
1) OCSP Stapling requires servers to support Stapling
2) Client certs cannot staple

There doesn’t seem to be any explanation as to why #1 doesn’t equally apply
(if not moreso?) to this use case, given the need to replace the
certificates frequently due to their short lifetime. The efforts towards
ACME-STAR are illustrative of exactly that - a need for new management
capabilities.

With regard to #2, I’m trying to understand how this compares to TLS1.3’s
restructuring of the Certificate message, which seems like it will have a
significantly broader adoption and a lower barrier to adoption, especially
in the case of client certs.

While presented as specific examples, I think they more generally speak to
a lack of definition as to the problem space or audience within the current
draft, thus making it difficult to see how adoption, implementation, or
consensus will emerge. While personally skeptical of the idea, I fully
accept that there may be some non-WebPKI use cases for this that could
benefit from this work, but it seems like nailing those down and
identifying them should be encouraged as a prerequisite for adoption. In
particular, it seems like fleshing how this is meaningfully different in
use case or deployment from existing technologies such as OCSP Stapling
seems good, so as to prevent an unnecessarily proliferation of ways to
solve the same basic problem.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 3 May 2018 07:47:03 -0400

On Wed, May 2, 2018 at 10:19 PM, Ryan Sleevi <[email-masked]> wrote:

>> I ask because, for various policy reasons, I would expect that
>> undertaking this work may result in policies that explicitly prohibit it
>> from being deployed on the Web PKI.
>>
> My biggest qualm is that the draft seems predicated on two statements
> about why existing technology is insufficient:
> There doesn’t seem to be any explanation as to why #1 doesn’t equally
> apply (if not moreso?) to this use case, given the need to replace the
> solve the same basic problem..
>

​The reason to move to short term certs is simple and has nothing to do
with insufficiency: It is simply more efficient.

Once you automate the process of certificate management, the move to short
lived certs is inevitable and obvious because then the server only needs to
cope with a single data object rather than two equivalent data objects.

With a long lived cert plus OCSP:

* The server has to update its cert every X days and update its OCSP token,
a different code path, every day.
* The client has to process the cert and then process the OCSP token, each
of which has a separate trust path.

With a short lived cert:

* The server has to update its cert every days.
* The client has to process the cert.

I do not understand where client certificates come into the argument.
Obviously, the same approach may be applied to client certs but why would
anyone bother when the browser UI for client auth is so utterly useless?

I don't want to get into business models but I will observe that my
employer is making good money by adding back features some folk have dissed
over the years.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 May 2018 05:50:05 -0700

> this work may result in policies that explicitly prohibit it from being

Ryan,

Do you think you could elaborate on this point?

Thanks,
-Ekr

> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>
>

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 03 May 2018 13:25:38 +0000

On Thu, May 3, 2018 at 7:47 AM Phillip Hallam-Baker <[email-masked]>
wrote:

>>> Is this being envisioned for the use in the PKI typically called the
>>> "Web PKI", or is this being seen as a draft for private use cases? I have
>>> read the draft, and do not feel this was clearly and unambiguously answered.
>>>
>> While presented as specific examples, I think they more generally speak
>> to a lack of definition as to the problem space or audience within the
>> current draft, thus making it difficult to see how adoption,
>> implementation, or consensus will emerge. While personally skeptical of the
>> idea, I fully accept that there may be some non-WebPKI use cases for this
>> that could benefit from this work, but it seems like nailing those down and
> * The server has to update its cert every X days and update its OCSP
> token, a different code path, every day.

To make sure I understand this claim: Is the view that adding yet another
method, which is not as expressive and with a host of trade offs, will
somehow payoff at some point in the future in which clients and servers no
longer have to implement or care about revocation data?

I would rather like to think “the spec is prettier if we do it this way” is
a poor justification for taking on work, so I was hoping a bit more
substance to a reply.

> anyone bother when the browser UI for client auth is so utterly useless?

It’s unclear: you read the draft and are disagreeing with it, or did you
read me reply and weren’t aware I was referencing the draft? The mention of
browsers leads me to believe the latter, because the message I was replying
to identified this work was not for the Web PKI, but if the former, I’m
hoping to bring a bit more clarity to the position.

> employer is making good money by adding back features some folk have dissed

I’m not sure how this furthers the discussion on the merits. Perhaps you
could elaborate how it fits with what we’re discussing? Or was this an
unrelated non sequitor you were calling out as such before making anyways?
I had a bit of trouble parsing.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 03 May 2018 13:34:21 +0000

> Do you think you could elaborate on this point?

It seems a bit less germane to discuss potential root store policy here in
the IETF, but there are already policies around lifetimes - such as maximum
certificate lifetimes or minimum OCSP response validity durations. Despite
being technically capable of issuance, I fully anticipate minimum lifetimes
being required for certificate validity.

Validity merely externalizes cost to PKI participants - too long a
validity, for example, carries greater risk of both key compromise and
information staleness. Models such as revocation try to remediate that, but
shift more burden onto relying parties. Actions such as too short validity
also shifts burden onto clients and the ecosystem - notably in terms of
client clock issues, by increasing the precision and accuracy necessary.

As it relates to the draft, however, it has further flaws in the design
assumptions, similar to these concerns. For example, suggesting that CAs
would be able to use shorter-lived certificates to no longer keep track of
what they issue is fundamentally incompatible with a Web PKI in which every
CA is accountable for what it issues: presently, for between five to seven
years from issuance. This is orthogonal to things like Certificate
Transparency, and is about operational requirements.

I expect the floor for certificates to bottom out at around 21-30 days for
publicly trusted certificates for the next decade, which potentially would
be mandated by requirements on issuance policy.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 3 May 2018 10:00:50 -0400

On Thu, May 3, 2018 at 9:25 AM, Ryan Sleevi <[email-masked]> wrote:

>> Once you automate the process of certificate management, the move to
>> short lived certs is inevitable and obvious because then the server only
>> needs to cope with a single data object rather than two equivalent data
>> objects.
>>
>> * The client has to process the cert and then process the OCSP token,
>> each of which has a separate trust path.
>>
>

Short lived certs are exactly as expressive as long term plus OCSP with
pre-generated validity tokens.

While the intent of the original OCSP proposal (which I wrote the draft for
and can thus speak with authority) was to enable insurance of individual
transactions, I am not aware of any use of OCSP for that purpose. Nor do I
expect any such use to arrive in the future as we subsequently developed
the TAXI (Trust Assertion XML Infrastructure) for that purpose which is now
known as SAML.

> a poor justification for taking on work, so I was hoping a bit more

​Simpler is better. ​

Changing practice in the browser world is certainly possible but has a long
payback time as it takes quite a while for browsers to update.

Instituting best practice for Web Services is a totally different matter as
there are new services being deployed every day and those that exist are
often kept up to date very aggressively.

> hoping to bring a bit more clarity to the position.

​At this point in time, PKIX has established itself as a mechanism ​for
supporting server authentication. PKIX has not established itself as a
mechanism for user authentication. SAML has been vastly more successful in
that role. And I do not see that changing.

TLS Client auth is not very useful as a means of authenticating users in a
Web browser but it is very widely used as a means of authenticating
Services to other Services.

The distinction between 'client' and 'server' is not very useful here
because all a 'client' is, is the party that initiates a transaction. PKIX
is for authenticating services whether to users or to other services and
regardless of whether it is the initiator or responder in a transaction.

Of course we need to move to short lived certs for services because in the
modern deployment, a service typically lives on a particular host for a
matter of a few days or even hours. Generating keys valid for up to 2 years
and then churning them round a data center simply means that every machine
in that data center is a potential point of compromise.

An obvious control to help mitigate this problem is to limit cert validity
to the length of time we expect the service to remain on a particular
machine and to generate new keying material every time the service moves to
a new host.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 3 May 2018 10:41:23 -0400

On Thu, May 3, 2018 at 10:00 AM, Phillip Hallam-Baker <[email-masked]

>> On Thu, May 3, 2018 at 7:47 AM Phillip Hallam-Baker <
>> [email-masked]> wrote:
>>
>>>
> While the intent of the original OCSP proposal (which I wrote the draft
> for and can thus speak with authority) was to enable insurance of
> individual transactions, I am not aware of any use of OCSP for that
> purpose. Nor do I expect any such use to arrive in the future as we
> subsequently developed the TAXI (Trust Assertion XML Infrastructure) for
> that purpose which is now known as SAML.
>
> I would rather like to think “the spec is prettier if we do it this way”
>> is a poor justification for taking on work, so I was hoping a bit more
>> substance to a reply.
>>
>
> ​Simpler is better. ​
>
> Changing practice in the browser world is certainly possible but has a
> long payback time as it takes quite a while for browsers to update.
>
> Instituting best practice for Web Services is a totally different matter
> as there are new services being deployed every day and those that exist are

While we may disagree as to whether this work is simpler - the draft I
think demonstrates that it's not, in practice, for any party involved
(relying party, CA, or service operator). However, I think there's
something to your point here which gets to the heart of whether LAMPS
should be undertaking this work. This is now the second message that you've
referenced the "browser world". While the initial replies suggested
non-browser/non-WebPKI case, which may be perfectly reasonable, I'm trying
to fully understand your position: Is it that this work is intended for the
browser case? If browsers explicitly prohibit the use of such work, or
reject implementation, does that undermine or devalue the work and
implementation experience? Because I do not see this being supported in
browsers, and I think it's extremely likely of being explicitly forbidden.

I highlight this in order to make sure there's consensus on what the draft
is for - since the draft itself leaves it ambiguous - and whether or not
there's a representative sample of implementors for that target use case.
The nature of this question is what plagued PKIX, and if we're trying to
ensure that LAMPS does not succumb to the overbroad, unadopted, zombie
effort that WGs can succumb to, then my $.02 we should make sure that the
goal and uses are as crisp as possible before adopting that work as a WG.

We can (and should) work out the "How" as a WG document, but the "Why"
seems like it should be addressed before adopting and incorporating into
the charter.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 May 2018 15:46:44 +0100

I don't have a position on the draft in question but...

> goal and uses are as crisp as possible before adopting that work as a WG.

... that certainly resonates with me;-)

I hope lamps does stick with the "only adopt if we think it's
really quite likely to be used" aspect of the charter.

S.

---

From: Tim Hollebeek <[email-masked]>
Date: Thu, 3 May 2018 22:01:03 +0000

(chair hat off)

I was at SECDISPATCH in London.  I'm in favor of short-lived certificates in 
general, but as I stated in London, I have many serious problems with this 
draft, which include the problems Ryan mentioned, and many more.  It's going 
to need a lot of work before we can consider adopting it.

That said, it's a draft, and it was pretty clear that SECDISPATCH wanted LAMPS 
to re-charter and consider it.  And I actually agree with that.  I think the 
issues with the draft that people have raised deserve discussion, and I hope 
Yoav understands that these serious concerns will need to be addressed before 
the document can be adopted.

But I support changing the LAMPS charter so that LAMPS can discuss the draft.

-Tim

> -----Original Message-----
> From: Spasm [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Thursday, May 3, 2018 10:47 AM
> To: Ryan Sleevi <[email-masked]>; Phillip Hallam-Baker
> <[email-masked]>
> Cc: LAMPS <[email-masked]>; Russ Housley <[email-masked]>; Yoav Nir
> <[email-masked]>
> Subject: Re: [lamps] Draft LAMPS Recharter
>
>
> > The nature of this question is what plagued PKIX, and if we're trying
> > to ensure that LAMPS does not succumb to the overbroad, unadopted,
> > zombie effort that WGs can succumb to, then my $.02 we should make
> > sure that the goal and uses are as crisp as possible before adopting that 
> > work
> as a WG.
>
> I hope lamps does stick with the "only adopt if we think it's really quite 
> likely to
> be used" aspect of the charter.
>
> S.

---

From: Russ Housley <[email-masked]>
Date: Wed, 9 May 2018 15:09:10 -0400

Based on the I-D that Wei recently posted, do people think we should add a work item:

7. Specify new extended key usage identifiers when there is a
significant constituency that will make use of certificates that
include that new identifier.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Wed, 9 May 2018 12:49:42 -0700

I am unsure that this is a good use of the WG time.  I think that this can
be done just as easily through the Independent Submissions stream.

Jim

> From: Spasm <[email-masked]> On Behalf Of Russ Housley
> Sent: Wednesday, May 9, 2018 12:09 PM
> 7. Specify new extended key usage identifiers when there is a significant
> constituency that will make use of certificates that include that new
> identifier.
> 
> Russ
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 9 May 2018 20:22:55 +0000

Yes.  Figuring out if that's true will be hard, but that's why we get paid the big bucks. :)