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.