< draft-yoon-pkix-wireless-internet-00.txt		draft-yoon-pkix-wireless-internet-01.txt >
	PKIX Working Group J. H. Yoon (KISA)		PKIX Working Group J. H. Yoon (KISA)
	Internet Draft C. J. Chung		Internet Draft C. J. Chung
	expires May, 2002 Y. Lee		expires November, 2002 Y. Lee
	J. I. Lee		J. I. Lee
	November, 2001		H. S. Lee
			May, 2002
	Wireless Internet X.509 Public Key Infrastructure		Wireless Internet X.509 Public Key Infrastructure
	Certificate Request Message Format and Protocol (WCRMFP)		Certificate Request Message Format and Protocol (WCRMFP)
	<draft-yoon-pkix-wireless-internet-00.txt>		<draft-yoon-pkix-wireless-internet-01.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with all		This document is an Internet-Draft and is in full conformance with all
	provisions of Section 10 of RFC 2026.		provisions of Section 10 of RFC 2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	This document describes the Wireless Certificate Request		This document describes the Wireless Certificate Request
	Message Format and Protocol (WCRMFP) in wireless internet		Message Format and Protocol (WCRMFP) in wireless internet
	environment. This format and protocol are used to convey a request		environment. This format and protocol are used to convey a request
	for a certificate to a Certification Authority (CA) (possibly via a		for a certificate to a Certification Authority (CA) (possibly via a
	Registration Authority (RA)) for the purposes of X.509 certificate		Registration Authority (RA)) for the purposes of X.509 certificate
	production. The request will typically include a public key and		production. The request will typically include a public key and
	associated registration information.		associated registration information.
	1. Introduction		1. Introduction
	Differring from wired system terminal, wirelss one has many		Different from wired system terminal, wireless one has many
	limitations in CPU, memory, battery life, and a user interface.		limitations in CPU, memory, battery life, and a user interface.
	Moreover the wireless network has very low bandwith, latency, and		Moreover the wireless network has very low bandwidth, latency, and
	data loss. For that reasons, using PKCS#10 or CRMF(RFC2511) is		data loss. For that reasons, using CRMF(RFC2511) is a burden to
	difficult in wireless environment. Actually the problem comes from		wireless and environment. So new message format in certificate
	ASN.1 encoding. Some big modules, like ASN.1 (compilier) and		request is needed.
	LDAP etc., can not be uploaded at mobile terminals. So new format
	and protocol in certificate request are needed.
	This document describes optimised certificate request format and		This document describes optimised certificate request format fitted
	protocol using SignText function[WAPscriptCrypto] defined in WAP		for wireless and mobile devices protocol using SignText function
	specification.		[WAPscriptCrypto] defined in WAP specification.
	1.1 Protocol requirements		1.1 Protocol requirements
	Construction of a certification request involves the following steps:		Construction of a certificate request needs the following requirements:
	a) A SignedContent(Certificate Request) value is constructed. This		a) Certificate Request Message Format is constructed at mobile
	value may include the public key, a portion of the end-entity's (EE's)		device. This value should include the public key, end-entity's
	ID and password. Other requested certificate fields, and additional		(EE's) ID and password. Other requested certificate fields, and
	control information related to the registration process are made in		additional control information related to the registration process
	off-line.		are made in out-of-band.
	b) A proof of possession (of the private key corresponding to the		b) A proof of possession (of the private key corresponding to the
	public key for which a certificate is being requested) value may		public key for which a certificate is being requested) value is
	be calculated across the SignedContent value.		included in certificate request massage.
	c) The CR(Certificate Request) message is securely		c) The CR(Certificate Request) message is securely
	communicated to a CA. However the specific methods of secure		communicated to a CA. However the specific methods of secure
	transport are beyond the scope of this document.		transport are beyond the scope of this document.
	1.2 Terminology		1.2 Terminology
	The key words "MUST", "REQUIRED", "SHOULD",		The key words "MUST", "REQUIRED", "SHOULD",
	"RECOMMENDED", and "MAY" in this document (in uppercase, as		"RECOMMENDED", and "MAY" in this document (in uppercase, as
	shown) are to be interpreted as described in RFC 2119.		shown) are to be interpreted as described in RFC 2119.
	skipping to change at page 3, line 17 ¶		skipping to change at page 3, line 17 ¶
	F) LDAP: Lightweight Directory Access Protocol		F) LDAP: Lightweight Directory Access Protocol
	G) POP: Proof of Possession [RFC2510]		G) POP: Proof of Possession [RFC2510]
	H) PEM: Privacy Enhanced Mail		H) PEM: Privacy Enhanced Mail
	I) RA: Registration Authority		I) RA: Registration Authority
	2. Protocol Overview		2. Protocol Overview
	2.1 Certificate Request Process		2.1 Certificate Request Process
	To get a certificate, the subscriber MUST be identifed at RA through		To get a certificate, the subscriber MUST be identifed at RA through
	direct confrontation and the subscriber makes the document which		out-of-band and the subscriber makes the document which
	contains other information for certificate. Then the RA SHOULD give		contains other information for certificate. Then the RA SHOULD give
	an ID and a Password for certificate request to subscriber.		subscriber an ID and a Password for certificate request.
	The following describes the procedure that a user receives a digital		The following describes the procedure that a user receives a digital
	signature certificate in wireless PKI model.		signature certificate in wireless PKI model.
	a) RA (or CA) MUST confirm the subscriber's identification through		a) RA (or CA) MUST confirm the subscriber's identification through
	direct confrontation.		direct confrontation.
	b) RA (or CA) SHOULD give an ID (Reference Number) and a		b) RA (or CA) SHOULD give an ID (Reference Number) and a
	Password (Authorization Code) to subscriber.		Password (Authorization Code) to subscriber.
	c) RA MUST enroll a subscriber's information in its data-base and		c) RA MUST enroll a subscriber's information in its data-base and
	sends it to related CA		sends it to related CA
	d) The subscriber SHOULD generate a key pair and certificate		d) The subscriber SHOULD generate a key pair and make certificate
	request form, signs on certificate request form, and sends it to RA		request form, sign on certificate request form, and send it to RA
	(or CA).		(or CA).
	e) The RA (or CA) that received the certificate request form and		e) The RA (or CA) that received the certificate request form and
	subscriber's digital signature MUST confirm the ownership of the		subscriber's digital signature MUST confirm the ownership of the
	public key that actually corresponds to private key through verifying		public key that actually corresponds to private key through verifying
	the subscriber's digital signature. RA MAY send certificate request		the subscriber's digital signature. RA MAY send certificate request
	form (PKCS#10 or RFC2511) to CA.		form (RFC2511) to CA.
	f) The CA issues a subscriber's X.509v3 certificate.		f) The CA issues a subscriber's X.509v3 certificate.
	g) The CA publishes the certificate on its directory and SHOULD		g) The CA publishes the certificate on its directory or WEB and
	give a subscriber's certificate or certificate URL [See Appendix C] to		SHOULD give a subscriber's certificate or certificate URL
	RA or subscriber.		[See Appendix C] to RA or subscriber.
	h) The RA SHOULD send the response[See Appendix C]		h) The RA SHOULD send the response[See Appendix C]
	information to the subscriber.		information to the subscriber.
	2.2 Configuration of certification request format		2.2 Configuration of certification request format
	Subscribers SHOULD generate certificate request format including		Subscriber SHOULD generate certificate request format including
	their public keys, and configure a request format that can prevent		their public keys, and configure a request format that can prevent
	Replay attack, message counterfeiting and forging, and deliver the		Replay attack, message counterfeiting and forging, and deliver the
	certification request formats to a CA (or through an RA).		certification request formats to a CA (or through an RA).
	2.2.1 Message Format		2.2.1 Message Format
	SignedContent = signText(M|H(M,N), 1, 0, í—í˜) [See Appendix B]		SignedContent = signText(M|HMAC(M,K), 1, 0, " ") [See Appendix B]
	where, M = type | PK | ID		where, M = type | PK | ID
	N = Password		K = Password
	H(M,N) [See RFC2104]		HMAC(M,K)=H(K XOR opad, H(K XOR ipad, M)) [See RFC2104]
	"type" : Type string value of management type (digital signature:		"type" : Type string value of management type (digital signature:
	110, key distribution: 120) [See appendix A]		110, key distribution: 120) [See appendix A]
	PK: digital signature verifying key of subscriber or public key for		PK: digital signature verifying key of subscriber or public key for
	key distribution [See appendix D]		key distribution [See appendix D]
	ID: reference number of subscriber		ID: reference number of subscriber
	Password : authorization code of subscriber		Password : authentication code of subscriber
	As the option of signText SHOULD be set at 1, PK (public key) and		As the option of signText SHOULD be set at 1, PK (public key) and
	ID are extracted from M among signed messages.		ID are extracted from M among signed messages.
	2.2.2 Structure of certification request protocol		2.2.2 Structure of certification request protocol
	++++++++++++++++++++++++++++++++++++++++++++++++		Subscriber | | RA (or CA)
	Subscriber | | RA (or CA)		CR = SignedContent | |
	++++++++++++++++++++++++++++++++++++++++++++++++		| ----> |
	CR = SignedContent | |		| | SignedContent = CR
	| -----> |		response | <---- |
	| | SignedContent = CR
	++++++++++++++++++++++++++++++++++++++++++++++++
	RA(or CA) MUST verify SignedContent by means of PK (public		RA (or CA) MUST verify SignedContent by means of PK (public
	key). (POP verification process [RFC2510])		key). (POP verification process [RFC2510])
	RA (or CA) retrieves the Password corresponding to ID from its		RA (or CA) retrieves the Password corresponding to ID from its
	database, and composes N. Then, RA (or CA) calculates H(M,N),		database, and composes N. Then, RA (or CA) calculates H(M,N),
	where the M is in the Subscriber's signed CR message. And RA		where the M is in the Subscriber's signed CR message. And RA
	(or CA) compares calculated value with subscriber's hash value		(or CA) compares calculated value with subscriber's hash value
	which is in the Subscriber's signed CR message. (user		which is in the Subscriber's signed CR message. (user
	authentication)		authentication)
			Response [see Appendix C]
	3. References		3. References
	[WAP211] Forum Proposed Version 9-Mar-2000, WAP-211-X.509:		[WAP211] Forum Proposed Version 9-Mar-2000, WAP-211-X.509:
	WAP Certificate and CRL Profile		WAP Certificate and CRL Profile
	[WAP217] WAP Forum Proposed Version 3-Mar-2000,		[WAP217] WAP Forum Proposed Version 3-Mar-2000,
	WAP-217-WPKI: Wireless Application Protocol Public Key		WAP-217-WPKI: Wireless Application Protocol Public Key
	Infrastructure Definition		Infrastructure Definition
	[WAPe2e] WAP Forum Approved Version 11-July-2000, WAPTM		[WAPe2e] WAP Forum Approved Version 11-July-2000, WAPTM
	skipping to change at page 6, line 19 ¶		skipping to change at page 6, line 19 ¶
	[PKCS10] RSA Laboratories, "PKCS#10, Certification Request		[PKCS10] RSA Laboratories, "PKCS#10, Certification Request
	Syntax Format", 1999.		Syntax Format", 1999.
	[PKCS12]RSA Laboratories, "PKCS#12, Personal Information		[PKCS12]RSA Laboratories, "PKCS#12, Personal Information
	Exchange Standard", 1999.		Exchange Standard", 1999.
	4. Security Considerations		4. Security Considerations
	To apply the PKI solution in wireless environment, X.509v3		To apply the PKI solution in wireless environment, X.509v3
	certificate is needed at the mobile terminal. However because of its		certificate is needed at the mobile terminals. However because of
	limitation, the certificate management protocol, like PKCS#10 or		its performance limitation, the certificate management protocol, like
	RFC2510, can not be implemented in it. Thus new certificate		PKCS#10 or RFC2510, can not be implemented in it. Thus new
	management protocol and format is required. And the this		certificate management protocol and format is required. And the
	protocol and format should be securely transferred between		this protocol and format should be securely transferred between
	subscriber and RA or CA.		subscriber and RA or CA.
	This document describes the certificate request format and protocol		This document describes the certificate request format and protocol
	which can provide the message integrity and proof of possession		which can provide the message integrity and proof of possession
	concerning with protection from replay attack and DoS attack.		protecting from replay attack.
	5. Intellectual Property Rights		5. Intellectual Property Rights
			This document and translations of it may be copied and furnished to
			others, and derivative works that comment on or otherwise explain it
			or assist in its implementation may be prepared, copied, published
			and distributed, in whole or in part, without restriction of any kind.
	The IETF has been notified of intellectual property rights claimed in		The IETF has been notified of intellectual property rights claimed in
	regard to some or all of the specification contained in this		regard to some or all of the specification contained in this
	document. For more information consult the online list of claimed		document. For more information consult the online list of claimed
	rights (see http://www.ietf.org/ipr.html).		rights [see http://www.ietf.org/ipr.html and the part related with WAP,
			see http://www.wapforum.org/what/ipr.htm].
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		intellectual property or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on the		has made any effort to identify any such rights. Information on the
	IETF's procedures with respect to rights in standards-track and		IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies		standards-related documentation can be found in BCP-11. Copies
	of claims of rights made available for publication and any		of claims of rights made available for publication and any
	assurances of licenses to be made available, or the result of an		assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use		attempt made to obtain a general license or permission for the use
	of such proprietary rights by implementors or users of this		of such proprietary rights by implementors or users of this
	specification can be obtained from the IETF Secretariat.		specification can be obtained from the IETF Secretariat.
			6. Acknowledgements
			The authors gratefully acknowledge the contributions of various
			members of the Wireless PKI Working Group in Korea - Licensed
			CAs, PKI vendors, and Telecommunication companies. Many of
			these clarified and improved this document.
	Appendix A. Definition of management type string, and encoding &		Appendix A. Definition of management type string, and encoding &
	decoding rules		decoding rules
	íš Definition of management type string		* Definition of management type string
	++++++++++++++++++++++++++++++++++++++++++++++++
	Type| Encryption & digital signature | Digital signature | Encryption		Type| Encryption & digital signature | Digital signature | Encryption
	++++++++++++++++++++++++++++++++++++++++++++++++		Request | 100 | 110 | 120
	Request | 100 110 120		Re-issuing | 200 | 210 | 220
	Re-issuing | 200 210 220		Update | 300 | 310 | 320
	Update | 300 310 320		Key Update | 400 | 410 | 420
	Update (key) | 400 410 420		Suspension | 500 | 510 | 520
	Suspension | 500 510 520		Revocation | 600 | 610 | 620
	Revocation | 600 610 620
	++++++++++++++++++++++++++++++++++++++++++++++++
	type = 3byte(string) & req = Base64 encoded(string) : POST mode		type = 3byte(string) & req = Base64 encoded(string) : POST mode
	is used.		is used.
	íš Encoding & Decoding rules		* Encoding & Decoding rules
	- In this document, all binary data MUST comply with the base64		- In this document, all binary data MUST comply with the base64
	encoding rules.		encoding rules.
	- The vertical line (|) is used as the separator, but it will not be		- The vertical line (|) is used as the separator, but it will not be
	used for hash message concatenation.		used for hash message concatenation.
	- The vertical line (|) will be excluded from the range of characters		- The vertical line (|) will be excluded from the range of characters
	that can be used as reference numbers (ID).		that can be used as reference numbers (ID).
	- The maximum length of the reference number is 10 characters,		- The maximum length of the reference number is 10 characters,
	and it is alphanumeric and case-sensitive.		and it is alphanumeric and case-sensitive.
	- The maximum length of the authorization code is 30 characters,		- The maximum length of the authorization code is 30 characters,
	and it is alphanumeric and case-sensitive.		and it is alphanumeric and case-sensitive.
	- The minimum length of the authorization code varies depending		- The minimum length of the authorization code varies depending
	on the period.		on the period.
	+++++++++++++++++++++++++++
	Period Length
	+++++++++++++++++++++++++++
	1 day 12 characters
	3 days 13 characters
	1 week 14 characters
	10 days 14 characters
	2 weeks 15 characters
	1 month 16 characters
	+++++++++++++++++++++++++++
	íÛ In case that ECDSA key is 20 bytes long, and the reference
	number is 8 bytes long
	Appendix B. SignText function [WAPscriptCrypto]		Appendix B. SignText function [WAPscriptCrypto]
	B.1 SignText configuration		B.1 SignText configuration
	signedString = Crypto.signText(StringToSign, options,		signedString = Crypto.signText(StringToSign, options,
	keyIdType, keyId)		keyIdType, keyId)
	B.2 Parameters		B.2 Parameters
	íñstringToSign = String		*stringToSign = String
	: contents of actual message		: contents of actual message
	íñoptions = Integer		*options = Integer
	: OR operation of several optional values is possible.		: OR operation of several optional values is possible.
	+++++++++++++++++++++++++++++++++++++++++++++++++
	value description		value description
	+++++++++++++++++++++++++++++++++++++++++++++++++
	0x0001 INCLUDE_CONTENT: Information is transferred.		0x0001 INCLUDE_CONTENT: Information is transferred.
	Return value includes StringToSign.		Return value includes StringToSign.
	0x0002 INCLUDE_KEY_HASH: Return value includes		0x0002 INCLUDE_KEY_HASH: Return value includes the public key
	the public key hash value corresponding to the signature key.		hash value corresponding to the signature key.
	0x0004 INCLUDE_CERTIFICATE: Return value includes		0x0004 INCLUDE_CERTIFICATE: Return value includes the
	the certificate or the URL of the certificate. If the Browser cannot		certificate or the URL of the certificate. If the Browser cannot
	obtain the certificate, í—error:noCert" value must be returned.		obtain the certificate, "error:noCert" value must be returned.
	+++++++++++++++++++++++++++++++++++++++++++++++++
	íñKeyIdType = Integer
	++++++++++++++++++++++++++++++++++++++++++++++++		*KeyIdType = Integer
	value description		value description
	++++++++++++++++++++++++++++++++++++++++++++++++
	0 None:Used when Key Identifier is not used.		0 None:Used when Key Identifier is not used.
	1 User_Key_HASH: User public key hash value is		1 User_Key_HASH: User public key hash value is
	offered to the next parameter (keyId).		offered to the next parameter (keyId).
	2 TRUSTED_Key_HASH: The public key hash		2 TRUSTED_Key_HASH: The public key hash value of the
	value of the Trusted CA is offered to the next parameter (keyId).		Trusted CA is offered to the next parameter (keyId).
	++++++++++++++++++++++++++++++++++++++++++++++++		*keyId = String
	íñkeyId = String
	: Hash value defined in accordance with KeyIdType. For		: Hash value defined in accordance with KeyIdType. For
	instance, SHA-1 public key hash value is 20 bytes.		instance, SHA-1 public key hash value is 20 bytes.
	B.3 Return value		B.3 Return value
	íñReturn value = String or Invalid		*Return value = String or Invalid
	: If the return value is without errors, it is the base-64		: If the return value is without errors, it is the base-64
	[RFC1521] encoding of SignedContent.		[RFC1521] encoding of SignedContent.
	Appendix C. Response to certification request format		Appendix C. Response to certification request format
	C.1 Success		C.1 Success
	íš MIME Type : application/vnd.wap.cert-response		* MIME Type : application/vnd.wap.cert-response
	íš Content : Base64-encoded CertResponse		* Content : Base64-encoded CertResponse
	enum { cert_info(0), cert(1), referral(2), (255) } CertRespType;		enum { cert_info(0), cert(1), referral(2), (255) } CertRespType;
	struct {		struct {
	CharacterSet character_set;		CharacterSet character_set;
	opaque displayName <1 .. 2^8 - 1>;		opaque displayName <1 .. 2^8 - 1>;
	} CertDisplayName;		} CertDisplayName;
	struct {		struct {
	opaque url <0 .. 128>;		opaque url <0 .. 128>;
	skipping to change at page 10, line 4 ¶		skipping to change at page 10, line 22 ¶
	enum { cert_info(0), cert(1), referral(2), (255) } CertRespType;		enum { cert_info(0), cert(1), referral(2), (255) } CertRespType;
	struct {		struct {
	CharacterSet character_set;		CharacterSet character_set;
	opaque displayName <1 .. 2^8 - 1>;		opaque displayName <1 .. 2^8 - 1>;
	} CertDisplayName;		} CertDisplayName;
	struct {		struct {
	opaque url <0 .. 128>;		opaque url <0 .. 128>;
	} UrlPoint;		} UrlPoint;
	struct {		struct {
	unit8 version;		unit8 version;
	CertRespType type;		CertRespType type;
	select (type) {		select (type) {
	case cert_info:		case cert_info:
	CertDisplayName display_name;		CertDisplayName display_name;
	Identifier ca_domain;		Identifier ca_domain;
	UrlPoint url;		UrlPoint url;
	case cert:		case cert:
	CertDisplayName display_name;		CertDisplayName display_name;
	Identifier ca_domain;		Identifier ca_domain;
	X509Certificate cert;		X509Certificate cert;
	case referral:		case referral:
	UrlPoint url;		UrlPoint url;
	unit32 seconds_to_wait;		unit32 seconds_to_wait;
	}		}
	} CertResponse;		} CertResponse;
	C.2 Fail		C.2 Fail
	íš MIME Type : text/plain		* MIME Type : text/plain
	íš Content : Error message of ascii text value		* Content : Error message of ascii text value
	Appendix D. Structure of PK(Public Key)		Appendix D. Structure of PK(Public Key)
	enum { rsa(2), ecdh(3), ecdsa(4), (255) } PublicKeyType ;		enum { rsa(2), ecdh(3), ecdsa(4), (255) } PublicKeyType ;
	struct {		struct {
	PublicKeyType publicKeyType;		PublicKeyType publicKeyType;
	select (publicKeyType) {		select (publicKeyType) {
	case ecdh : ECPublicKey ;		case ecdh : ECPublicKey ;
	case ecdsa : ECPublicKey ;		case ecdsa : ECPublicKey ;
	case rsa : RSAPublicKey ;		case rsa : RSAPublicKey ;
	skipping to change at page 11, line 4 ¶		skipping to change at page 11, line 16 ¶
	enum { rsa(2), ecdh(3), ecdsa(4), (255) } PublicKeyType ;		enum { rsa(2), ecdh(3), ecdsa(4), (255) } PublicKeyType ;
	struct {		struct {
	PublicKeyType publicKeyType;		PublicKeyType publicKeyType;
	select (publicKeyType) {		select (publicKeyType) {
	case ecdh : ECPublicKey ;		case ecdh : ECPublicKey ;
	case ecdsa : ECPublicKey ;		case ecdsa : ECPublicKey ;
	case rsa : RSAPublicKey ;		case rsa : RSAPublicKey ;
	} ;		} ;
	} PublicKey ;		} PublicKey ;
	struct {		struct {
	opaque url <0 .. 128>;		opaque url <0 .. 128>;
	} UrlPoint;		} UrlPoint;
	struct {		struct {
	opaque rsa_exponent<1..2^16-1> ;		opaque rsa_exponent<1..2^16-1> ;
	opaque rsa_modulus<1..2^16-1> ;		opaque rsa_modulus<1..2^16-1> ;
	} RSAPublicKey ;		} RSAPublicKey ;
	enum { ECunNamed(0), ECNamed(1), implicitlyCA(2), (255) }		enum { ECunNamed(0), ECNamed(1), implicitlyCA(2), (255) }
	ECNameType;		ECNameType;
	struct {		struct {
	ECNameType ecNameType;		ECNameType ecNameType;
	select (ecNameType) {		select (ecNameType) {
	case ECunNamed :		case ECunNamed :
	ECParameters ecParameters;		ECParameters ecParameters;
	case ECNamed :		case ECNamed :
	opaque oid<1..2^8-1> ;		opaque oid<1..2^8-1> ;
	case implicitlyCA :		case implicitlyCA :
	struct { };		struct { };
	} ;		} ;
	opaque public_key_point<1..2^8-1> ;		opaque public_key_point<1..2^8-1> ;
	} ECPublicKey ;		} ECPublicKey ;
	enum { ec_prime_p(1), ec_characteristic_two(2), (255) } ECFieldID;		enum { ec_prime_p(1), ec_characteristic_two(2), (255) } ECFieldID;
	enum { ec_basis_onb(1), ec_basis_trinomial(2),		enum { ec_basis_onb(1), ec_basis_trinomial(2),
	ec_basis_pentanomial(3), ec_basis_polynomial(4) } ECBasisType;		ec_basis_pentanomial(3), ec_basis_polynomial(4) } ECBasisType;
	skipping to change at page 12, line 22 ¶		skipping to change at page 13, line 4 ¶
	uint16 k3;		uint16 k3;
	case ec_basis_polynomial:		case ec_basis_polynomial:
	opaque irreducible <1..2^8-1>		opaque irreducible <1..2^8-1>
	};		};
	};		};
	ECCurve curve;		ECCurve curve;
	ECPoint base;		ECPoint base;
	opaque order <1..2^8-1>;		opaque order <1..2^8-1>;
	opaque cofactor <1..2^8-1>;		opaque cofactor <1..2^8-1>;
	} ECParameters;		} ECParameters;
			Appendix E. ASN.1 Notes
	Appendix E. Author Addresses:		This ASN.1 syntax is just an example. Our wireless certificate request
			may be presented this way. The ID and Password which are given to
			subscribers through out-of-band (ex. visit) are put to 'certReqId' and
			'K' in HMAC. This ASN.1 syntax is based on RFC2511bis.
	Jaeil Lee		E.1. CertReqMessage Syntax
			CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
			CertReqMsg ::= SEQUENCE {
			certReqId INTEGER,
			-- endowed ID to subscriber
			pop ProofOfPossession,
			-- content depends upon key type }
			E.2. Proof of Possession Syntax
			ProofOfPossession ::= CHOICE {
			signature [0] EXPLICIT POPOSigningKey,
			keyDistribution [1] EXPLICIT POPOPrivKey }
			POPOSigningKey ::= SEQUENCE {
			poposkInput [0] EXPLICIT POPOSigningKeyInput,
			algorithmIdentifier AlgorithmIdentifier,
			signature BIT STRING }
			POPOSigningKeyInput ::= SEQUENCE {
			publicKeyMAC PKMACValue,
			publicKey SubjectPublicKeyInfo
			-- publicKey info is not defined in this document,
			-- but you can find the related information at
			-- draft-ietf-pkix-ipki-pkalgs-05.txt
			}
			PKMACValue ::= SEQUENCE {
			algId AlgorithmIdentifier,
			value BIT STRING }
			POPOPrivKey ::= CHOICE {
			subsequentMessage [0] EXPLICIT SubsequentMessage,
			dhMAC [1] EXPLICIT BIT STRING }
			SubsequentMessage ::= INTEGER {
			encrURL (0),
			-- requests that resulting cert URL be encrypted for the
			-- end entity (following which, POP will be proven in a
			-- confirmation message. see appendix C)
			challengeResp (1) }
			-- requests that CA/RA engage in challenge-response
			-- exchange with end entity in order to prove private key
			-- possession.
			It is expected that protocols which incorporate this specification
			will include the confirmation and challenge-response messages
			necessary to a complete protocol.
			E.2.1 Use of Password-Based MAC
			PBMParameter ::= SEQUENCE {
			salt OCTET STRING,
			owf AlgorithmIdentifier,
			-- AlgId for a One-Way Function (SHA-1 recommended)
			iterationCount INTEGER,
			-- number of times the OWF is applied
			mac AlgorithmIdentifier
			-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
			} -- or HMAC [RFC2104, RFC2202])
			publicKeyMAC = Hash( K XOR opad, Hash( K XOR ipad, public key) )
			where ipad and opad are defined in [RFC2104].
			The AlgorithmIdentifier for owf SHALL be SHA-1 {1 3 14 3 2 26} and
			for mac SHALL be HMAC-SHA1 {1 3 6 1 5 5 8 1 2}.
			Appendix F. Considerations
			As mentioned in introduction, because the mobile environment is limited,
			RFC2511 can not be used there. Thus, if possible to reduce the PKI
			module and data size, most of functions are omitted except core ones
			which can preserve message integrity and entity authentication and
			proof of possession. ASN.1 which can be ported in mobile devices is
			comparatively big and slow. Usual cert request message format size is
			around 600 bytes. But ours are around 200 bytes, a third smaller than
			RFC2511 and PKCS#10. And no additional run-time libraries are needed.
			Although we tested ASN.1 encoder and decoder at mobile device, WTLS
			encoding method is more efficient and effective. PDAs and other handheld
			equipments can be afford ASN.1, but still weigh on mobile phone compared
			with WTLS one at the moment.
			Here are our test equipments;
			1. Test phone A
			Device model : Samsung A-5000
			CPU : msm3100
			Clock : 13.5Mhz
			Memory : 2M (RAM), 4M(ROM)
			OS : REX
			Compiler : Arm2.5 compiler
			Browser : Mobile Explorer (KS1.2 - optimized by Korean vendor)
			2. Test phone B
			Device model : Nokia 8887
			CPU : msm3100
			Clock : 13.5Mhz
			Memory : 2M (RAM), 4M(ROM)
			OS : REX
			Compiler: Arm compiler
			Browser: WAP
			Appendix G. Author Addresses:
			Hongsub Lee
	78, Garak-dong, Songpa-Gu, Seoul, Korea, 138-803		78, Garak-dong, Songpa-Gu, Seoul, Korea, 138-803
	Korea Information Security Agency		Korea Information Security Agency
			E-Mail: hslee@kisa.or.kr
			Jaeil Lee
			Korea Information Security Agency
	E-Mail: jilee@kisa.or.kr		E-Mail: jilee@kisa.or.kr
	Young Lee		Young Lee
	Korea Information Security Agency		Korea Information Security Agency
	E-Mail: ylee@kisa.or.kr		E-Mail: ylee@kisa.or.kr
	Chanju Chung		Chanjoo Chung
	Korea Information Security Agency		Korea Information Security Agency
	E-Mail: cjchung@kisa.or.kr		E-Mail: cjchung@kisa.or.kr
	Jaeho Yoon		Jaeho Yoon
	Korea Information Security Agency		Korea Information Security Agency
	E-Mail: jhyoon@kisa.or.kr		E-Mail: jhyoon@kisa.or.kr
End of changes. 51 change blocks.
	114 lines changed or deleted		219 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/