Minutes IETF101: lamps
minutes-101-lamps-01

LAMPS Session at IETF 101
23 March 2018

Executive Summary

The documents related to internationalized email addresses in
certificates are in the RFC Editor queue.  The S/MIME 4.0 documents with
the IESG, and concerts with them were discussed and resolved.  Work on
rfc6844bis is progressing, and the WG adopted an Internet-Draft.  The
addition of the SHAKE128/256 and SHAKE256/512 algorithms for PKIX and
S/MIME is progressing, but the group recommend a simple approach that
avoid algorithm identifier paramaters.


0)  Minute Taker, Jabber Scribe, Bluesheets

Stefan Santesson is taking notes.
Melinda Shore is Jabber Scribe.


1)  Agenda Bash

No agenda changes.


2)  Documents in the RFC Editor's Queue
    a)  draft-ietf-lamps-rfc5280-i18n-update
    b)  draft-ietf-lamps-eai-addresses

No concerns were raised on these documents.


3)  Documents that have been sent to the IESG
    a)  draft-ietf-lamps-rfc5750-bis
    b)  draft-ietf-lamps-rfc5751-bis

These documents received comments as part of AD evaluation.  Various
issues need to be discussed today.

Simplify requirements language in 5750-bis for SMIMECapabilites
attribute:  The current language is redundant, and no one felt that
simplification would be a problem.  Jim Schaad will propose language in
an updated Internet-Draft.

RFC 2119 language in 5750-bis for SMIMECapabilites attribute:  It is
unclear how the attribute should be processed  by the recipient if the
MUST statements are violated by the sender.  It was noted that the
current text has survived many versions of S/MIME, and it not created
any known interoperability issues.  The group decided that the
SMIMECapabilites attribute SHOULD be ignored if the sender violates
any of the requirements.  Jim Schaad will update the Internet-Draft.

Clarify the meaning of "weak crypto" in 5750-bis.  The current wording
is unclear as to what is actually meant by "weak".  The statement was
originally written about 40-bit encryption, but now that support for
3DES is being removed, the statement seems to be an exaggeration.  Yet,
something need to be said in the security considerations.  Jim Schaad
will propose language in an updated Internet-Draft.

Support for PKCS#6 certificates in 5750-bis:  The group decided that
PKCS#6 certificate MUST NOT be used.  The OPTIONAL field will not be
removed from the ASN.1, but Jim Schaad will update the Internet-Draft
to say that the field MUST NOT be present. 

Time for certificate validity checks:  The SigningTime attribute found
in an S/MIME message MUST NOT be used as use a source of reliable time
for certification path validation.  A countersignature from a timestamp
authority (TSA) could be reliable time source.  Jim Schaad will propose
language in an updated Internet-Draft. 

4)  Active Working Group Documents
    a)  draft-hoffman-andrews-caa-simplification

Comments on the current Internet-Draft lead to discussion on the mail
list and discussions within the CA/Browser Forum, and the document will
include some guidance on things not to do.  The next version of the
Internet-Draft will be posted as draft-ietf-lamps-rfc6844bis-00.


4)  Active Working Group Documents
    b)  draft-ietf-lamps-pkix-shake
    c)  draft-ietf-lamps-cms-shakes

The group discussed the use of the SHAKE128/256 and SHAKE256/512
algorithms with RSASSA-PSS, and suggested that the approach used in
PKCS#1 is too messy.  The use of a single object identifier to name
RSASSA-PSS and all of the parameters was greatly preferred.  This would
lead to the assignment of just two object identifiers, one for RSASSA-PSS
with SHAKE128/256, and another one for RSASSA-PSS with SHAKE256/512.
Quynh Dang will update both Internet-Drafts to take this approach.

One question about requirements for salt generation it was clarified.
No guidance needs to go into the document as the salt has no implication
for security.


5)  Other Business (if time allows)
    a)  Trustico and the need for revocation requests

A number of options and protocol choices exists for revocation requests.
Is harmonization desired?  The revocation request format is diverse and
context specific.  It is generally unclear who can request revocation.
The purpose is also unclear.  No one offered a good solution.  Further
discussion will be taken to the mail list.


5)  Other Business (if time allows)
    b)  draft-truskovsky-lamps-pq-hybrid-x509

A new certificate extension was proposed that holds additional public
key material as well as additional certificate signatures.  This is
meant to provide a way to specify quantum-safe cryptographic keys and
signatures in certificates that still can be processed and handled by
legacy implementation that does not support quantum-safe cryptographic
algorithms.

Several issues and problems was raised and discussed.  First, the size
of the certificate may be a problem, especially in protocols like TLS.
One way to handle this might be the inclusion of a pointer to the data
and a hash to that data (as is done for logotypes).  The pointer and
hash would be much smaller than the quantum-safe cryptographic keys and
signatures.  Second, the semantics of multiple public keys and
signatures is unclear.  Third, even if the semantics is clear for a
particular certificate, it may still be complex how such certificates
should be used in protocols.  Making use of the additional keys and
signatures may require complex logic.


5)  Other Business (if time allows)
    c)  draft-housley-cms-mix-with-psk

The chair made the group aware of draft-housley-cms-mix-with-psk-03.
Review and comment was requested.