Forum of Certification Authorities and Browser Developers Approved the Obligation of the DNS CAA
Qualis, a cloud provider that provides a wide range of Internet security services, talks about a topical issue recently approved as mandatory additional tools to enhance the validity of security certificates (SSL / TSL).
CAA (Certification Authority Authorization - Authorization of Certification Authorities), defined in RFC 6844 in 2013, was proposed to strengthen the Public Key Infrastructure (PKI) ecosystem with the help of a new means of controlling which certification authority can issue a certificate for this particular domain. .
Despite the fact that CAA was introduced more than 4 years ago, it is still little known today, and at the moment only 100, or maybe about 200 sites use it. However, significant changes are coming, because the CA certification forum and browser developers (CA / Browser forum) approved the CAA as mandatory - as part of the standard set of basic conditions for issuing a security certificate. The new norm will take effect from September 2017.
The possibility of issuing a security certificate by any certification center (CA) for any domain was repeatedly indicated as the weakest point of the PKI ecosystem. Despite the fact that certification authorities must act without violating certain general rules, there are still no means of technical control over what they are doing. Hence, a certain weak link in the system arises, and in the presence of hundreds of CA, there are hundreds of such links, respectively.
')
CAA creates a mechanism that allows domain owners to create whitelisting centers at the level of DNS records, which they are allowed to issue certificates for their domain. For this purpose, a new resource DNS entry, CAA (type 257) is introduced. The domain owner restricts the issuance of certificates by explicitly specifying the address of the certification authority on this record.
For example, like this:
And it's all. Before issuing a certificate for a domain, the CA checks its DNS resource record for the CAA, and issues the certificate only if it finds its address there. In addition to the “issue” directive from the example above, there is also an “issuewild” directive restricting the issuance of extended wildcard certificates, and an “iodef” directive that contains a URL that a CA can access if something goes wrong - in the sense of certification policies or technical issues. (128 is a control byte with the high bit set, indicating that this directive is critical and must be executed unconditionally).
From a certain point of view, CAA performs almost the same function as HPKP (HTTP Public Key Pinning - attaching public HTTP keys), but in a slightly different way. First, the CAA prevents the issuance of a certificate, while HPKP checks the client side at runtime, identifying certificates that have already been issued as valid or not.
Secondly, HPKP is for browsers, and CAA is for certificate authorities. HPKP, giving the list of keys, a means of technical control, while the CAA carries out, rather, administrative control. Yes, it is expected that if CAA records do not comply, the certification authority stops issuing the certificate, but the certification authority may switch to manual mode and make a decision on release if the request is still recognized as genuine. And yes, this is again a difficulty - there are many certification centers, and the main problem for them is to resist certain “social” pressure factors and still fulfill certain formal rules in case of non-compliance of CAA records.
But to say that CAA is useless or intersects with HPKP is not worth it. There are certain advantages, in particular, in comparison with HPKP, the CAA has fewer opportunities for abuse and violation of property rights in the online space.
HPKP, if not functioning properly, can completely destroy your web business, and the CAA will only be slightly annoying if something goes wrong.
And besides, “attaching public keys to confirm ownership of a web resource” scares potential HPKP users with its complexity and cumbersome compared to the simplicity of the CAA DNS record.
You can check the availability of CAA records using any online service that analyzes the composition of DNS records for public domains.
CAA (Certification Authority Authorization - Authorization of Certification Authorities), defined in RFC 6844 in 2013, was proposed to strengthen the Public Key Infrastructure (PKI) ecosystem with the help of a new means of controlling which certification authority can issue a certificate for this particular domain. .
Despite the fact that CAA was introduced more than 4 years ago, it is still little known today, and at the moment only 100, or maybe about 200 sites use it. However, significant changes are coming, because the CA certification forum and browser developers (CA / Browser forum) approved the CAA as mandatory - as part of the standard set of basic conditions for issuing a security certificate. The new norm will take effect from September 2017.
The possibility of issuing a security certificate by any certification center (CA) for any domain was repeatedly indicated as the weakest point of the PKI ecosystem. Despite the fact that certification authorities must act without violating certain general rules, there are still no means of technical control over what they are doing. Hence, a certain weak link in the system arises, and in the presence of hundreds of CA, there are hundreds of such links, respectively.
')
CAA creates a mechanism that allows domain owners to create whitelisting centers at the level of DNS records, which they are allowed to issue certificates for their domain. For this purpose, a new resource DNS entry, CAA (type 257) is introduced. The domain owner restricts the issuance of certificates by explicitly specifying the address of the certification authority on this record.
For example, like this:
example.org. CAA 128 issue "letsencrypt.org"
And it's all. Before issuing a certificate for a domain, the CA checks its DNS resource record for the CAA, and issues the certificate only if it finds its address there. In addition to the “issue” directive from the example above, there is also an “issuewild” directive restricting the issuance of extended wildcard certificates, and an “iodef” directive that contains a URL that a CA can access if something goes wrong - in the sense of certification policies or technical issues. (128 is a control byte with the high bit set, indicating that this directive is critical and must be executed unconditionally).
From a certain point of view, CAA performs almost the same function as HPKP (HTTP Public Key Pinning - attaching public HTTP keys), but in a slightly different way. First, the CAA prevents the issuance of a certificate, while HPKP checks the client side at runtime, identifying certificates that have already been issued as valid or not.
Secondly, HPKP is for browsers, and CAA is for certificate authorities. HPKP, giving the list of keys, a means of technical control, while the CAA carries out, rather, administrative control. Yes, it is expected that if CAA records do not comply, the certification authority stops issuing the certificate, but the certification authority may switch to manual mode and make a decision on release if the request is still recognized as genuine. And yes, this is again a difficulty - there are many certification centers, and the main problem for them is to resist certain “social” pressure factors and still fulfill certain formal rules in case of non-compliance of CAA records.
But to say that CAA is useless or intersects with HPKP is not worth it. There are certain advantages, in particular, in comparison with HPKP, the CAA has fewer opportunities for abuse and violation of property rights in the online space.
HPKP, if not functioning properly, can completely destroy your web business, and the CAA will only be slightly annoying if something goes wrong.
And besides, “attaching public keys to confirm ownership of a web resource” scares potential HPKP users with its complexity and cumbersome compared to the simplicity of the CAA DNS record.
You can check the availability of CAA records using any online service that analyzes the composition of DNS records for public domains.
Source: https://habr.com/ru/post/329274/
All Articles