Stefan,

It used to be that LDAP was the preferred method for distributing CA certificates, but over time HTTP of a certs-only CMS message seems to have overtaken LDAP in popularity.

The best solution is to use the AIA and SIA extensions to communicate the location of this data.  For SIA, this can begin by including an SIA extension in the self-signed trust anchor certificate.

In the scenario that you describe below, either AIA or SIA should work.  X.509 says that "The issuedToThisCA elements of the crossCertificatePair attribute of a CA's directory entry shall be used to store all, except self-issued certificates issued to this CA." (Self-issued certificates appear in the cACertificate attribute.)  Similarly the certs-only CMS message referred to by an HTTP URI in an AIA extension should include all certificates issued to the issuing CA.  Of course, there is always the possibility that a CA may issue a cross-certificate to another CA without informing the subject CA.

I agree with Santosh about the SIA extension, and I would really like to see support for this extension more widely implemented.  I believe that SIA extensions offer two advantages over AIA extensions.  First, with the SIA extension, I can pre-populate a certificate cache in order to make path validation more efficient.  When I install a trust anchor, I can follow the SIA extension in that certificate to obtain all CA certificates issued by the trust anchor and then follow the SIA extension in those certificates recursively in order to fully pre-populate a certificate cache so when the time comes to validate a certificate I can quickly build the path based on locally cached intermediate certificates.

I also believe that SIA has a security advantage over AIA.  With the AIA extension, I am downloading information using a URL in a certificate that I haven't yet validated.  This certificate may have just been placed in a "signed" email that was sent to me by a spammer (just as spammers use other techniques to obtain evidence of who has opened their emails).  With the SIA extension, I can validate the certificate before using the URL to download more intermediate certificates, and so only make use of URLs that I have already verified as coming from "trusted" sources.

Dave

On 05/05/2011 11:20 AM, Stefan Santesson wrote:

SIA is at most a way to communicate the location of the data.

I'm interested what the best protocol for distributing that data is, in general. We can assume for now that the location of the data is known by local configuration, by SIA or by whatever means.

/Stefan

From: Santosh Chokhani <SChokhani <at> cygnacom.com>
Date: Thu, 5 May 2011 11:12:08 -0400
To: Stefan Santesson <stefan <at> aaa-sec.com>, "pkix <at> ietf.org" <pkix <at> ietf.org>
Subject: RE: Intermediary CA certificate distribution protocols

SIA is a good use for that.

 

From: Stefan Santesson [mailto:stefan <at> aaa-sec.com]
Sent: Thursday, May 05, 2011 10:03 AM
To: Santosh Chokhani; pkix <at> ietf.org
Subject: Re: Intermediary CA certificate distribution protocols

 

For the reasons pointed out by Paul, and because the relying party may use a CA certificate that is not listed in the path assumed by the issuer.

 

The EE certificate issuer may assume the path   TA_A -> intCA_001 -> CA_002 -> EE

 

The certs used in this path are: 

[TA_A -> TA_A]

[TA_A -> intCA_001]

[intCA_001 -> CA_002], and 

[CA_002 -> EE]

 

The AIA in the EE cert will identify the location of the [intCA_001 -> CA_002] cert.

 

The RP may not trust TA_A, but have internally cross certified CA_002 under a trusted TA_X

The certs of this path are:

[TA_X -> TA_X]

[TA_X -> CA_002]

[CA_002 -> EE]

 

The EE cert is the same, thus the EE cert is still pointing to [intCA_001 -> CA_002]. However this cert is not trusted by the RP. Thus AIA is not useful for this case.

 

The question is. If I have a local Trust Anchor  (TA_X) that provides a whole bunch of intermediary certificates as a service to local and/or remote hosts that are configured to trust TA_X but not TA_A, then what is the best protocol to use to make the intermediary certs issued by TA_X available to other hosts in the network?

 

/Stefan

 

 

 

From: Santosh Chokhani <SChokhani <at> cygnacom.com>
Date: Thu, 5 May 2011 09:37:18 -0400
To: Stefan Santesson <stefan <at> aaa-sec.com>, "pkix <at> ietf.org" <pkix <at> ietf.org>
Subject: RE: Intermediary CA certificate distribution protocols

 

Stefan,

 

Why would caIssuers field in AIA not be a preferred approach?

 

From: pkix-bounces <at> ietf.org [mailto:pkix-bounces <at> ietf.org] On Behalf Of Stefan Santesson
Sent: Thursday, May 05, 2011 9:12 AM
To: pkix <at> ietf.org
Subject: [pkix] Intermediary CA certificate distribution protocols

 

I'm curious about implementer opinions on what protocol you use/prefer for certificate distribution of intermediary CA certificates.

 

Certs include the AIA extension to allow a verifier to walk up the path of an EE cert. However, that is not a preferable solution.

In cross certification schemes among other's the intermediary cert that chains to one of the RP trust anchor may be provided from a cross certifying PKI, bridge CA or similar.

 

In such case, what is the most preferred protocol to distribute / make available such intermediary certificates from one or more sources. I can think of a number of possible alternatives like LDAP, XKMS, FTP of a PKCS#7 certs only file, etc.

 

/Stefan

_______________________________________________ pkix mailing list pkix <at> ietf.org https://www.ietf.org/mailman/listinfo/pkix