provides the built-in db_datareader account that only allows read
access to tables (but see the note above about what can be done even
with read-only access) and the ability to run the server under a
dedicated low-privilege account (a standard feature of Unix systems).
The mechanism described in this document is not intended to function
as a trusted directory/database. In particular, users should not
assume that just because they fetched a public key or certificate
from an entity claiming to be X, that X has made any statement about
the veracity of the public key or certificate. The use of a signed
representation of the items stored removes the need to depend on the
certificate store for any security service other than availability.
Although it’s possible to implement a trusted directory/database
using HTTPS or some other form of secured/trusted link, this is a
local policy/configuration issue, and in the absence of such
additional security measures users should apply appropriate levels of
verification to any keys or certificates fetched before they take
them into use.
5. IANA Considerations
No action by IANA is needed. The AIA/SIA accessMethod types are
identified by object identifiers (OIDs) from an arc managed by the
PKIX working group. Should additional accessMethods be introduced
(for example, for attribute certificates or non-X.509 certificate
types), the advocates for such accessMethods are expected to assign
the necessary OIDs from their own arcs.
6. Acknowledgements
Anders Rundgren, Blake Ramsdell, Jeff Jacoby, David Shaw, and members
of the ietf-pkix working group provided useful input and feedback on
this document.
7. References
7.1. Normative References
[FIPS180] Federal Information Processing Standards Publication
(FIPS PUB) 180-1, Secure Hash Standard, 17 April
1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R.
Thayer, "OpenPGP Message Format", RFC 2440, November
1998.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public
Key Infrastructure Operational Protocols: FTP and
HTTP", RFC 2585, May 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
June 1999.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
for specifying the location of services (DNS SRV)",
RFC 2782, February 2000.
[RFC2854] Connolly, D. and L. Masinter, "The ’text/html’ Media
Type", RFC 2854, June 2000.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T.
Roessler, "MIME Security with OpenPGP", RFC 3156,
August 2001.
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo,
"(Extensible Markup Language) XML-Signature Syntax
and Processing", RFC 3275, March 2002.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo,
"Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC
3280, April 2002.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004.
7.2. Informative References
[Birkholz] "Special Ops: Host and Network Security for
Microsoft, Unix, and Oracle", Erik Birkholz et al,
Syngress Publishing, November 2002.
[Garcia-Molina] "Main Memory Database Systems", Hector Garcia-Molina
and Kenneth Salem, IEEE Transactions on Knowledge and
Data Engineering, Vol.4, No.6 (December 1992), p.509.
[Gutmann] "A Reliable, Scalable General-purpose Certificate
Store", P. Gutmann, Proceedings of the 16th Annual
Computer Security Applications Conference, December
2000.
[Heidemann] "Performance Interactions Between P-HTTP and TCP
Implementations", J. Heidemann, ACM Computer
Communications Review, April 1997.
[HKP] "A PGP Public Key Server", Marc Horowitz, 2000,
http://www.mit.edu/afs/net.mit.edu/project/pks/
thesis/paper/thesis.html. A more complete and up-
to-date overview of HKP may be obtained from the
source code of an open-source OpenPGP implementation
such as GPG.
[Ji] "Affinity-based Management of Main Memory Database
Clusters", Minwen Ji, ACM Transactions on Internet
Technology, Vol.2, No.4 (November 2002), p.307.
[Krishnamurthy] "PRO-COW: Protocol Compliance on the Web - A
Longitudinal Survey", Balachander Krishnamurthy and
Martin Arlitt, Proceedings of the 3rd Usenix
Symposium on Internet Technologies and Systems
(USITS’01), March 2001, p.109.
[Nielsen] "Network Performance Effects of HTTP/1.1, CSS1, and
PNG", H.Nielsen, J.Gettys, A.Baird-Smith,
E.Prud’hommeaux, H.Wium Lie, and C.Lilley, 24 June
1997, http://www.w3.org/Protocols/HTTP/
Performance/Pipeline.html
[PKCS11] PKCS #11 Cryptographic Token Interface Standard, RSA
Laboratories, December 1999.
[PKCS15] PKCS #15 Cryptographic Token Information Syntax
Standard, RSA Laboratories, June 2000.
[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP
56, RFC 3205, February 2002.
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing
TCP’s Initial Window", RFC 3390, October 2002.
[RFC3875] Robinson, D. and K. Coar, "The Common Gateway
Interface (CGI) Version 1.1", RFC 3875, October 2004.
[Spero] "Analysis of HTTP Performance Problems", S.Spero,
July 1994, http://www.w3.org/Protocols/HTTP/1.0/
HTTPPerformance.html.
[UPNP] "Universal Plug and Play Device Architecture, Version
1.0", UPnP Forum, 8 June 2000.
Author’s Address
Peter Gutmann
University of Auckland
Private Bag 92019
Auckland, New Zealand
EMail: pgut001@cs.auckland.ac.nz
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).