Subject: [lamps] draft-ietf-lamps-lightweight-cmp-profile-01, section 5.4.3

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 23 Apr 2020 06:51:44 +0000

During the past LAMPS WG online meeting we discussed the root CA certificate update structure. I wanted to explain the reasons behind our suggestion to change the caKeyUpdateInfo structure.

The structure caKeyUpdateInfo contains three certificates (oldWithNew, newWithOld and newWithNew) and all are mandatory. Especially in meshed CA arrangements the oldWithNew and newWithOld certificates are needed. As the number of certificates transferred and stored is crucial in many environments and hierarchical CA arrangements are more common in industrial or IoT environments, we thought about the need for all three certificates.
1. As long as the message is properly authenticated by an authorized entity (e.g., the existing CA), only newWithNew is really necessary as this is the new Root CA certificate. The two other may be helpful for chain building in a mixed environment where one device needs to authenticate another device using the other root.
2. The newWithOld certificate could be necessary when a Device A needs to authenticate to Device B and Device A uses a certificate under the new root and Device B only knows the old root. Then Device A should also deliver the newWithNew and newWithOld certificates to give Device B the chance to build a proper chain. 
3. The oldWithNew certificate is only necessary if two devices need to authenticate each other and one of the devices does not know the old root CA certificate. I regard the case a quite uncommon as in many environments all devices already have a common oldWithOld root certificate when the newWithNew root certificate is being rolled out.

Having these three points in mind, we think a structure like this would be good.
     RootCaKeyUpdContent ::= SEQUENCE {
          newWithNew   CMPCertificate,  -- new pub signed with new priv
          newWithOld   [0] CMPCertificate OPTIONAL, -- new pub signed with old priv
          oldWithNew   [1] CMPCertificate OPTIONAL -- old pub signed with new priv
      }

The Structure should be used in Lightweight CMP Profile section 5.4.3 like this:
           rootCaKeyUpdate       REQUIRED
       -- MUST be present and be of type RootCaKeyUpdContent
             newWithNew          REQUIRED
       -- MUST be present if infoValue is present
       -- MUST contain the new root CA certificate
             newWithOld          RECOMMENDED
       -- SHOULD be present if infoValue is present
       -- MUST contain an X.509 certificate containing the new public
       -- root CA key signed with the old private root CA key
             oldWithNew          OPTIONAL
       -- MAY be present if infoValue is present
       -- MUST contain an X.509 certificate containing the old public
       -- root CA key signed with the new private root CA key

And the uses shall have the flexibility to either fill either
- newWithNew, 
- newWithNew + newWithOld, 
- newWithNew + oldWithNew, or 
- newWithNew + newWithOld + oldWithNew.
Therefore we changed the order of the certs and added tagging in RootCaKeyUpdContent for newWithOld and oldWithNew. Is this correct?

This structure services the uses cases in scope of the Lightweight CMP Profile best and offers the needed flexibility for reducing the overhead of delivering certificates that are not needed. But finally it is also open to cover all other use cases.

As discussed during the LAMPS WG session, I will suggest a new structure and OID in the Lightweight CMP Profile for this structure.
Any feedback is welcome.

-- Hendrik