[Servercert-wg] [External Sender] Question regarding the id-ad-caIssuers accessMethod URI

[Adriano Santoni]

Hi,

IMO, including an HTTPS URI in the *id-ad-caIssuers* accessMethod is at 
least a bad practice and very unwise (if done on purpose), as it may 
give rise to unbounded loops, as it is clearly explained in RFC5280:

> CAs SHOULD NOT include URIs that specify https, ldaps, or similar
> schemes in extensions.  CAs that include an https URI in one of these
> extensions MUST ensure that the server's certificate can be validated
> without using the information that is pointed to by the URI.  Relying
> parties that choose to validate the server's certificate when
> obtaining information pointed to by an https URI in the
> cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess
> extensions MUST be prepared for the possibility that this will result
> in unbounded recursion.

That said, whether it amounts to a violation of the BRs it's a different 
matter. Generally speaking, since the requirement for the 
*id-ad-caIssuers* accessMethod is expressed in the same way as for the 
*id-ad-ocsp* accessMethod and for *distributionPoint* (see 7.1.2.11.2), 
therefore if using an "https" URI is indeed a violation it should be so 
for all three cases.

It should also be noted that PKILINT contains a validator for checking 
that the URI in the *id-ad-caIssuers* accessMethod starts with "http://".

Adriano


Il 25/04/2024 08:10, Dimitris Zacharopoulos (HARICA) via Servercert-wg 
ha scritto:
> NOTICE: Pay attention - external email - Sender is 
> 0100018f13e0c532-cd7a8efa-701a-498e-9678-2ba113a48abf-000000 at amazonses.com 
>
>
>
>
>
> Dear Members,
>
> I have a quick question regarding the |id-ad-caIssuers| accessMethod URI.
>
> Section 4.2.2.1 of RFC 5280 
> <https://www.rfc-editor.org/rfc/rfc5280.html#section-4.2.2.1> states 
> that:
>
>> When the|id-ad-caIssuers|accessMethod is used, at least one instance 
>> SHOULD specify an accessLocation that is an HTTP [RFC2616] or LDAP 
>> [RFC4516] URI.
>
> RFC 2616 does not support https. That was introduced in a superseded 
> version.
>
> Since RFC 5280 points to RFC 2616, based on past discussions about 
> strictly adhering to RFC 5280 despite the existence of superseded 
> versions, I believe that the proper interpretation of this requirement 
> is that the "http" scheme is allowed and "https" is not.
>
> Do Members agree with that interpretation?
>
> If this is the correct interpretation, would it be considered a 
> violation of the BRs if a CA or end-entity certificate contains 
> https:// URL in the id-ad-caIssuers accessMethod ?
>
> I'm afraid that this might not be as clear in the BRs as it should be, 
> so if people agree with the above, we should probably update section 
> 7.1.2.7.7 
> <https://github.com/cabforum/servercert/blob/main/docs/BR.md#71277-subscriber-certificate-authority-information-access> 
> (and possibly other parts) to explicitly state that the allowed scheme 
> is "http" and not "https", just like we do for the CRLDP in section 
> 7.1.2.11.2 
> <https://github.com/cabforum/servercert/blob/main/docs/BR.md#712112-crl-distribution-points> 
> .
>
>
> Thank you,
> Dimitris.
>
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240425/320b6987/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4620 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240425/320b6987/attachment-0001.p7s>