@aarongable I was proposing an authoritative challenge responder for (optionally) the whole domain, not one record per domain/subdomain, and the CA assisted DCV method seems(?) to be CA specific, which would defeat CA fallback.
1 Like
Re: "CA Specific" -- yes, you have to CNAME to a specific CA, but the whole point of dns-account-01 is that you could have multiple records pointing to multiple different delegates (i.e. multiple CAs).
Re: "whole domain" -- that's very very tricky. CAA ends up with complex semantics because it wants to let you set policies for the whole domain, but also let subdomains (e.g. if your company has multiple independent business units, or even if your personal website has a third-party hosted blog) set their own policies. But regardless, this is theoretically already solved by the BRs definition of an Authorization Domain Name. If you want a cert for beta.blog.example.com, I as a CA can choose to validate your control over just example.com and that's sufficient to issue. So all you would need is a way to communicate to the CA what ADN you want them to validate.
4 Likes
Reading up on this, my understanding is that CA Assisted DCV is not really a new protocol, is already compliant with the BRs, and is potentially in use by some CAs. The Ballot appears to simply update the BR to give some formal guidance on how CAs implement this.
For those that have a hard time following the discussion on that link - look at slides 11/12/13 on the threat model presentation. The concept is essentially using a CNAME DNS-01 delegation onto an account-specific subdomain controlled by the CA; so the CA follows the DNS-01 delegation from the authoritative nameserver back to itself, and effectively serves as the DNS-01 token for authorization. IMHO, it's a pretty brilliant application of the existing BRs. I hope LetsEncrypt considers implementing this.
3 Likes
Just a quick update. I have found this(Sorry for cutting the conversation):
Section 6.3.2 limits the validity period of Subscriber Certificates. The CA MAY use the documents
and data provided in Section 3.2 to verify certificate information, or may reuse previous
validations themselves, provided that the CA obtained the data or document from a source
specified under Section 3.2 or completed the validation itself no more than 825 days prior to
issuing the Certificate. For validation of Domain Names and IP Addresses according to Section
3.2.2.4 and 3.2.2.5, any data, document, or completed validation used MUST be obtained no more
than 398 days prior to issuing the Certificate.
Obtained from page 46 section 4.2.1 here.
So it is okay with their general policies and rules to reuse old validations, provided they are in the timeframes mentioned above.
Correct, and Let's Encrypt does reuse them, for up to 30 days. And as discussed above, we hope to reduce that period to more like 7 hours, but haven't yet announced concrete plans or timelines to do so.
5 Likes
The Baseline Requirements set the current minimum accepted policies for the industry. The BRs have evolved over time, and allow many behaviors due to the necessity of certain legacy elements – or by accident. Many of the things that are allowed in one section of the BRs somewhat contradict other sections of the BR. Additionally, many CAs are Browser Vendors do not believe these policies are secure enough, so decide to implement higher standards and advocate within the CA/B forum for the industry to adopt their more secure policies as the new standards.
IIRC, and I may be wrong on this one factor when ISRG/LetsEncrypt decided they would only cache authorizations for 30 days is because that number is in-line with the BR's required expiry of an ACME token validity. While the BRs state a valid authorization can be reused for a period longer than 30 days, they also state an unvalidated authorization token can only be used for a period of 30 days. (Stated differently- you only have 30 days to validate the ACME token, but once you do the authorization is now good for a much longer period) The concepts are closely related and slightly contradict one another. Discrepancies like this are common with RFCs and standards, and they become more consistent over time.
So while the CA/B Forum allows for certain behaviors, it does not mean those behaviors are necessarily secure enough. LetsEncrypt - and most other CAs - believe many of these policies to be inadequate and choose to implement stricter requirements.
When it comes to some of the security models, a few thigs:
First, I'll link to my comment a few years ago here in a topic concerning OCSP stapling - What is the relationship between the revoking list and OCSP Stapling? - #36 by jvanasco - however the whole thread is worth reading. This should explain a bit why LetsEncrypt (and the industry) are moving towards shorter certificates and abandoning OCSP stapling. The design of the OCSP ecosystem and BRs create a situation where a certificate can appear to be valid for 10 days after being revoked.
Second, the link that Aaron Gable shared above regarding CA assisted validation contains links to a Doc and Presentation on threat modeling for that design. I'll directly link to them here:
While these don't go into the concepts of time-based reuse, they do detail the concerns and threats to the original authorization - and that should help you understand why the industry is moving towards shorter validities and reuse times.
In a nutshell: the current BRs and ecosystem are somewhat insecure in many ways, but they can't be fixed overnight because too many things would break - so we are slowly moving towards a more secure system.
3 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.