Subject: New topic - selective retrieval of cross-certs

From: Sharon Boeyen <[email-masked]>
Date: Wed, 1 Mar 2000 13:32:55 -0500

I'd like to initiate discussion on solutions to the following problem:

In a strict hierarchy, each cert has a single superior and 
identification and retrieval of the next cert to build a path 
(from the EE cert to the root) is straightforward through use 
of the AIA extension. However, in a distributed trust model, 
especially one using a 'bridge CA' or hub and spoke model, the selection 
of the next cert to build a path is not as straightforward. Some build from 
the EE to a trusted CA key, others build from the trusted CA key toward 
the root. Some build a path and then start validating the certs, others 
validate the certs as they are building the chain in order to do early 
pruning of the set of certs. All these are valid techniques and I'm trying
to look
at the scaling issues in all these environments. As the number of CA
certs issued to/by any given CA grows, it becomes infeasible for a verifier
to 
deal with the complete set of certs in a single basket, such as a single
directory 
attribute in its entirety with all values at once. For instance, if a bridge
CA has 
1,000 spokes, then its 'outbound' or reverse cross-certificates would take
on the order 
of one hour to download over a phone. Obviously this is unacceptable. 

A couple of options seem interesting.

If a directory is used as the repository, then the use of extended filters
in 
directory search operations may be useful. This would allow a relying party
to 
retrieve only a subset of the certificates in a directory attribute, based
on 
whatever criteria were interesting to the relying party (e.g. retrieve only
the 
certs that contain a given policy OID or only those that were issued within
a 
given name subtree etc.). Issues with this approach may be the complexity of

supporting the filters, matching rules and search operations themselves in
products.

An alternative to the directory filters would be be having 
the verifier use HTTP to retrieve just those certificates that meet its
requirements.
To do this effectively in path development/processing that is done from a
trusted 
CA key toward the EE cert, a new extension "subjectInfoAccess" similar to
the authorityInfoAccess
would be useful. The SIA would contain a URL that represented the set of
certificates issued
to CAs by the CA that is the subject of the certificate containing the SIA
extension. 
A verifier would perform an http 'get'on the URL contained in the
subjectInfoAccess 
extension of a certificate. The current values of the state variables in the
certification path 
processing algorithm would be included in the 'get' operation as parameters.
For instance, 
the current acceptable policies, name constraints, inhibit mapping
indicator, explicit policy 
indicator etc are included. Then a CGI on the target URL could return only
those outbound 
certificates from the full list that satisfy the requirements defined by
those parameters.

Similarly, if building the path from the EE toward a trusted CA key, the AIA
could contain a URL 
that represented a set of certificates (rather than a single one as in a
strict hierarchy) and 
the 'get' could contain a set of parameters to filter only certificates that
match the processing
parameters. 

As I said earlier, these techniques wouldn't be necessary in a single strict
hierarchy that 
isn't cross certified with any other PKIs, but in distributed trust models
(especially hub & spoke CAs) 
as well as in cross-certified hierarchies and mixed environments, they would
be useful.

I'm interested in hearing feedback on this http proposal as well as any
other ideas for 
filtering sets of certs to make path construction and validation efficient
in very large scale
environments. Are folks interested in pursuing http based mechanisms further
within PKIX? What, if 
anything, should PKIX do about this issue? Do people prefer the directory
filter approach, the http
approach, other?

Sharon 

Sharon Boeyen
Entrust Technologies
[email-masked]

---

From: Steve Hanna <[email-masked]>
Date: Wed, 01 Mar 2000 16:20:15 -0500

Thanks, Sharon, for raising these issues. Building certification paths
in a distributed trust model will probably grow in importance as
cross-certification increases. Our research group has spent a good deal
of time studying this problem. My comments appear below.

Sharon Boeyen wrote:
> If a directory is used as the repository, then the use of extended
> filters in directory search operations may be useful. This would allow
> a relying party to retrieve only a subset of the certificates in a
> directory attribute, based on whatever criteria were interesting to
> the relying party (e.g. retrieve only the certs that contain a given
> policy OID or only those that were issued within a given name subtree
> etc.). Issues with this approach may be the complexity of
> supporting the filters, matching rules and search operations
> themselves in products.

This approach could, of course, be supported using the certificate
matching rules defined in X.509 (or some variation).

> the verifier use HTTP to retrieve just those certificates that meet
> its requirements. To do this effectively in path
> development/processing that is done from a trusted CA key toward the
> EE cert, a new extension "subjectInfoAccess" similar to the
> authorityInfoAccess would be useful. The SIA would contain a URL that
> represented the set of certificates issued to CAs by the CA that is
> the subject of the certificate containing the SIA extension.
> subjectInfoAccess extension of a certificate. The current values of
> the state variables in the certification path processing algorithm
> would be included in the 'get' operation as parameters. For instance,
> indicator, explicit policy indicator etc are included. Then a CGI on
> the target URL could return only those outbound certificates from the
> full list that satisfy the requirements defined by those parameters.

Why is this better than the solution described above? The complexities
you described above all apply here. The only difference is that you have
added a new extension to the certificate and changed the transport
protocol from LDAP to HTTP (which is probably less suited for the job).

> Similarly, if building the path from the EE toward a trusted CA key,
> the AIA could contain a URL that represented a set of certificates
> (rather than a single one as in a strict hierarchy) and the 'get'
> could contain a set of parameters to filter only certificates that
> match the processing parameters.

Same comments as above. If people really want the ability to do this
with HTTP, let's send the matching rule over as the parameter. That way,
we won't need two ways to encode the same information.

> I'm interested in hearing feedback on this http proposal as well as
> any other ideas for filtering sets of certs to make path construction
> and validation efficient in very large scale environments. Are folks
> interested in pursuing http based mechanisms further within PKIX?
> What, if anything, should PKIX do about this issue? Do people prefer
> the directory filter approach, the http approach, other?

Our group is definitely interested in finding ways to make path
construction easier. We would like to propose some specific changes and
additions to the CertificateAssertion that will assist in building
certification paths (such as changing the policy field to match any
certificate that includes *any* of the specified policies). We have also
participated (with David Chadwick) in the development of an Internet
Draft (draft-ietf-ldapext-matchedval-01.txt) that would allow an LDAP
server to filter the elements of a crossCertificatePair attribute and
return only those that match a given matching rule.

Steve Hanna
Sun Labs

---

From: Sean Mullan <[email-masked]>
Date: Thu, 02 Mar 2000 16:57:47 +0000

Hi Sharon,

I'd like to raise another related issue with respect to building
certification paths.

As you note below, building certification paths in a 'reverse'
direction (from trust anchor to EE) is a valid way to build
certification paths. However, RFC 2587 (PKIX LDAPv2 schema) specifies
that the storage of cross certificates in the reverse component of
the crossCertificatePair is optional. It is not possible to efficiently
build a certification path in a 'reverse' direction unless the 
certificates are populated in the reverse component of the crossCertificatePair
attribute. Specifying that this feature is optional makes it
difficult to build paths in a reverse direction in a trust model
where lots of cross certificates and multiple directories
are involved and you don't know if the CAs support
the optional storage.

I would like to suggest that RFC 2587 be ammended to make storage
of cross certificates in the reverse component of the
crossCertificatePair attribute mandatory.

Thanks,
--Sean

-- 
************************************************************
Sean Mullan
Sun Microsystems                        tel: +353 1 819 9176
East Point Business Park                fax: +353 1 819 9262
Clontarf                         mailto: [email-masked]
Dublin 3
Ireland
************************************************************