Proposal: ACME Profiles

[jvanasco]

@Nummer378

@orangepizza

with profiles will they include must-staple-or not version?

I don't see why they should. ACME has previously handled this via CSR so its easiest to leave it this way.

Yes. @aarongable has mentioned in several places they want to move this - and other attributes - onto profiles and away from CSRs.

In the above notice:

@aarongable

• The CSR contained in the Finalize request message can carry additional information, but copying values directly from CSRs to final certificates has been the root cause of many CA incidents, so great care must be taken. Let’s Encrypt does use the presence of the “ocspMustStaple” extension in the CSR to cause the inclusion of the same extension in the final certificate, but this is the only attribute we extract from the CSR and frankly we’d rather not even do that much.

And in the other thread this example:

@aarongable

       "profiles": {
         "default": "The profile that Let's Encrypt has been using for the last 6+ years.",
         "short": "The same as 'default', but with a validity period of 10 days.",
         "minimal": "A stripped-down profile with a short lifetime, no OCSP, no keyEncipherment KU, no clientAuth EKU, etc."
       }

I am +1 on removing everything from the CSR and shifting to profiles or other. While it had an important role in ACME v1 as the genesis of the ACME Order and could be generated by a Client or Subscriber, in ACME v2 it is expected to be carefully constructed by the Client – and CAs have been handling unsupported situations differently (mostly within RFCs). I don't think we're likely to see RFC updates to address this, as there are too many CAs at this point who are utilizing the "flexibility" of the RFC here - so adopting profiles would address these situations fairly decently by shifting a focus onto the alternate method.