Limited Additional Mechanisms for PKIX and SMIME
charter-ietf-lamps-08

[Ballot comment]
As written in my previous review, I find `The LAMPS WG is now tackling these topics which will be published as Standards Track, BCP, or Informational` rather vague as it covers everything rather than being specific by work items.

[Ballot comment]
I am okay with the proposed recharter, but I'd like to suggestion one change that I believe is helpful.

OLD: The LAMPS WG is now tackling these topics which will be published as Standards Track, BCP, or Informational:
NEW: The LAMPS WG is tackling the following topics, with the intent to publish Standards Track, BCP, or Informational documents:

[Ballot comment]
The charter should perhaps be rewritten as most of the text is about LAMPS being a brand new WG, which it is no more ;-)

More seriously, I find `The LAMPS WG is now tackling these topics which will be published as Standards Track, BCP, or Informational` rather vague as it covers everything rather than being specific by work items.

[Ballot comment]
Thanks for the update to cover the different document tracks through which the WG may publish documents.

Please pull in the existing WG milestones (most of which are not yet done) so they don't get lost.

[Ballot comment]
non-blocking, but....

    The US National Institute of Standards and Technology (NIST) has
    produced quantum-resistant public-key cryptographic algorithm standards.
    In addition, CFRG may vet other quantum-resistant public key cryptographic
    algorithms.

Why not just omit this to prevent putting the finger on the NIST vs non-NIST algorithms ?
Similarly, for:

    one or more NIST PQC key-establishment algorithm or a PQC key-establishment algorithm vetted by the CFRG

and:

    one of the key derivation functions in NIST SP 800-56C, or a key derivation function vetted by the CFRG.

(note additionally the "or" in the last sentence could be interpreted to mean "no NIST KDF, only a CFRG KDF" depending on your creative mindset

[Ballot block]
While I intend to ballot a supportive YES later (as the work is important), there is a lack of technical clarity on the deliverables as the draft charter does not specify their intended status.

[Ballot comment]
Thank you for preparing this update.

Please find below some comments:

# Clarification questions

## "Limited"

What aspects in the charter ensure that the work will be actually "limited"?

The updates part is crystal clear. I’m less clear about the other work items.

## Consistency & Interop

For an outsider, I see the WG defining a lot of extensions but I don’t know whether all these are actually deployed (per the required guidelines set in the charter itself), but more importantly whether these extensions interact, whether there are dependencies, lead to more interoperability (*), etc.?

BTW, how "known constituency interested in real deployment" is materialized when a work is proposed to the WG?

# Minor comments

## Maybe remove the first paragraph

That was useful when first creating the WG, but now LAMPS is well-established and does not need anymore to justify its existence ;-)

# NIST/vetted by the CFRG

I found that repetitive. May be the mention in the main bullet 2 is sufficient

# nit

OLD: produced by the PKIX and S/MIME WG

NEW: produced by the PKIX and S/MIME WGs

# nit

OLD: for "dual signature" that combine

NEW: for "dual signature" that combines

# Specify operational practices

Should that be operational guidance? (2 occurrences)

# Any reason this distinct expectation on # of NIST algos vs CFRG algo?

CURRENT:
  one or more NIST PQC key-establishment algorithm or a PQC key-establishment algorithm vetted by the CFRG

or

  one of the key derivation functions in NIST SP 800-56C, or a key derivation function vetted by the CFRG

# nit

OLD: One example of this

NEW: One example of such use

# nit: “Certificates” and “certificates”

The text uses both. Please pick one form.

# I don’t parse this part:

CURRENT:
  Currently, Trust Anchors use self-signed certificates for this purpose, using bandwidth that could prohibit constrained devices from being able to utilize the larger signature sized quantum resistant algorithms.

Cheers,
Med

(*) When checking recently an implem as part of my review of a LAMPS document, I noticed a discussion on the various formats out there and was puzzled by statements such as “with interoperability being more important than strict IETF specification compliance”: https://github.com/openssl/openssl/issues/26652

[Ballot comment]
PQC is of course a must but I wonder why in 5.a only the US NIST algorithms will be used ? Can we use a wording as in 5.b (i.e., not limiting ourself to US NIST) ?

Regards

-éric

[Ballot comment]
To the non-expert, these seems like "certificate stuff" and "email stuff" married together out of convenience. If this is two distinct sets of expertise, IMO it would waste fewer peoples' time to have two separate working groups.

[Ballot comment]
Do we need to expand or qualify (US) NIST?

If I read this properly, for 5.a we have to wait for NIST (since we will
use their OIDs), but for 5.b we could in theory go faster, if CFRG
produces something sooner.  But for 5.b we still have to wait for at
least one of NIST and CFRG, right?

The proposed milestones put a lot of work in September; is that
achievable?

[Ballot block]
Regarding:

The LAMPS WG may produce
clarifications where needed, but the LAMPS WG shall not adopt
anything beyond clarifications without rechartering.


... may produce clarifications ...

I would argue that this allows for updates specifications that doesn't change the scope of the specification. Some clarifications may result in a actual change of a prior WG consensus decision. If that is what is intended, then fine. But I would appreciate some clarification on what type of work is actually expected here.

[Ballot comment]
It's not fully clear to me what is meant with "these environments". I guess something with constraint devices...? Would be nice to be at least slightly more concrete to make the charter less ambiguous/less open-ended.

[Ballot comment]
About the lightweight CMP, I suggest to have a close relationship with LWIG WG (notably sharing the WG last call in both WG).

-éric

[Ballot comment]
Just wondering whether point 4) in the charter should rather be part to an IRTF RG rather than to an IETF WG. But, I am trusting the security AD on this point.

[Ballot comment]
No objection to the list of work items, but maybe it’s time to rename this “AMPS”, as “L” doesn’t seem to apply any more.

[Ballot comment]
It looks like we didn't note last time that:

% 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.

is potentially ambiguous about "that approach" -- it's the RFC 6844
one that we want to fix, not the new one, of course.

[Ballot comment]
I'm a No Objection, but I had comments on this charter when we balloted for External Review, and it looks like this is the same version that I commented on.

Thread started at https://mailarchive.ietf.org/arch/msg/spasm/hvivetNqR4T4xfEtSsOKd4auw18.

Do the right thing, of course.

Spencer

[Ballot comment]
The milestones look aggressive but I'm unfamiliar with how mature the existing drafts are.

s/in some environments, such a the/in some environments, such as the/

s/6. Specifies a certificate extension/6. Specify a certificate extension/

[Ballot comment]
All of the comments I would have had have already been made by others.
It does seem likely that the text for item (3) can be tightened up some.

[Ballot comment]
Thank you for educating me - it sounds like my concerns have been considered, clearing my Block position.

----


Also, "revoking them pointless" does not parse - perhaps "revoking them is pointless"?


Original Block position (for archeology):
"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."

This makes me twitch -- how short is "short"? And how long is the time to "detect, report, and distribute revocation information"?
With e.g: CT, misissued certificates may be visible before they are used in an attack, decreasing the detection time.

Also, I would figure that it is still useful to know that a certificate was revoked and didn't just expire -- if I see a certificate which expired 10 minutes ago I may be willing (after some consideration, checking my clock, etc) to decide to trust it anyway (even if that's a bad idea!), but a revoked certificate is a clear indication that something bad happened, and changes my risk assessment.

It's entirely possible that there is a really good reason why I'm wrong / that this argument doesn't make sense in some use cases (or just that I'm nuts!)

[Ballot comment]
I am, of course, curious about Warren's BLOCKing comment, but assuming that conversation goes well ...

I had some editorial comments, of course.

The last sentence in this list item is borked, as Warren noted ...

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.

Perhaps something like

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 such short-lived certificates is unnecessary and would be pointless.

I'm not sure that "near-term" is necessary in the first sentence of this list item.

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.

I found it confusing because "near-term" isn't "near-term from now", it's "near-term after the invention of quantum computing destroys civilization. If you want an adjective, perhaps something like "proactive" would be closer.

In this text,

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 might 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.

I wasn't sure from this description whether quantum computing resistance was the only "environment" where these are applicable. As a nit, s/such a/such as/.

[Ballot block]
"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."

This makes me twitch -- how short is "short"? And how long is the time to "detect, report, and distribute revocation information"?
With e.g: CT, misissued certificates may be visible before they are used in an attack, decreasing the detection time.

Also, I would figure that it is still useful to know that a certificate was revoked and didn't just expire -- if I see a certificate which expired 10 minutes ago I may be willing (after some consideration, checking my clock, etc) to decide to trust it anyway (even if that's a bad idea!), but a revoked certificate is a clear indication that something bad happened, and changes my risk assessment.

It's entirely possible that there is a really good reason why I'm wrong / that this argument doesn't make sense in some use cases (or just that I'm nuts!)

[Ballot comment]
Nice work on this one.

This is very nit-picky, but perhaps placing the explanation of each topic immediately following the list item naming the topic would be clearer?

Like, so:

Having completed the S/MIME 4.0 specifications and updates to support
i18n email addresses in PKIX certificates, the LAMPS WG is now tackling
these topics:

1. Specify a discovery mechanism for CAA records to replace the one
  described in RFC 6844.

RFC 6844 describes the mechanism by which CAA records relating to a
domain are discovered.  Implementation experience has demonstrated an
ambiguity in the current processing of CNAME and DNAME records during
discovery.  Subsequent discussion has suggested that a different
discovery approach would resolve limitations inherent in the current
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, which gives 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.

Added charter milestone "WGLC for a draft to specify the way to include an i18n email address as a subject alternative name and an issuer alternative name", due January 2017

Added charter milestone "WG adoption of a draft to specify the way to include an i18n email address as a subject alternative name and an issuer alternative name", due July 2016