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

[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