envelopedData [0] EnvelopedData }
-- The encrypted private key MUST be placed in the envelopedData
-- encryptedContentInfo encryptedContent OCTET STRING.
EncryptedValue ::= SEQUENCE {
intendedAlg [0] AlgorithmIdentifier OPTIONAL,
-- the intended algorithm for which the value will be used
symmAlg [1] AlgorithmIdentifier OPTIONAL,
-- the symmetric algorithm used to encrypt the value
encSymmKey [2] BIT STRING OPTIONAL,
-- the (encrypted) symmetric key used to encrypt the value
keyAlg [3] AlgorithmIdentifier OPTIONAL,
-- algorithm used to encrypt the symmetric key
valueHint [4] OCTET STRING OPTIONAL,
-- a brief description or identifier of the encValue content
-- (may be meaningful only to the sending entity, and used only
-- if EncryptedValue might be re-examined by the sending entity
-- in the future)
encValue BIT STRING }
-- the encrypted value itself
-- When EncryptedValue is used to carry a private key (as opposed to
-- a certificate), implementations MUST support the encValue field
-- containing an encrypted PrivateKeyInfo as defined in [PKCS11],
-- section 12.11. If encValue contains some other format/encoding
-- for the private key, the first octet of valueHint MAY be used
-- to indicate the format/encoding (but note that the possible values
-- of this octet are not specified at this time). In all cases, the
-- intendedAlg field MUST be used to indicate at least the OID of
-- the intended algorithm of the private key, unless this information
-- is known a priori to both sender and receiver by some other means.
KeyGenParameters ::= OCTET STRING
id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
--with syntax:
OldCertId ::= CertId
CertId ::= SEQUENCE {
issuer GeneralName,
serialNumber INTEGER }
id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
--with syntax:
ProtocolEncrKey ::= SubjectPublicKeyInfo
-- Registration Info in CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip 2 }
id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax
UTF8Pairs ::= UTF8String
id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
--with syntax
CertReq ::= CertRequest
-- id-ct-encKeyWithID is a new content type used for CMS objects.
-- it contains both a private key and an identifier for key escrow
-- agents to check against recovery requestors.
id-ct-encKeyWithID OBJECT IDENTIFIER ::= {id-ct 21}
EncKeyWithID ::= SEQUENCE {
privateKey PrivateKeyInfo,
identifier CHOICE {
string UTF8String,
generalName GeneralName
} OPTIONAL
}
PrivateKeyInfo ::= SEQUENCE {
version INTEGER,
privateKeyAlgorithm AlgorithmIdentifier,
privateKey OCTET STRING,
attributes [0] IMPLICIT Attributes OPTIONAL
}
Attributes ::= SET OF Attribute
END
Appendix C. Why do Proof-of-Possession (POP)
Proof-of-Possession, or POP, means that the CA is adequately
convinced that the entity requesting a certificate for the public key
Y, has access to the corresponding private key X.
POP is important because it provides an appropriate level of
assurance of the correct operation of the PKI as a whole. At its
lowest level, POP counters the "self-inflicted denial of service";
that is, an entity voluntarily gets a certificate that cannot be used
to sign or encrypt/decrypt information. However, as the following
two examples demonstrate, POP also counters less direct, but more
severe, threats:
POP for signing keys: it is important to provide POP for keys used
to sign material, in order to provide non-repudiation of
transactions. For example, suppose Alice legitimately has private
key X and its corresponding public key Y. Alice has a certificate
from Charlie, a CA, containing Y. Alice uses X to sign a
transaction T. Without POP, Mal could also get a certificate from
Charlie containing the same public key, Y. Now, there are two
possible threats: Mal could claim to have been the real signer of
T; or Alice can falsely deny signing T, claiming that it was
instead Mal. Since no one can reliably prove that Mal did or did
not ever possess X, neither of these claims can be refuted, and
thus the service provided by and the confidence in the PKI has
been defeated. (Of course, if Mal really did possess X, Alice’s
private key, then no POP mechanism in the world will help, but
that is a different problem.)
Note that one level of protection can be gained by having Alice
(as the true signer of the transaction) include in the signed
information, her certificate or an identifier of her certificate
(e.g., a hash of her certificate). This might make it more
difficult for Mal to claim authorship; he would have to assert
that he incorrectly included Alice’s certificate, rather than his
own. However, it would not stop Alice from falsely repudiating
her actions. Since the certificate itself is a public item, Mal
indeed could have inserted Alice’s certificate or identifier into
the signed transaction, and thus its presence does not indicate
that Alice was the one who participated in the now-repudiated
transaction. The only reliable way to stop this attack is to
require that Mal prove he possesses X before his certificate is
issued.
For signing keys used only for authentication, and not for non-
repudiation, the threat is lower because users may not care about
Alice’s after-the-fact repudiation, and thus POP becomes less
important. However, POP SHOULD still be done wherever feasible in
this environment, by either off-line or on-line means.
POP for key management keys: Similarly, POP for key management
keys (that is, keys used for either key agreement or key exchange)
can help to prevent undermining confidence in the PKI. Suppose
that Al is a new instructor in the Computer Science Department of
a local university. Al has created a draft final exam for the
Introduction to Networking course he is teaching. He wants to
send a copy of the draft final to Dorothy, the Department Head,
for her review prior to giving the exam. This exam will of course
be encrypted, as several students have access to the computer
system. However, a quick search of the certificate repository
(e.g., search the repository for all records with
subjectPublicKey=Dorothy’s-value) turns up the fact that several
students have certificates containing the same public key
management key as Dorothy. At this point, if no POP has been done
by the CA, Al has no way of knowing whether all of the students
have simply created these certificates without knowing the
corresponding private key (and thus it is safe to send the
encrypted exam to Dorothy), or whether the students have somehow
acquired Dorothy’s private key (and thus it is certainly not safe
to send the exam). Thus, the service to be provided by the PKI
allowing users to communicate with one another, with confidence in
who they are communicating with, has been totally defeated. If
the CA is providing POP, then either no students will have such
certificates, or Al can know with certainty that the students do
indeed know Dorothy’s private key, and act accordingly.
Author’s Address
Jim Schaad
Soaring Hawk Consulting
PO Box 675
Gold Bar, WA 98251
EMail: jimsch@exmsft.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 currently provided by the
Internet Society.