Minutes interim-2020-lamps-01: Mon 10:30
minutes-interim-2020-lamps-01-202003301030-00

LAMPS WG Agenda at Virtual IETF 107 on 30 March 2020

0)  Minute Taker, Jabber Scribe, Bluesheets

Peter Yee agreed to take notes.

The bluesheet is in the Etherpad:
https://etherpad.ietf.org:9009/p/notes-ietf-107-lamps

The jabber log is here:
https://www.ietf.org/jabber/logs/lamps/2020-03-30.html

1)  Agenda Bash

2)  Documents with the RFC Editor and IESG
    a)  draft-ietf-lamps-5480-ku-clarifications (Sean)

Sean Turner said the document is ready for publication after one minor
change.  Roman Danyliw will hit the button to put it in the RFC Editor
queue once Sean posts an update.

3)  Active Working Group Documents
    a)  draft-ietf-lamps-header-protection-requirements (Alexey, Bernie)

The document has not been updated since IETF 106.

Alexey Melnikov said that he has received no information from DKG on the
user interface experiment.  Alexey tried to import DKG’s certificate, but
his system was unhappy about the lack of CRL information.  Russ tried as
well with two mail clients; the signature part worked (and he sent
screen shots), but encryption did not work, even with DKG’s assistance.
Alexey said that decryption and signature verification worked in his
system as long as CRL checks were ignored.  Alexey also attempted with
Thunderbird, and it seemed to work all right, but he didn’t send screen
shots on the mistaken assumption that someone else would do so.  Russ
noted that no one tried it on Outlook; he tested on Apple Mail and
MailMate.  Alexey said that they should examine which other major mail
clients are missing.  Russ encourages anyone people to participate in
the experiment described in draft-dkg-lamps-samples.  Russ asked Bernie
to revitalize the mail thread.  The keys, certificates, and sample
messages are also available from https://gitlab.com/dkg/lamps-samples.

    b)  draft-ietf-lamps-cms-update-alg-id-protect (Russ)

This document was adopted by the WG since the last IETF meeting.  The
draft specifies what is done in the CMS Signed-data Content Type to
prevent substitution attacks.  The hash algorithm protecting content
and the hash algorithm protecting the signed attributes MUST be the
same one.  Query: are there any implementations that actually allow for
different hash algorithms to be used?  This also has implications for
timestamping.  Russ believes the document is ready for WG Last Call.
Tim Hollebeek will start the WG Last Call shortly. 

 	c)  draft-ietf-lamps-rfc7030est-clarify (Michael, Thomas, Wei)
 
Michael Richardson said there have been a couple of minor errata that
were submitted.  Michael is working through those errata with the
submitters off of the mail list.  He will post the outcome to the mail
list after a way forward is agreed with the errata submitters.  Russ
will start the WG Last Call on the document.  If not satisfied by the
existing document, any concerns raise by the errata submitters can be
treated as WG Last Call comments.
 
    d)  draft-ietf-lamps-cmp-updates (Henk)

The document was adopted by the WG.  Hendrik (Henk) Brockhaus suggests
that the EKU names for id-kp-cmcRA and id-kp-cmcCA be changed to
id-kp-cmRA and id-kp-cmcCA, respectively.  The goal is to make them
enrollment protocol agnostic.  Similarly, id-kp-cmcArchive would be
changed to id-kp-cmArchive.  The IANA registry would be annotated to
indicate the reuse of the OIDs.  In addition, a new object identifier
(OID) is needed: id-kp-cmKGA.  Russ asked if there were any
implementations waiting for the OID assignment of id-kp-cmKGA.  Henk
says not yet, but he will ask for early assignment if the need arises.
Russ and Jim Schaad spoke against renaming the existing OIDs; they are
referenced in RFC 6402, RFC 6403, RFC 7030, and RFC 8756.

The CMP valueHint field contains a key identifier to assist in
passphrase retrieval.  A question: should that identifier be stored
in pkcs-9-at-friendlyName or pkcs-9-at-localKeyId?  The CMP valueHint
is used for distributing a revocation key.  Henk prefers
pkcs-9-at-localKeyId.  Jim Schaad will take a look at the question
and come back to Henk if he has a different opinion.

 	e)  draft-ietf-lamps-lightweight-cmp-profile (Henk, Steffen, David)

The lightweight CMP profile document was adopted by the WG.  Several
outstanding issues and to-dos were addressed in January, but some still
remain:

  *  Delayed enrollment could be optional or recommended.  Opinions
     seem to be in favor of optional.
  *  An example of a prefilled certTemplate in the
     get-cert-parameters-request message has been requested.
  *  Is there a better way to handle using different symmetric keys for
     encrypting the private key and MAC protection of the CMP messages?
     The use of PBMParameter (password-based MAC parameters) for
     deriving encryption works for this purpose, but it is not really
     the right name for this purpose, since it has to do with MACing,
     not encryption.  Russ will look at the text to see if the OID and
     structure lead to confusion for implementers.  If there is
     confusion, than another OID and name would need to be created.
  *  For the root CA key update message, the caKeyUpdateInfo structure
     already exists in RFC 4210 and requires all three of oldWithNew,
     newWithOld, and newWithNew values be present.  Discussions on the
     mail list suggest that oldWithNew should be OPTIONAL, newWithOld
     should be RECOMMENDED, and newWithNew REQUIRED.  That saves on the
     overhead of transmitting excess certificates.  Russ and Jim suggest
     generating a new OID rather than re-using the existing OID to
     prevent a backward compatibility issue.  For documentation
     purposes, Russ asked that Henk post the rationale for not including
     all three certificates to the mail list.  The argument should cover
     both hierarchical and mesh CA arrangements.  In any case, a new OID
     would probably be most sensible.
  *  Do we really need both get-certificate-parameters and
     get-certificate-management-configuration messages?  In many ways,
     they can convey the same information.
  *  Henk has added rsaKeyLen to get-certificate-parameters, but he
     wants to know if multiple RSA key lengths should be specifiable.
     One RSA key length could be treated as a minimum length and the key
     generator could create longer keys, whereas multiple RSA key
     lengths would allow for more specificity in the request.  Henk
     prefers a single key length and if the key generator can't support
     that length, it responds with an error indication.  No one appears
     to be in favor of multiple lengths.  Going back to the original
     question about the need for both messages, a question will be
     posted to the list to see if anyone cares.  If no one cares, Henk
     will delete get-certificate-management-configuration.  The query
     will be cross-posted to the PKIX list as well.
  *  The get-enrollment-voucher message has been added to support BRSKI,
     but it probably ought to be clarified that it is limited to
     RFC 8366 uses only.  Otherwise, it might be used for other purposes
     that aren't as well defined.  Perhaps clarification should be added
     that it is BRSKI-only.  Michael Richardson thinks a different
     document that specifies how BRSKI is used with CMP might be
     merited.
  *  File-based transport of CMP needs to be specified, but it will
     probably not require much text since it involves manual processes,
     not bits-on-the-wire.
  *  There has been desire for a CoAP-based transport profile to be
     added.  Jim Schaad suggests that a separate document out of the
     ACE WG would be more appropriate for specifying such a transport.
     CMP is transport agnostic.  Michael Richardson doesn't have the
     bandwidth to supply text for the transport is any case.  Jim is
     willing to supply the basic structure for a separate document.  He
     feels that a short, separate document is better than sending the
     whole document for CoAP experts to review.
  *  Security considerations are needed.
  *  There are times when an additional RA signature over certificate
     request(s) is needed: when the RA collects several messages and
     forwards them as a batch, or when an RA modifies a request(s).
     Jim will take a look at this point.  Henk will also work on
     clarifying the concept.
  *  For RA-to-RA communication, Henk suggests specifying some HTTP
     endpoints that are separate from the client-to-RA HTTP endpoints.
     When an RA is forwarding messages, it should not use the
     client-to-RA endpoints.  There are not many uses for RA-to-RA
     communication, but they could be used for firewalling of CAs via
     an extra RA, for example.  Jim does not think the cases are
     different for the most part, so he does not see much need for
     different HTTP endpoints.  Other reasons for using RA-to-RA
     communications might be for connectivity reasons, or for allowing
     local policy enforcement before submitting to a central CA.
     Michael Richardson believes this adds too much complexity, but if
     Henk feels that it is a really compelling use case, he would like
     to see a write-up.  Henk says that some of this can be found in
     Section 6 of the document; and he asks that everyone review it.
  *  Henk could use some help in completing the ASN.1 modules in the
     appendices and dealing with IANA considerations..   

4)  Wrap Up

Expect two WG Last Calls to begin in the next few days.