Subject: [pkix] Intermediary CA certificate distribution protocols

From: Stefan Santesson <[email-masked]>
Date: Thu, 05 May 2011 15:11:47 +0200

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

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 5 May 2011 09:37:18 -0400

Stefan,

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Thursday, May 05, 2011 9:12 AM
To: [email-masked]
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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 May 2011 06:56:59 -0700

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

Because you might not have network connectivity to all the locations listed in the AIA. For example, in IPsec, you might have only IP connectivity by IP address and not even have a DNS resolver until after the IPsec tunnel is set up.

You might also not want to announce to the world which CA certificates you want, in order to reduce tracking.

--Paul Hoffman

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 05 May 2011 16:02:41 +0200

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 <[email-masked]>
Date:  Thu, 5 May 2011 09:37:18 -0400
To:  Stefan Santesson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  RE: Intermediary CA certificate distribution protocols

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

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 5 May 2011 10:42:16 -0400

How would a CA help you with that?

Why do you need access to all locations in the AIA?  You need access to one only.

What would you do about CRL DP and OCSP?

Are you recommending IP address pointer.

If you want to reduce tracking, is this not an RP issue?

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Thursday, May 05, 2011 9:57 AM
To: Santosh Chokhani
Cc: Stefan Santesson; [email-masked]
Subject: Re: [pkix] Intermediary CA certificate distribution protocols

--Paul Hoffman

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 5 May 2011 16:52:24 +0200

This is maybe slightly off-topic for this list, but I imagine that in practice that the more widely-used ways of distributing intermediate CA information are in applications: In TLS, you can put the whole chain in the Certificate payload.  I think there's a similar slot in IPsec, and of course in S/MIME, you can just append more certificates to the message.  

--Richard

On May 5, 2011, at 3:11 PM, Stefan Santesson wrote:

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 05 May 2011 16:59:23 +0200

Santosh,

I respect the many interesting questions about the use of AIA, however
that is not the subject of my thread.
For my use-case AIA is not applicable.

I would suggest that any further discussion about AIA is done in this
separate thread. I hope that is OK.

/Stefan

On 11-05-05 4:42 PM, "Santosh Chokhani" <[email-masked]> wrote:

>Because you might not have network connectivity to all the locations
>listed in the AIA. For example, in IPsec, you might have only IP
>connectivity by IP address and not even have a DNS resolver until after
>the IPsec tunnel is set up.
>

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 5 May 2011 11:12:08 -0400

SIA is a good use for that.

From: Stefan Santesson [mailto:[email-masked]]
Sent: Thursday, May 05, 2011 10:03 AM
To: Santosh Chokhani; [email-masked]
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 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 <[email-masked]<mailto:[email-masked]>>
Date: Thu, 5 May 2011 09:37:18 -0400
To: Stefan Santesson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Intermediary CA certificate distribution protocols

Stefan,

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

/Stefan

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 May 2011 17:19:52 +0200 (MEST)

Richard L. Barnes wrote:
> 
> This is maybe slightly off-topic for this list, but I imagine that in
> practice that the more widely-used ways of distributing intermediate
> CA information are in applications: In TLS, you can put the whole chain
> in the Certificate payload.

That is not an accurate characterization.  In TLS, you MUST put the whole
chain into the Certificate payload, any you may only omit the self-signed
certificate at the end of the chain.

>                               I think there's a similar slot in IPsec,
> and of course in S/MIME, you can just append more certificates
> to the message.  

PKCS#7 and its successor CMS provides room for an unsorted
certificate junkyard  http://tools.ietf.org/html/rfc2315#section-6.6
whose content may or may not be helpful in building certificate chains.

XMLSecurity might allow multiple occurrances of the X509Certificate
container, but using more than one seems to be unusual.

WS-Security tried to improve that by allowing certificate chains in
one of two Chain formats, PKCS#7 (the junkyard) and a well-formed chain
similar to what TLS does (X509PKIPathv1).

I can not comment on IPsec.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 05 May 2011 17:20:44 +0200

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 <[email-masked]>
Date:  Thu, 5 May 2011 11:12:08 -0400
To:  Stefan Santesson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  RE: Intermediary CA certificate distribution protocols

> 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: Stefan Santesson <[email-masked]>
Date: Thu, 05 May 2011 17:25:58 +0200

Absolutely right Richard, but in some cases the sender does not know what
Roots/Trust Anchors the receiver will use and can not provide all
necessary certificates for any theoretically possible path.

The RP decision to rely on another Trust Anchor may require the RP to also
download CA certificates provided by that TA. It is the protocol for that
exchange I'm interested in.

/Stefan

On 11-05-05 4:52 PM, "Richard L. Barnes" <[email-masked]> wrote:

>practice that the more widely-used ways of distributing intermediate CA
>information are in applications: In TLS, you can put the whole chain in
>the Certificate payload.  I think there's a similar slot in IPsec, and of
>course in S/MIME, you can just append more certificates to the message.
>
>--Richard
>
>
>> 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.
>>chains to one of the RP trust anchor may be provided from a cross
>>certifying PKI, bridge CA or similar.
>> 
>>think of a number of possible alternatives like LDAP, XKMS, FTP of a
>>PKCS#7 certs only file, etc.
>> 
>> /Stefan

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 May 2011 08:29:29 -0700

The answers I gave might not meet your personal usage scenarios, but they do apply to many people.

--Paul Hoffman

---

From: Eric Norman <[email-masked]>
Date: Thu, 05 May 2011 10:39:24 -0500

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

SSL or S/MIME?

I've always interpreted the "other certificate" capabilities in either as meaning:

There is a possibility the you (RP) might need these certificate for validation
to succeed, so I'll send them to you just in case.

Note that this may still require installation of a trust anchor by the RP.

EJN

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 05 May 2011 11:50:47 -0400

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:

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 <[email-masked]>

Date: Thu, 5 May
2011 11:12:08 -0400

To: Stefan Santesson
<[email-masked]>,
"[email-masked]"
<[email-masked]>

Subject: RE:
Intermediary CA certificate distribution protocols

SIA
is a good use for that.

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 <[email-masked]>

To: Stefan Santesson <[email-masked]>,
"[email-masked]"
<[email-masked]>

Subject: RE: Intermediary CA certificate
distribution protocols

Stefan,

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

From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Stefan Santesson

Sent: Thursday, May 05, 2011 9:12
AM

To: [email-masked]

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

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 May 2011 18:36:35 +0200 (MEST)

> an EE cert. However, that is not a preferable solution.

"not a preferable solution"?  It appears that some serious security
vulnerabilities have found their way into at least parts of the installed
base based on negligent chasing of AIA caIssuers from untrusted certs.

It is a serious security problem and would be completely irresponsible
to have software perform AIA caIssuers downloads for (still unverified
and therefore) untrusted certs without a sufficiently adept/clueful
human end user authorizing each download URL _before_ the download
is being attempted.

We had a discussion on this on the TLS WG mailing list in Aug 2010.

  http://www.ietf.org/mail-archive/web/tls/current/msg06813.html
  http://www.ietf.org/mail-archive/web/tls/current/msg06824.html
  http://www.ietf.org/mail-archive/web/tls/current/msg06830.html

> PKI, bridge CA or similar.

I agree.  Those who engage in cross-certifying/bridging ought to bear
the burden on providing and missing cross-certs to all entities
within that PKI.

> think of a number of possible alternatives like LDAP, XKMS, FTP of a PKCS#7

There should be a protocol and an architecture that allows entities
to build certificate chains for communication peers in a trustworthy
and protected fashion, i.e. reliably precluding access to untrusted/
unverified resources.  If it doesn't exist yet, then it is about
time for it to be created in case that cross-certifying / bridging
of PKIs (rather than the ~100 independent roots of the TLS X.509 PKI)
is considered a use case for the real world that needs to be supported.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 5 May 2011 12:40:43 -0400

SIA had URI and that could be HTTP or LDAP.

Or, are you asking how to populate each RP store in case it is network disconnected.

BTW, you can also resolve via DNS the URI in SIA to location of your choice on your network.

From: Stefan Santesson [mailto:[email-masked]]
Sent: Thursday, May 05, 2011 11:21 AM
To: Santosh Chokhani; [email-masked]
Subject: Re: Intermediary CA certificate distribution protocols

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: Stefan Santesson [mailto:[email-masked]]
Sent: Thursday, May 05, 2011 10:03 AM
To: Santosh Chokhani; [email-masked]<mailto:[email-masked]>
Subject: Re: Intermediary CA certificate distribution protocols

/Stefan

Stefan,

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 05 May 2011 18:42:00 +0200

Thanks David,

You are spot on the issue I wanted to address. I'm also assuming that http
access to a PKCS#7 is more popular than LDAP.
The thing is that the number of available certs will expand over time, so
the RP host getting these certs will need to poll for new data frequently
(or every time a certificate is validated) in order to update the cache.
I'm not sure a PKCS#7 certs only file is the most efficient solution for a
continuous update scenario, but it might very well be.

/Stefan

From:  "David A. Cooper" <[email-masked]>
Date:  Thu, 05 May 2011 11:50:47 -0400
To:  Stefan Santesson <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [pkix] Intermediary CA certificate distribution protocols

> 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
> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: Eric Norman <[email-masked]>
Date: Thu, 05 May 2011 12:00:33 -0500

> exchange I'm interested in.

Is there an implicit assumption about "when" here?

If you're asking an RP to make such a decision as soon as they encounter an EE
certificate that they can't connect to one of their trust anchors, then I think you're
asking for a system that would gloriously fail usability concerns.

EJN

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 5 May 2011 13:21:08 -0400

In addition to what Stefan says, for client authenticated TLS, there is a problem in the client certificate side.  While TLS spec may say that the trust anchors sent by the Server are advisory, browsers such as IE, use them and when the path terminates prior to that TA, the browser does not use the client certificate inhibiting client authenticated TLS.

The only fix I have seen to that is for the server to send a broad set of TAs to the client.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Thursday, May 05, 2011 11:26 AM
To: Richard L. Barnes
Cc: [email-masked]
Subject: Re: [pkix] Intermediary CA certificate distribution protocols

/Stefan

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 5 May 2011 13:21:49 -0400

Paul,

Your response in not helpful to me in terms of either learning on this forum or contributing to this forum.

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Thursday, May 05, 2011 11:29 AM
To: Santosh Chokhani
Cc: Stefan Santesson; [email-masked]
Subject: Re: [pkix] Intermediary CA certificate distribution protocols

--Paul Hoffman

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 5 May 2011 13:30:13 -0400

Aren't the certificate chains also passed in the clear before the session is secured?

Would that not offer an attack vector as well, albeit a bit harder.

Also, for cross-certified environments when the Server and Client TA set are different, you need to use AIA or SIA to complete the path.

BTW, if TLS folks are concerned with AIA, they can use SIA starting with the value in the RP TA obviating your concern.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Thursday, May 05, 2011 12:37 PM
To: Stefan Santesson
Cc: [email-masked]
Subject: Re: [pkix] Intermediary CA certificate distribution protocols

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 May 2011 21:22:19 +0200 (MEST)

> Aren't the certificate chains also passed in the clear before

Yes, they are.

> Would that not offer an attack vector as well, albeit a bit harder.

Unless you want to stop communicating entirely, the attack vector
that you parse protocol PDUs (explicit PDUs, ASN.1, XML, etc.)
in not avoidable.

Searching locally preconfigured places for certificates to complete
a certification path should not be a problem; considering
additional certs supplied by the peer in-band with the communication
protocol also does not create an additional attack vector.

But being able to entice a communication peer to automatically access
arbitrary resources described by an attacker-supplied, unverified URI,
is a whole different category.

The most important part of rfc-5280 is 6.1.3 (a)
  http://tools.ietf.org/html/rfc5280#section-6.1.3

The security-relevant issue is to perform (a1) and (a2) _before_ (a3),
(but somehow rfc5280 goofed (a4), because (a4) ought to be the
 first check in the list under 6.1.3 (a)).

AIA OCSP URIs and CRL-DP URIs should only be accessed after the
signature on the certificate has been successfully validated with
a trusted key (a public key that has been verified to be trustworthy
under your set of trust anchors).

You still can be screwed by any single one of the CAs issued under any of
your trust anchors with crafted AIA OCSP URIs and CRL-DP URIs,
but that is a risk that you subscribe to when you
"open the shrink wrap around the trust anchor cert" (or its software
 container, e.g. preloaded in a browser) and decide to use it...

> 
> Also, for cross-certified environments when the Server and Client TA
> set are different, you need to use AIA or SIA to complete the path.
> 
> BTW, if TLS folks are concerned with AIA, they can use SIA starting with
> the value in the RP TA obviating your concern.

I'm fine with what the TLS spec says (MUST send the entire chain),

But I'm irritated about very dangerous automatic AIA caIssuer chasing
that I've seen in a pretty common PKI Software when visualizing
Certificate contents, and I read a description of some browser
behaviour that also sounded like automatic AIA caIssuer chasing.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 06 May 2011 00:24:26 +0200

I totally agree that path discovery through AIA is a bad solution
providing many attack vectors to defeat a bad PKI implementation. And it
is messy to use on the fly letting users wait for network time-outs etc
when processing options.

It's way better to solve bottom up discovery by simply providing the path
(as TLS requires).

However. As stated before, I would like to focus this discussion on
top-down path discovery when the RP use a TA different from the one
assumed by the sender. The use case I have in mind is when the RP relies
on one or a few TAs to provide trust in only those CAs that are approved
for a given context. The RP just installs the few TA root certificates and
trows all other roots in the bin. It then downloads and caches all
intermediary certs provided by the locally accepted TAs.

This guarantees that only those chains that chains to one of the cached
intermediary certs will be accepted.

The question at hand is what's the best suited protocol for such
continuous caching of intermediary certs from the few trusted TAs?

My current main choices are:
-Http access to PKCS#7 certs only file
-LDAP
-XKMS

Who has experience of pros and cons of theses solutions?
What is lacking?
Is there more to be done in this area?

/Stefan

On 11-05-05 6:36 PM, "Martin Rex" <[email-masked]> wrote:

>>for
>>of

---

From: Stephen Wilson <[email-masked]>
Date: Fri, 06 May 2011 08:43:57 +1000

> It's way better to solve bottom up discovery by simply providing the path
Yeah, I've always thought that the path discovery problem is trivial. 
Why wouldn't someone digitally signing a transaction always send the 
through the entire certificate chain?  Or more precisely, why wouldn't 
their software send through the entire chain as applicable in the 
context it's operating in?

Stephen Wilson
Lockstep

http://lockstep.com.au <http://www.lockstep.com.au>
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy.Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 5 May 2011 16:59:00 -0700

> It's way better to solve bottom up discovery by simply providing the path

Agree as first choice, though you provided a kind of counter-example earlier in this thread.  ;-)

> intermediary certs provided by the locally accepted TAs.

This sounds like an exponential-growth problem.  Turning your description around, I think you are creating requirements:

1) the number of TAs is small.
2) the number of intermediate CAs under each TAs is small.
3) the RP knows when any of the above change, and how to get the updates.

> intermediary certs will be accepted.

Sounds reasonable to me.

> Is there more to be done in this area?

I've no experience with XKMS.  The other two seem to work.

I'm kind of stuck on the above requirements though.  Can you explain why I shouldn't focus on them first?  Your application already solves those parts of the problem?

>> is considered a use case for the real world that needs to be supported.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Martin Rex <[email-masked]>
Date: Fri, 6 May 2011 03:44:57 +0200 (MEST)

> -Http access to PKCS#7 certs only file

AIA caIssuers allows both, ASN.1 DER single cert or PKCS7/CMS certs only bag

rfc 5280, section 4221 Authority Information Access, last para on page 50:
   http://tools.ietf.org/html/rfc5280#page-50

   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].

And I only found ASN.1 DER single cert in the statistically INsignificant
number of server certs I that I looked at.
 
There are these two other cert distribution methods shipping as
part of Microsoft Operating systems.

The approach up to W2K3 to regularly poll a TrustAnchor update
from the vendors server (but I've never seen any of these Windows
machines asking the user for consent to update the trust anchors,
or telling the user what exactly was changed during the update).
But you can still look in the certificate store to find out which
trust anchors you happen to trust.

And then there is the approach in Win7 (probably started in Vista)
where you have no clue whatsoever which trust anchors your browser
will trust, because missing certificates and missing trustanchors
will be automatically downloaded and added (no asking, no telling),
and even if you look at the cert store, decide you don't like some
cert and delete it -- it will automatically reappear on the next
certificate path validation.   So if you want to discontinue trusting
a cert, you must move it manually into the untrusted issuers container.
Which is a tad difficult to do if you don't have the slighest clue
which certs your machine will automatically trust...

What might help, if there was a protocol (and service based on it)
offered by every of your trust anchors that engages in cross-certing,
where you could send in a list of Issuer DNames asking them to return
all valid path certs to (cross-)CA-certs that were created with this
issuer name in them.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 06 May 2011 11:05:22 +0200

Hi Henry,

On 11-05-06 1:59 AM, "Henry B. Hotz" <[email-masked]> wrote:

>This sounds like an exponential-growth problem.  Turning your description
>around, I think you are creating requirements:
>

I understand your concern, but this is not an exponential growth problem.

It would be if you would attempt to collect all issued cert from all
trusted CA's, starting from 100+ TAs.

However, the top down model in my use-case is an act of selecting a vey
limited number of TA's that you specifically select as your trust
provider. So condition 1) is absolutely met. The number of intermediary
CAs under each CA does not have to be small, but manageable. In my
particular case it is in the range of about 100-200 CAs.

The RP does not know then a new intermediary CA is added and here is the
root of my wandering what the best protocol for this is.
The RP needs to frequently update it's cache. Avoiding unnecessary
transfer of data can be achieved in the case of a PKCS#7 file by using
HTTP caching and HTTP headers to only download an updated cert file if it
has been changed. This allows frequent caching without excessive bandwidth
waste.

I assume LDAP and XKMS has other in-protocol functions for determining if
anything has changed, but I'm not sure that would be easier.

A specific use case is the somewhat 500 trust services in EU listed a
complex structure of signed XML files, called Trust-service Status Lists
(TSL). It is currently very hard for an RP application to extract relevant
CA keys and TA's from those XML files. To solve this you can create a
locally trusted TA who digs into those TSLs and cross certifies any
relevant CA out of those listed in the available TSLs. The only thing you
give to the RP is the locally trusted TA cert and a way to obtain the
cross certificates from that TA.

You may create several (but few) TA's representing different trust
policies. The RP installs the TA's representing the trust policies it
accepts, download related intermediary certificates and suddenly is able
to correctly trust all EU CA's that are compatible with the selected
policies. 

This solution is simple, straight forward, compatible with current PKI
implementations and so much easier than letting each RP dig into all
national TSL files to figure out what to trust.

/Stefan

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 6 May 2011 08:40:36 -0400

-----Original Message-----
From: Stefan Santesson
>> This sounds like an exponential-growth problem.  Turning
>> your description around, I think you are creating requirements:
>>

I suppose Henry was using a bit of hyperbole - it is an O(N*M) problem
which, unlike exponential, is tractable even as the number of TAs (N)
and Intermediate CAs per TA (M) increase.  If it were not, then web
browser caches would grind to a halt as the number of web pages visited
(N) and images per page (M) increased.  But web caches work fine at
scale, and so should certificate caches.  By analogy with the browser,
the user/administrator of the RP system should be able to tune the
certificate cache size as appropriate.

> Avoiding unnecessary transfer of data can be achieved in
> the case of a PKCS#7 file by using HTTP caching and HTTP headers
> to only download an updated cert file if it has been changed.
> This allows frequent caching without excessive bandwidth waste.

Did we put you up to this? :-)  I couldn't have said it better myself.

> The only thing you give to the RP is the locally trusted TA cert
> and a way to obtain the cross certificates from that TA.
>
> This solution is simple, straight forward, compatible with
> current PKI implementations and so much easier than letting
> each RP dig into all national TSL files to figure out what
> to trust.
>
> /Stefan

I vote for using PKCS#7 over HTTP for cert transfers.  (We've been using
HTTP for CRLs rather than LDAP for years.)  And the obvious way for the
TA to publish its current list of Intermediate CAs is a SIA URL in the
TA cert pointing to an HTML file containing links to each Intermediate
CA cert.  The RP fetches the HTML list if it has changed, and fetches
each cert anchor (<a href=...>) in the list if that cert is not already
cached.

What could be simpler or more standard or more bandwidth efficient?

If the TA has privacy concerns, it can authenticate the RP using https,
generate the list on the fly based on the RP's privileges, and use
dynamic IntCA cert links (random and valid only for N seconds).  All
standard web stuff.

Dave

---

From: Santosh Chokhani <[email-masked]>
Date: Sat, 7 May 2011 07:07:57 -0400

In the end the AIA chasing is done using a certificate provided by the server.  So, either the server gave you a bad certificate or an attacker substituted it in which case he can substitute the whole chain.

Basically, AIA and SIA is a trade off of performance.  Each has its benefits and drawbacks.  Security-wise one can argue that SIA is safer.  But, just as you argue for processing PDU correctly, one can process payload from AIA correctly.

Your analysis about 5280 is incorrect.  I hope we are talking about the same thing.  Item 1 in 6.1.3 a is the important thing.  This ensures signatures chain.  Item 4 ensures names chain, which is totally superfluous once the signatures chain.  If an attacker has your private key, it matters not what name he binds that key to.  So, name chaining in a certification path is not security relevant.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Thursday, May 05, 2011 3:22 PM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [pkix] Intermediary CA certificate distribution protocols

Yes, they are.

-Martin

---

From: Tom Gindin <[email-masked]>
Date: Sun, 8 May 2011 18:35:28 -0400

It sounds perfectly reasonable.  The main limitation on such a 
solution is that existing self-signed certificates treated as trust 
anchors do NOT typically contain SIA extensions and most of them last 
another 20+ years.

                        Tom Gindin

From:   "Kemp, David P." <[email-masked]>
To:     <[email-masked]>
Date:   05/06/2011 08:41 AM
Subject:        Re: [pkix] Intermediary CA certificate distribution 
protocols
Sent by:        [email-masked]

-----Original Message-----
From: Stefan Santesson

Dave

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 9 May 2011 09:02:31 -0400

> 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,…

Anything but LDAP.  Something bound to HTTP preferred.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 9 May 2011 09:08:37 -0400

> Aren't the certificate chains also passed in the clear before the session is secured?

It depends on the web server.  IIS defaults to TLS renegotiation, so the session is server-authenticated up through ChangeCipherSpec. and then the handshake is restarted under the session key.

This only protects the client's chain and identity, though.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 9 May 2011 09:12:51 -0400

> Is there more to be done in this area?

LDAP will make your network boundary people very unhappy.  It's a difficult protocol to proxy properly, so you end up with direct access to the server more often than not.  Plus you have to allow anonymous binding, which means you need to dedicate the server to serving these objects and no other, which is a waste of resources.  LDAP also won't leverage client-side network caches, nor will many clients be able to check for updates without a complete handshake and LDAP query--which are generally expensive.  

HTTP is your best answer.  Coupled with compression and if-modified-since it gets quite efficient.

-- T

---

From: Martin Rex <[email-masked]>
Date: Mon, 9 May 2011 20:52:17 +0200 (MEST)

Santosh Chokhani wrote:
> 
> In the end the AIA chasing is done using a certificate provided by
> the server.  So, either the server gave you a bad certificate or an
> attacker substituted it in which case he can substitute the whole chain.
> 
> Basically, AIA and SIA is a trade off of performance.  Each has its
> benefits and drawbacks.  Security-wise one can argue that SIA is safer.
> But, just as you argue for processing PDU correctly, one can process
> payload from AIA correctly.

It is impossible make "AIA chasing" safe.

You can try "white-listing" AIA locations, but in that case you are
really searching pre-configured locations it doesn't really matter
(security-wise) that there is AIA info in the peers cert.

There are two security-relevant aspects about "AIA chasing":

  - being able to coerce your peer into accessing arbitrary URIs from
    still untrusted&unverified certificates

  - being able to coerce your peer into accessing *SOME* HTTP-URI
    as a result of path construction and being able to attach
    and HTTP-redirect the peer's request.

By being too liberal in what your implementation does in order to
build certificate chains, you can get your consumers into big trouble.
Any searches should be limited to local resources and securely
authenticated remote resources.

> 
> Your analysis about 5280 is incorrect.  I hope we are talking about
> the same thing.  Item 1 in 6.1.3 a is the important thing.

All of rfc-5280 6.1.3 (a) is important,  And it is important that
(1) and (2) are performed before (3).  But technically, if (4) is
necessary at all (I believe it is), then it ought be the first in
the list.  The public key crypto operation is going to be significantly
more expensive than a name comparison where one of the names is a
trusted name.  Therefore it just is not sensible to do (4) after (1).

>
> This ensures signatures chain.  Item 4 ensures names chain, which is
> totally superfluous once the signatures chain.

As described above, there are places in rfc5280 that say that issuer&subject
chaining MUST be checked.  When it is to be checked at all, then it would
be sensible to perform the name comparison before the PK-operation.

So it's either first in the list or not in the list at all, but not at (4).

-Martin

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 09 May 2011 22:02:58 +0200

On 2011-05-09 20:52, Martin Rex wrote:
<snip>
> It is impossible make "AIA chasing" safe.

I think you are greatly overstating the security problems with AIAs.

A browser can download pages that contains URLs that points to arbitrary servers.
if that works, AIAs that point to very specific data read by code that isn't
particularly complex should present very limited security risks.

Anders

---

From: Martin Rex <[email-masked]>
Date: Mon, 9 May 2011 22:35:03 +0200 (MEST)

> I think you are greatly overstating the security problems with AIAs.

No, the problem is real.

> A browser can download pages that contains URLs that points

Correct.  A secure web browser is an oxymoron.

>
> if that works, AIAs that point to very specific data read by code that
> isn't particularly complex should present very limited security risks.

A web browser is a gaping security hole, so if you're looking at the
world purely from a browsers perspective, then you might not see
any additional security problems.

There are some folks, however, who believe that a browser that starts
a session with a "trusted" server, and where that server can be trusted
to _not_ serve any off-site _nor_ non-HTTPS urls, becomes vulnerable
through AIA-chasing, because that can be served on the initial
clear-text handshake when it is still unprotected and unverified.

But if one's attitude is that everything is a browser app, and everyone
and his dog is allowed to tell one's browse what to open, then one
might not bother if one's PKI software uses the same careless approach,
independent of what app is calling it.

-Martin

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 9 May 2011 15:08:58 -0700

> particularly complex should present very limited security risks.

Not directly comparable.  The browser will only get those referrals *after* it has completed the TLS verification of the server.  Furthermore any referrals will need to go through the same process from scratch (unless they are only referrals to local content).

I'm assuming https://-only;  otherwise this whole discussion seems moot.

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 10 May 2011 06:57:07 +0200

IMO, all Internet-facing SW *must* whitstand "bad content";
it doesn't matter if it is reading PKI(X) structures or is
streaming video.

Compared to protecting servers against attacks, this problem
is pretty well analyzed and solved.  IE's AIA-based certificate
caching works perfectly well AFAICT.  Firefox typically requires
manual install of sub CAs for smart cards and that *sucks*.

Anders Rundgren
developer of Internet-facing PKI-powered software

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 10 May 2011 09:14:43 -0400

Martin,

In AIA chasing when the PK enabling software visits the URL. all it can do is download a payload for certificate processing and fail that.  AIA chasing does not mean invoking a browser.

In terms of name checking, it is not a particularly useful check from security viewpoint.  It is not necessary once signature chains.  Furthermore, even if succeeds, signature chaining must be done.  SDSI and SPKI designs were correctly based on the same principle.  Your point about order is acceptable.  Note that 5280 states that anything that provides equivalent results is acceptable.  5280 logic for path validation is not optimized for performance.  It is possible to make several performance oriented optimizations.  For example, one could perform all the checks in Section 6 of 5280 before you check the signatures on the certificates and CRLs that are relevant.  One can also employ a strategy of build a little and verify a little since signature verification is less expensive than accessing pointers for CRL and certificates over the Internet.  Also note that RSA public key operation is not particularly expensive.  What takes up most of the delays we observe is accessing various Internet resources.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Monday, May 09, 2011 2:52 PM
To: Santosh Chokhani
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [pkix] Intermediary CA certificate distribution protocols

-Martin

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 10 May 2011 10:26:22 -0700

> it doesn't matter if it is reading PKI(X) structures or is

While I agree in theory, in practice there will always be bugs.  One of the reasons for "defense in depth" is to limit the impact of newly-discovered bugs.  A ready-made "visit this site that exploits this bug you haven't fixed yet" feature seems like a bad thing.

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 10 May 2011 19:58:52 +0200

On 2011-05-10 19:26, Henry B. Hotz wrote:
> While I agree in theory, in practice there will always be bugs. 
> One of the reasons for "defense in depth" is to limit the impact
> of newly-discovered bugs.  A ready-made "visit this site that exploits
> this bug you haven't fixed yet" feature seems like a bad thing.

What I meant is that PKI(X) structures do not present bigger risks
than other objects in spite of that they deal with "security".

But sure, I was recently involved in a case where a s.c. security expert
declared CRL retrieval as a "highly risky endeavor" and made the poor
customer invest in a quite expensive, proprietary semi-off-line CRL
proxy arrangement.  That's progress :-)

Anders
Continuing writing PKI SW that is *designed* for the Internet:
http://webpki.org/auth-token-4-the-cloud.html

---

From: Martin Rex <[email-masked]>
Date: Tue, 10 May 2011 19:48:03 +0200 (MEST)

Anders Rundgren wrote:
> caching works perfectly well AFAICT.

Solved?  Cough...  It is a real security vulnerability waiting
to be exploited.

There appears to be an automatic AIA-based certificate retrieval,
and it looks like it is part of MS CryptoAPI rather than, or in
addition to, MSIE, because automatic silent AIA-retrieval is also
performed when you are visualizing a cert in a file (*.cer)
when you double-click on it in Windows Explorer.

The interesting question is: does the PKI software of your TLS server
do silent automatic AIA-chasing for client certs?  And what about
AIA-chasing of server certs when your TLS server performs
programmatic TLS client access to other servers?

Supporting occasional AIA-guided discovery of intermediate CA certs,
each download individually, interactively and counsciously approved
by leap-of-faith may be OK, but automatic silent AIA-chasing
certainly is _not_ OK.  It might be convenient, but that does not
make it less of a security problem.

>
> Firefox typically requires manual install of sub CAs for
> smart cards and that *sucks*.

I admit to have no real experience with PKCS#11 interfaces to
cryptographic tokens / smartcards, but the PKCS#11 interface definition
seems to support storing more than a single cert on a token, in which
case the token not carrying all path certs would be a defective token
personalization and a software not retrieving all path certificates
would indicate a defective pkcs#11 caller.

-Martin

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 10 May 2011 11:54:13 -0700

In my experience the card only contains the user's cert.  Everything else needs to be configured, though the system may be able to verify the card from it's pre-existing trust anchors.  Don't think there is any standard expectation w.r.t. intermediate certs, so Anders' comment probably applies many places.

IMO it's better to require custom client config to use a smart card, than to chase unverified attributes over the 'net.  Depends on the application though.

---

From: Martin Rex <[email-masked]>
Date: Wed, 11 May 2011 01:49:02 +0200 (MEST)

Henry B. Hotz wrote:
> 
> In my experience the card only contains the user's cert.
> Everything else needs to be configured, though the system may be able
> to verify the card from it's pre-existing trust anchors.
> Don't think there is any standard expectation w.r.t. intermediate
> certs, so Anders' comment probably applies many places.

>From what I know about "the old days", there were early Smartcards in
the 199x with ridiculously small storage capacities, like 1 KByte.
But back then, we had VeriSign RootCAs with X.509v1 certs directly
signing EndEntity certs (i.e. no path certificates between the EE cert
and the rootCA cert).

But that was 15+ years ago.  Todays multi-CA-hierarchies should not
be used with hardware tokens / smart cards that can not accomodate
all intermediate CA certs that are used.

> 
> IMO it's better to require custom client config to use a smart card,
> than to chase unverified attributes over the 'net.
> Depends on the application though.

There is the option of interactive, conscious approval of cert discovery
aided by AIA in a leap-of-faith.

And if _you_ are trying to configure your browser to use your token,
then the AIA in the cert on your token is actually a "trusted source".

Using a token/smartcard first time for login to machine is different,
where the machine MUST not trust any information from the cert on your
token until it has been successfully verified.

-Martin