Re: AIA CA Issuers field
On Mon, May 11, 2020 at 02:50:19PM +, Corey Bonnell via dev-security-policy wrote: > > * Are there rules that CAs must adhere to in regards to referencing the > > intermediate in the AIA field? Does it need to be available? Does it > > need to be there at all? > > It's optional (SHOULD-level), as Baseline Requirements 7.1.2.3 (c) [1] states: > It (AIA extension) SHOULD also contain the HTTP URL of the Issuing > CA’s certificate (accessMethod = 1.3.6.1.5.5.7.48.2). > > I'd think it's a reasonable expectation/implicit requirement that if the > caIssuers field is present, the issuing CA cert should be generally > available on the global internet at the specified URL. I read RFC5280 4.2.2.1 as *requiring* a URL in caIssuers to return the issuing CA cert. So a cert SHOULD have caIssuers, and if caIssuers is present and contains a HTTP URL that URL MUST return a DER-encoded cert (or "certs-only" CMS). The only corner case I can find is that if the URL returns a DER-encoded cert (etc), I can't see anything that explicitly requires that DER-encoded cert (etc) to be the issuing CA certificate. It's strongly implied by "the additional information lists certificates that were issued to the CA that issued the certificate containing this extension", but it's not as clear and obvious as the rest of the requirements (no "MUST" in there, for instance). I don't encourage anyone to try *making* that argument, though... > > * RfC 5280 says certificates should be served as > > "application/pkix-cert". Is it a violation of any rule if they are > > not? (application/x-x509-ca-cert is common, no content type and > > completely bogus content types linke text/html also happen.) > > Since this a SHOULD-level requirement, it's not prohibited to use other > content-types (although discouraged). I wonder if it's worth starting to require violations of SHOULDs be explained. After all, "SHOULD" indicates that > there may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. (RFC2119, natch) As a result, if someone violates a SHOULD, then it is reaonable to assume that the violator can explain the thought processes that caused them to carefully understand and weigh the implications before rejecting the recommendation. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: AIA CA Issuers field
> * Are there rules that CAs must adhere to in regards to referencing the > intermediate in the AIA field? Does it need to be available? Does it > need to be there at all? It's optional (SHOULD-level), as Baseline Requirements 7.1.2.3 (c) [1] states: It (AIA extension) SHOULD also contain the HTTP URL of the Issuing CA’s certificate (accessMethod = 1.3.6.1.5.5.7.48.2). While nowhere is it explicitly written in the relevant requirements that the resource actually has to be available, I'd think it's a reasonable expectation/implicit requirement that if the caIssuers field is present, the issuing CA cert should be generally available on the global internet at the specified URL. Otherwise, it makes no sense for the pointer to be embedded in the certificate, as it serves no use for Relying Parties on the internet. > * It seems common practice and desired by RFCs to have the intermediate > referenced in binary DER format and not PEM encoded. But some > certificates do reference PEM encoded intermediates. Is this a > violation of any rule and should this be reported as an incident? It MUST be a DER-encoded certificate (PEM isn't allowed) according to RFC 5280 4.2.2.1: Where the information is available via HTTP or FTP, accessLocation MUST be a uniformResourceIdentifier and the URI MUST point to either a single DER encoded certificate as specified in [RFC2585] or a collection of certificates in a BER or DER encoded "certs-only" CMS message as specified in [RFC2797]. Given that, I'd think it would be violation if PEM-encoded certificates were served in the same manner if CAs were serving PEM-encoded CRLs. > * RfC 5280 says certificates should be served as > "application/pkix-cert". Is it a violation of any rule if they are > not? (application/x-x509-ca-cert is common, no content type and > completely bogus content types linke text/html also happen.) Since this a SHOULD-level requirement, it's not prohibited to use other content-types (although discouraged). Thanks, Corey [1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.0.pdf smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
AIA CA Issuers field
Hi, I have been doing some checks on certificates with the AIA Issuers field. I already reported certificates with a 403 error on the HTTP url of the intermediate (see earlier mail). Now there's more stuff to be found and I'm wondering: * Are there rules that CAs must adhere to in regards to referencing the intermediate in the AIA field? Does it need to be available? Does it need to be there at all? * It seems common practice and desired by RFCs to have the intermediate referenced in binary DER format and not PEM encoded. But some certificates do reference PEM encoded intermediates. Is this a violation of any rule and should this be reported as an incident? * RfC 5280 says certificates should be served as "application/pkix-cert". Is it a violation of any rule if they are not? (application/x-x509-ca-cert is common, no content type and completely bogus content types linke text/html also happen.) -- Hanno Böck https://hboeck.de/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
