When CRMF message bodies are used in the Full Enrollment Request
message, each CRMF message MUST include both the subject and
publicKey fields in the CertTemplate (or in the altCertTemplate
control).
5. Security Considerations
5.1. Protection of Alternative Certificate Templates
This document defines extensions to the CRMF format, so security
considerations from the CRMF specification [CRMF] apply here as well.
In particular, the security of alternative certificate templates
relies upon the security mechanisms of the protocol or process used
to communicate with CAs.
Exact security requirements depend on a particular PKI deployment,
but integrity protection and message origin authentication are
typically required for certification requests. The CMP and CMC
certificate management protocols mentioned in this document provide
both integrity protection and message origin authentication for
request messages (which includes certificate templates as well).
Confidentiality may also be required where alternative certificate
templates contain subscriber-sensitive information. The CMC protocol
allows the content of request messages to be encrypted. CMP does not
include confidentiality mechanisms for certification requests, but if
confidentiality is needed, it can be achieved with a lower-layer
security protocol (e.g., TLS or IPsec).
5.2. Request Authorisation
In order to make a decision as to whether a request should be
accepted, a CA should normally be able to compare the (authenticated)
name of the sender of the request with the request subject name.
For example, an End Entity may be allowed to request additional
certificates for himself/herself. In this case, the CA will accept a
request if the Sender is equal to the Subject (of course, other
conditions will have to be checked as well before the certificate is
granted).
If a PGP certificate is requested using the extensions proposed here,
the Sender field of the request will be encoded as an ASN.1
GeneralName (in both CMP and CMC), while the Subject will be
represented as a PGP UserID. Since the PGP UserID is effectively an
unrestricted octet string, it is not always trivial to compare these
two types. It is possible that an attacker may try to submit
requests with specially crafted UserIDs (e.g., that include obscure
characters) in order to trick the CA comparison algorithm and obtain
a PGP certificate with a UserID that belongs to someone else.
In these circumstances, it is safer for the CA, when building the PGP
certificate’s UserID, to completely rebuild the UserID based on the
content of the authenticated Sender name rather than take the UserID
from the request. To achieve this, additional information about the
End Entity may be required at the CA (e.g., the EE’s email address).
5.3. PGP Parser
Software components that implement the proposed extensions (e.g., CMP
or CMC servers) will necessarily increase in complexity. If a
"standard" server is expected to be able to parse ASN.1 streams, the
"extended" server is required to be able to parse PGP streams as
well. A PGP parser code may introduce new security vulnerabilities
that can be exploited by an attacker to mount a DoS attack or gain
access to the server.
In order to reduce the consequences of a successful attack, it is
recommended that the CMP or CMC servers be run on a separate machine
from the main CA server. These protocol servers should not have
access to the main CA key and should not have write access to the CA
store.
Appendix A. Examples of OpenPGP CertTemplates
This Appendix presents examples of OpenPGP CertTemplates that are
used for requesting OpenPGP certificates from a CA.
A1. Simple Certificate Request
Alice requests an OpenPGP certificate for her public key accompanied
by a subkey.
The content of the OpenPGP CertTemplate in the request is as follows.
This CertTemplate conforms to the OpenPGP CertTemplate Required
Profile.
0000: 99 01 A2 === Pub Key packet ===
0003: 04 3C 58 27 A2 11 ver 4, created 30 Jan 2002, DSA
0009: 00 E3 FB 9D .. 2B EF DSA prime p
008B: 00 A0 FF 7E .. BA 71 DSA group order q
00A1: 03 FF 68 BC .. 56 71 DSA group generator g
0123: 03 FE 38 1F .. F2 63 DSA public key value y
01A5: B4 19 === User ID packet ===
01A7: 41 6C .. 6D 3E "Alice <alice@example.com>"
01C0: 89 00 49 === Signature packet (self-signature) ===
01C3: 04 10 11 02 ver 4, gen cert, DSA, SHA1
01C7: 00 09 05 02 3C 58 27 A2 02 1B 03
created 30 Jan 2002, key usage:
sign data and certify other keys
01D2: 00 0A 09 10 43 5C .. 06 77 issuer key id
01DE: 5A C2 left 16 bits of signed hash value
01E0: 00 A0 EB 00 .. 1B 75 DSA value r
01F6: 00 A0 F4 E4 .. A8 3D DSA value s
020C: B9 02 0D === Public Subkey packet ===
020F: 04 3C 58 27 A2 10 ver 4, created 30 Jan 2002,
Elgamal (encrypt-only) algorithm
0215: 08 00 F6 42 .. 0B 3B Elgamal prime p
0317: 00 02 02 Elgamal group generator g
031A: 07 FE 37 BA .. DF 21 Elgamal public key value y
041C: 89 00 49 === Signature packet (subkey binding) ===
041F: 04 18 11 02 ver 4, subkey binding, DSA, SHA1
0423: 00 09 05 02 3C 58 27 A2 02 1B 0C
created 30 Jan 2002, key usage:
encrypt communications and storage
042E: 00 0A 09 10 43 5C .. 06 77 issuer key id
043A: C7 DE left 16 bits of signed hash value
043C: 00 9E 21 33 .. 39 1B DSA value r
0452: 00 9F 64 D7 .. 63 08 DSA value s
0468:
CA certifies Alice’s User ID and the public key and creates the
following OpenPGP certificate:
0000: 99 01 A2 === Pub Key packet ===
0003: <the same as in the request>
01A5: B4 19 === User ID packet ===
01A7: <the same as in the request>
01C0: 89 00 49 === Signature packet (self-signature) ===
01C3: <the same as in the request>
020C: 89 00 49 === Signature packet (certification) ===
020F: 04 13 11 02 ver 4, positive cert, DSA, SHA1
0213: 00 09 05 02 3C 58 28 1A 02 1B 03
created 30 Jan 2002, key usage:
sign data and certify other keys
021E: 00 0A 09 10 F0 0D .. 1F CA issuer key id
022A: 06 DF left 16 bits of signed hash value
022C: 00 9F 57 2D .. 26 E3 DSA value r
0242: 00 A0 B3 02 .. CE 65 DSA value s
0258: B9 02 0D === Public Subkey packet ===
025B: <the same as in the request>
0468: 89 00 49 === Signature packet (subkey binding) ===
046B: <the same as in the request>
04B4:
A2. Certificate Request with Central Key Generation
Alice requests that the CA generate an RSA key pair that will be used
for signing, an RSA key pair that will be used for encryption, and
requests that the CA certify these keys. The RSA keys are requested
to be 2048 bits long with the public exponent 65537.
The content of the OpenPGP CertTemplate in the request is as follows:
0000: 99 01 0D === Pub Key packet (Template) ===
0003: 04 FF FF FF FF 01 ver 4, any creation date, RSA
0009: 08 00 FF FF .. FF FF RSA public modulus n - given length
010B: 00 11 01 00 01 RSA public exponent e
0110: B4 19 === User ID packet ===
0112: 41 6C .. 6D 3E "Alice <alice@example.com>"
012B: 89 00 23 === Signature packet (Template) ===
012E: 04 10 11 02 ver 4, gen cert, DSA, SHA1
0132: 00 09 05 02 FF FF FF FF 02 1B 03
any creation date, key usage:
sign data and certify other keys
013D: 00 0A 09 10 FF FF .. FF FF issuer key id - any
0149: 05 3A left 16 bits of signed hash value
014B: 00 08 FF DSA value r - any
014E: 00 08 FF DSA value s - any
0151: 99 01 0D === Public Subkey packet (Template) ===
0154: 04 FF FF FF FF 01 ver 4, any creation date, RSA
015A: 08 00 FF FF .. FF FF RSA public modulus n - given length
025C: 00 11 01 00 01 RSA public exponent e
0261: 89 00 20 === Signature packet (Template) ===
0264: 04 18 01 02 ver 4, subkey binding, RSA, SHA1
0268: 00 09 05 02 FF FF FF FF 02 1B 0C
any creation date, key usage:
encrypt communications and storage
0273: 00 0A 09 10 FF FF .. FF FF issuer key id - any
027F: 12 E6 left 16 bits of signed hash value
0281: 00 08 FF RSA signature value - any
0284:
CA generates keys, certifies Alice’s User ID and the public key, and
creates the following OpenPGP certificate:
0000: 99 01 0D === Pub Key packet ===
0003: 04 3C 5A A5 BB 01 ver 4, created 01 Feb 2002, RSA
0009: 08 00 C7 21 .. 5B EB RSA public modulus n
010B: 00 11 01 00 01 RSA public exponent e
0110: B4 19 === User ID packet ===
0112: 41 6C .. 6D 3E "Alice <alice@example.com>"
012B: 89 01 1F === Signature packet (self-signature) ===
012E: 04 10 01 02 ver 4, gen cert, RSA, SHA1
0132: 00 09 05 02 3C 5A A5 BB 02 1B 03
created 01 Feb 2002, key usage:
sign data and certify other keys
014D: 00 0A 09 10 8E AF .. 1A 18 issuer key id
0149: 3B 21 left 16 bits of signed hash value
014B: 07 FE 2F 1D .. C0 81 RSA signature value
024D: 89 00 49 === Signature packet (certification) ===
0250: 04 13 11 02 ver 4, positive cert, DSA, SHA1
0254: 00 09 05 02 3C 5A A5 DC 02 1B 03
created 01 Feb 2002, key usage:
sign data and certify other keys
025F: 00 0A 09 10 F0 0D .. 1F CA issuer key id
026B: BA C2 left 16 bits of signed hash value
026D: 00 9F 5E 58 .. 30 B3 DSA value r
0283: 00 A0 D1 D7 .. 5A AF DSA value s
0299: 99 01 0D === Public Subkey packet ===
029C: 04 3C 5A A5 C5 01 ver 4, created 01 Feb 2002, RSA
02A2: 08 00 C3 03 .. 8C 53 RSA public modulus n
03A4: 00 11 01 00 01 RSA public exponent e
03A9: 89 01 1F === Signature packet (subkey binding) ===
03AC: 04 18 01 02 ver 4, subkey binding, RSA, SHA1
03B0: 00 09 05 02 3C 5A A5 C5 05 1B 0C
created 01 Feb 2002, key usage:
encrypt communications and storage
03BB: 00 0A 09 10 8E AF .. 1A 18 issuer key id
03C7: C8 44 left 16 bits of signed hash value
03C9: 07 FB 04 D7 .. 75 BE RSA signature value
04CB:
Normative References
[ASN1] CCITT Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1), 1988.
[ATTCERT] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April
2002.
[CMC] Myers, M., Liu, X., Schaad, J., and J. Weinstein,
"Certificate Management Messages over CMS", RFC 2797, April
2000.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[CMP] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure: Certificate
Management Protocol (CMP)", RFC 4210, September 2005.
[CRMF] Schaad, J., "Internet X.509 Public Key Infrastructure:
Certificate Request Message Format (CRMF)", RFC 4211,
September 2005.
[OPENPGP] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors’ Addresses
Mikhail Blinov
Guardeonic Solutions
Fitzwilliam Court, Leeson Close
Dublin 2, Ireland
EMail: mikblinov@online.ie
Carlisle Adams
School of Information Technology and Engineering (SITE)
University of Ottawa
800 King Edward Avenue
P.O. Box 450, Stn A
Ottawa, Ontario, Canada K1N 6N5
EMail: cadams@site.uottawa.ca
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78 and at www.rfc-editor.org/copyright.html, 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 currently provided by the
Internet Society.