Subject: RE: New topic - selective retrieval of cross-certs

From: Sharon Boeyen <[email-masked]>
Date: Thu, 2 Mar 2000 09:26:53 -0500

Steve, 
Some interesting ideas. I'm not particularly wedded to any specific 
solution, but trying to raise some ideas for consideration. I'm very 
familiar with the certificateAssertion match capabilities but I'm not
familiar enough with directory and PKI client products to know whether 
these are likely to be natively supported or not, because of their 
complexity. One appealing aspect of http is that it can more easily 
address the firewall problems that directory protocols have more 
trouble with. I'm not suggesting that we drop directory solutions at
all, but think that http may also be a promising vehicle for repository 
access especially the verifier doesn't necessarily have the address for 
the directory in question or where firewall traversal is an issue. 

Your idea of passing the certificateAssertion syntax as http parameters
may also be promising. One of the efficiencies I have in mind relates 
to the environment where the verifier is doing validation of certs while 
building the path. As the path processing variables change (e.g.
allow/prevent
policy mapping) it would be nice to be able to change the parameters of 
the 'filter' with each subsequent cert retrieval attempt. If the
certificateAssertion
can handle all those variables, or is close to doing so, that's certainly
worth 
pursuing. That way we could have a single syntax that applies both to LDAP
and 
HTTP mechanisms.

David, thoughts?

Sharon

> -----Original Message-----
> From: Steve Hanna [mailto:[email-masked]]
> Sent: Wednesday, March 01, 2000 4:20 PM
> To: Sharon Boeyen
> Cc: [email-masked]'
> Subject: Re: New topic - selective retrieval of cross-certs
> 
> 
> 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).
> 
> > 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.
> 
> 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: Steve Hanna <[email-masked]>
Date: Thu, 2 Mar 2000 11:15:55 -0500

>complexity.

I can't speak for directory implementors, but PKI client products have lots of
code that's much more complicated than putting together a certificateAssertion.
How about parsing the dozens of complicated extensions that MUST be supported
under PKIX! If we can help improve cert path building, that would be very
helpful. And PKI clients that don't want to use the certificateAssertion (for
whatever reason) can pull down all the certs and filter them on the client.

> One appealing aspect of http is that it can more easily 

There is a classic tendency to piggyback *everything* on top of http, citing
firewall traversal. This drives sysadmins batty and causes firewall vendors
to add stateful filtering so that they can block out certain *kinds* of HTTP
traffic. We may need to do this, but I would prefer not to if possible.

As for the question of how the PKI client knows the address of the directory,
why not use put in the CRLDistributionPoints extension a URIName with an ldap
scheme (including the DNS name of the directory server)?

>pursuing. That way we could have a single syntax that applies both to LDAP

I think we're close. In fact, I noticed that the definition of the policy
field in the certificateAssertion was changed in the most recent X.509 draft
to include the very change I suggested in my last message! I suppose that's
probably due to somebody's (Santosh's?) experience with building certification
paths. When I get back to my office, I'll dig up the list of other changes we
would suggest. But the existing certificateAssertion is pretty decent.

Thanks,

Steve