> * 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
