30% TANIEJ!

Thinking in Java. Edycja polska. Wydanie IV

67.90 zł   97.00 zł

RFC 4387           Certificate Store Access via HTTP       February 2006


2.5.3.  URI Notes

   Pre-constructed URIs that fetch a certificate/public key matching a
   fixed search criterion may be useful for items such as web pages or
   business cards, or even for technical support/helpdesk staff who want
   to mail to users but can't find the certificate themselves.  These
   URIs may also be used to enforce privacy measures when distributing
   certificates by perturbing the search key in a manner known only to
   the certificate/public key store, or to the certificate store and
   users (in other words, by converting the URI into a capability).  For
   example, a user with a newly-issued certificate could be instructed
   to fetch it with a key of "x-encrCertHash=...", which is decrypted by
   the certificate store to fetch the appropriate certificate, ensuring
   that only the certificate owner can fetch their certificate
   immediately after issue.  Similarly, an organisation that doesn't
   want to make its certificates available for public query might
   require a MAC on search keys (e.g., "x-macCertHash=...") to ensure
   that only authorised users can search for certificates (although a
   more logical place for access control, if a true web server is being
   used to access the store, would obviously be at the HTTP level).

   The query types have been specifically chosen to be not just an HTTP
   interface to LDAP but a general-purpose retrieval mechanism that
   allows arbitrary certificate/public key storage mechanisms (with a
   bias towards simple {key,value} stores, which are deployed almost
   universally, whether as ISAM, Berkeley DB, or an RDBMS) to be
   employed as back-ends.  This specification has been deliberately
   written to be technology neutral, allowing any {key,value} lookup
   mechanism to be used.  It doesn't matter if you choose to have
   trained chimpanzees look up certificates in books of tables, as long
   as your method can provide the correct response with reasonable
   efficiency.

   Certificate/public key and CRL stores are allocated separate URIs
   because they may be implemented using different mechanisms.  A
   certificate store typically contains large numbers of small items,
   while a CRL store contains a very small number of potentially large
   items.  By providing independent URIs, it's possible to implement the
   two stores using mechanisms tailored to the data they contain.

   PGP combines key and revocation information into a single data object
   so that it's possible to return both public keys and revocation
   information from the same URI.  If distinct key and revocation
   servers are available, these can provide a slight performance gain
   since fetching revocation information doesn't require fetching the
   key that it applies to.  If no separate servers are available, a

Gutmann                     Standards Track                    [Page 10]