Should I take that to mean that the new entry may be completely rejected by systems that aren't yet ready to handle it?
If so, can we overcome that by simple having two entries:
Or would such "conflicting/overlapping" entries create a problem elsewhere?
In short, what is the best way to handle this (at this time)?
From a CAA standards perspective, CAs have always been allowed to unilaterally make up parameters. That's what they're for.
An issuer MAY choose to specify issuer-parameters that further constrain the issue of certificates by that issuer, for example, specifying that certificates are to be subject to specific validation polices, billed to certain accounts, or issued under specific trust anchors.
The semantics of issuer-parameters are determined by the issuer alone.
DigiCert could create a 'cats' parameter so you could use 'issue "digicert.com; cats=2"' and require that 2 cats sleep on top of your CSR.
If a CA's CAA parser crashes -- or, worse, permits issuance improperly -- in the face of parameters, it's badly broken.
Because Let's Encrypt implements the ACME standard, they're following the ACME standardization process for the ACME CAA extensions. But that's not really relevant to how CAs handle it.
Side note: I'm a bit worried by the hyphens in the parameter names, though. That could potentially cause problems. But parsers ought not to be that brittle.
Edit:
I don't know what that would do. I think it could plausibly be interpreted as allowing Let's Encrypt to use any validation method. I don't know how Let's Encrypt will handle it.
But the crucial question now becomes: "What's the OID for a Cryptokitty in the CSR?"
I would think that the danger, if any, is that another CA altogether may not correctly parse the record in a multi-CA environment. If you literally wanted to restrict to Let’s Encrypt only and via DNS-01 only, I suspect the new form works perfectly for that. If you need to authorize multiple CAs, but only a particular validation method for Let’s Encrypt, I would make those changes and promptly test issuance at the entire set of authorized CAs.
If there’s a danger out there, it would probably be from another CAs’ software analyzing the CAA records, seeing something they didn’t expect (new parameters in the body of a CAA record with the issue tag), and failing secure (decline to issue).
This has been addressed by ACME-CAA draft-05 and the change is live in the staging environment as of today's deploy.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.