공인인증서 요청형식 프로토콜 규격 Accredited Certificate Request Message Format Specification v1.21 2009년 9월
목 차 1. 개요 1 2. 규격의 구성 및 범위 1 3. 관련 표준 및 규격 1 3.1 국외 표준 및 규격 1 3.2 국내 표준 및 규격 2 3.3 기타 2 4. 정의 2 4.1 전자서명법 용어 정의 2 4.2 용어의 정의 2 4.3 용어의 효력 3 5. 약어 3 6. 유선 공인인증서비스에서의 공인인증서 요청형식 3 6.1 온라인 요청 형식 3 6.2 오프라인 요청형식 6 7. 무선 공인인증서비스에서의 공인인증서 요청형식 7 7.1 무선 공인인증서 관리형식 타입 스트링 및 인코딩 규칙 7 7.2 온라인 요청 형식 7 7.3 오프라인 요청 형식 9 부록 1. VID 및 EVID 구조 10 부록 부록 부록 2. PK(Public Key) 의 구조 12 3. 인증서 요청에 대한 응답형식 14 4. 규격 연혁 16
공인인증서 요청형식 프로토콜 규격 Accredited Certificate Request Message Format Specification 1. 개요 본 규격에서는 전자서명법에 따라 구축된 공인전자서명인증체계 공인인증서 비스에서 사용되는 유무선 공인인증서 요청형식을 규정한다. 2. 규격의 구성 및 범위 본규격은 [RFC2511], [WAPWPKI] 등국제표준을준수하여, 국내공인전자 서명인증체계 내에서 사용되는 유 무선 공인인증서 요청 메시지 형식을 정의한다. 첫번째로제장에서는유선공인인증서비스에서의온오프라인인증서요청형식 6 을 정의한다. 두번째로제장에서는무선공인인증서비스에서의온오프라인인증서요청형식을 7 정의한다. 3. 관련 표준 및 규격 3.1 국외 표준 및 규격 [RFC2119] [RFC2510] [RFC2511] [WAPWPKI] [WAPWTLS] IETF RFC 2119 (1997), Key Words for use in RFCs to Indicate Requirement Levels IETF RFC 2510 (1999), Internet X.509 Public Key Infrastructure Certificate Management Protocol IETF RFC 2511 (1999), Internet X.509 Certificate Request Message Format WAP Forum Approved Version 24-April-2001, WAP-217-WPKI, : Wireless Application Protocol Public Key Infrastructure Definition WAP Forum Approved Version 6-April-2001, Wireless -1-
[PKCS10] Transport Layer Security RSA Laboratories PKCS#10 v1.7 (2000), CertificationRequest SyntaxStandard 3.2 국내 표준 및 규격 [KCAC.TS.RS] [KCAC.TS.SIVID] [KCAC.TS.E2E] KISA, KCAC.TS.RS, v1.11, 공인인증서 발급을 위한 참조 번호/ 인가코드 기술규격, 2009 KISA, KCAC.TS.SIVID, v1.21, 식별번호를 이용한 본인확 인기술규격, 2009 KISA, KCAC.TS.E2E, v1.30, 무선 응용계층 보안 프로토 콜기술규격, 2003 [KCAC.TS.DSIG] KISA, KCAC.TS.DSIG, v1.30, 전자서명 알고리즘 규격, 2009 3.3 기타 해당사항 없음 4. 정의 본규격에서사용하는용어의정의는제장에서정한것을제외하고는관련 4 법령 등이 정하는 바에 의한다. 4.1 전자서명법 용어 정의 본규격에서사용된다음의용어들은전자서명법및동법시행령, 공인인증기관의 시설 및 장비 등에 관한 규정( 행정안전부 고시) 에 정의되어 있다. 가) 나) 다) 공인인증서 공인인증기관 가입자 4.2 용어의 정의 가) 유선 공인인증서비스 : 인터넷 기반의 전자거래를 위해 공인인증서를 이용하는 서비스 -2-
4.3 나) 무선 공인인증서비스 : 무선 단말기 기반의 전자거래를 위해 공인인증서를 이용하는 서비스 다) 개인키 소유여부 검증정보 : 인증서 요청정보에 포함된 공개키가 용어의 효력 대응되는 개인키를 가입자가 소유하고 있음을 증명하기 위한 정보 본 규격에서 사용된 다음의 용어들은 전자서명인증체계 공인인증서 요청형식 프로토콜의 구현 정도를 의미하는 것으로 의미를 지닌다. 가) 해야한다, 필수이다, 강제한다 ( 기호 : M) 반드시 준수해야 한다. 나) 권고한다 ( 기호 : R) [RFC2119] 를 준용하며 다음과 같은 보안성 및 상호연동을 고려하여 준수할 것을 권장한다. 다) 할 수 있다, 쓸 수 있다 ( 기호 : O) 주어진 상황을 고려하여 필요한 경우에 한해 선택적으로 사용할 수 있다. 라) 권고하지 않는다 ( 기호 : NR) 보안성 및 상호연동을 고려하여 사용하지 말 것을 권장한다. 마) 금지한다, 허용하지 않는다 ( 기호 : X) 반드시 사용하지 않아야 한다. 바) 언급하지 않는다, 정의하지 않는다 ( 기호 : -) 준수 여부에 대해 기술하지 않는다. 5. 약어 본규격에서는다음의약어가이용된다. 가) CA : Certification Authority, 인증기관 나) RA : Registration Authority, 등록대행기관 6. 유선 공인인증서비스에서의 공인인증서 요청형식 6.1 온라인 요청형식 -3-
온라인 요청형식은 인증서 요청정보와 개인키 소유여부 검증정보 및 추가 등록 정보로 구성되며, 온라인 요청형식의 구성은 다음과 같다. CertReqMessage ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg CertReqMsg ::= SEQUENCE { certreq CertRequest, pop ProofOfPossession OPTIONAL, reginfo SEQUENCE SIZE (1..MAX) of AttributeTypeAndValue OPTIONAL} certreq 는인증서요청정보로인증서에포함될내용만을포함해야한다. pop는 가입자의 개인키 소유여부 검증정보로 가입자의 키가 전자서명키인 경우, 인증서 요청정보에 대한 서명값을 포함해야 한다. reginfo 는인증요청을위해추가적인등록정보가요구될때사용되는정보로, [KCAC.TS.SIVID] 에 따른 가입자 신원확인 정보 및 가입자의 접속 정보, 지불 정보 등이 포함될 수 있다. 6.1.1 인증서 요청정보 인증서 요청정보의 구성은 다음과 같다. CertRequest ::= SEQUENCE { certreqid INTEGER, certtemplate CertTemplate, controls Controls OPTIONAL } certreqid는 인증요청메시지와이에대응하는응답메시지를확인하기위해 사용되는 정보로, 대응되는 메시지간에 certreqid 값은 서로 동일해야 한다. certtemplate 는 [RFC2510] 에 따라 인증서 발급에 대한 가입자의 요청에 따른 각각의 정보를 포함하며, 다음과 같이 구성된다. CertTemplate ::= SEQUENCE { version [0] Version OPTIONAL, serialnumber [1] INTEGER OPTIONAL, signingalg [2] AlgorithmIdentifier OPTIONAL, -4-
issuer [3] Name OPTIONAL, validity [4] OptionalValidity OPTIONAL, subject [5] Name OPTIONAL, publickey [6] SubjectPublicKeyInfo OPTIONAL, issueruid [7] UniqueIdentifier OPTIONAL, subjectuid [8] UniqueIdentifier OPTIONAL, extensions [9] Extensions OPTIONAL } OptionalValidity ::= SEQUENCE { notbefore [0] Time OPTIONAL, notafter [1] Time OPTIONAL } control 은 인증서 발급에 영향을 주는 정보를 포함하는 것으로, regtoken, authenticator, pkipublicationinfo, oldcertid의 control 이 사용될 수 있다. Contorls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue regtoken control은 가입자의 신원을 확인하기 위한 일회성 정보를 가지며, 이 정보는 CA에서 생성할 수도 있고 out-of-band 로 가입자에게 제공될 수 있다. 이 control 은 PKI 서비스에 신규 가입한 가입자에 대해서만 사용가능하며, UTF8으로 인코딩된다. authenticator control은 가입자의 신원을 확인하기 위해 CA와 가입자간에 공유된 가입자 정보의 일부가 포함될 수 있다. 이 control은 신규 가입자뿐만 아니라 기존 가입자들의 인증서 요청 시에도 사용될 수 있다. pkipublicationinfo control은 인증서공고방법및공고위치정보를포함한 것으로,control 의 형식은 [RFC2511] 을 준용한다. oldcertid control은 가입자의 기존 인증서가 가입자의 인증 요청 메시지에 포함된 정보로 갱신될 수 있도록 기존 인증서의 발급자 포함해야 한다.control 의 형식은 [RFC2511] 을 준용한다. DN과인증서일련번호를 6.1.2 개인키 소유여부 검증정보 가입자의 정당한 개인키 소유여부를 검증하기 위해 온라인 요청형식은 개인키 소유여부 검증정보를 포함해야 하며, 이 정보는 CA 혹은 RA에 의해 검증되 -5-
어야 한다. 인증기관의 정책에 따라 개인키 소유여부 정보를 증하는 경우, 이 필드는 사용되지 않는다. 개인키 소유여부 검증정보의 구성은 다음과 같다. ProofOfPossession ::= CHOICE { raverified signature keyencipherment [0] NULL, [1] POPOSigningKey, [2] POPOPrivKey, keyagreement [3] POPOPrivKey } out-of-band로 검 가입자의 전자서명생성키에 대한 소유여부 검증을 위한 정보는 포함되어야 하며, 다음과 같이 구성된다. signature에 POPOSigningKey ::= SEQUENCE { poposkinput algorithmidentifier [0] POPOSigningKeyInput OPTIONAL, AlgorithmIdentifier, signature BIT STRING } 인증서 요청 메시지의 CertTemplate 에 subject 와 publickey 가 포함되는 경우, poposkinput 필드는 생략될 수 있으며, signature 는인증서요청정보의 DER 인코딩 값에 대한 서명값을 가진다. 이에 반해, 인증서 요청 메시지의 CertTemplate에 subject와 publickey 가 없는 경우, poposkinput 필드는 반드시 존재해야 하며, 이 필드에 대해 DER 인코딩된 값을 signature 의 값으로 갖는다.poposkInput 필드는 다음과 같이 구성된다. POPOSigningKeyInput ::= SEQUENCE { authinfo CHOICE { sender [0] GeneralName, publickey PKMACValue}, publickey SubjectPublicKeyInfo } sender 필드는 인증서 요청자가 사전에 인증된 가입자인 경우에만 사용되며, 신규 가입자 등 사전에 인증되지 않은 가입자의 경우, publickeymac 필드가 사용된다. publickeymac 필드는 가입자의 공개키의 DER 인코딩 값에 대해 password-based MAC 을설정한다. 6.2 오프라인 요청형식 -6-
오프라인 요청형식은 [PKCS10] 을 준용하여야 한다. 7. 무선 공인인증서비스에서의 공인인증서 요청형식 7.1 무선 공인인증서 관리형식 타입 스트링 및 인코딩 규칙 본규격에서요청발급에따른해당타입을아래와같이정의하고 ( ), 3 스트링(String) 으로 표현한다. 바이트의 종 류 키분배 및 전자서명 전자서명 키분배 요청( 발급) 100 110 120 모든 바이너리 데이터는 base64 인코딩 규칙을 따라야 한다. 구분자는 버티칼 라인( ) 을 사용하지만, 해쉬 메시지의 concatenation시에 구분자를 사용하지 않아야 한다. 또한, 참조번호로 사용할 수 있는 문자의 범위에서 버티칼 라인( ) 은 제외해야 한다. 또한, 정의하고 있는 데이터를 등록기관( 또는 공인인증기관) 에게 전송할 때는 POST 방식을 사용해야 한다. 7.2 온라인 요청형식 온라인 요청형식은 공인인증서 생성을 위해 가입자가 공인인증기관( 또는 등록 기관을 통해) 에게 공인인증서 요청을 전달하는 메시지이다. 가입자는 일회성 정보( ID, 패스워드), POP 를 위한 방법, 가입자의 공개키( 전자 서명용 공인인증서인 경우에는 신원확인정보) 를 포함하는 요청형식을 생성하여 Replay attack, 메시지 위 변조 방지할 수 있는 요청형식을 구성하여 공인인증 기관( 또는 등록기관을 통해) 에 공인인증서 요청형식을 전달하여야 한다. 일회성 정보(ID, Passwd) 는 [KCAC.TS.RS] 를 준수하여 이용하고, 가입자가 공인인증서를 요청할 때에는 청형식을 생성한다. [KCAC.TS.E2E] 에서 정의한 signtext함수를 사용하여 인증서 요 -7-
o 전자서명용 또는 키분배용으로 요청하는 경우 가입자 등록기관( 또는 공인인증기관) nonce 생성 nonce R 생성 V ID = H ( H ( ID N,R )) EVID = E(VID R) M = type PK ID EVID N = Passwd SignedContent = signtext(m H ( M,N ), 1, 0, ) CR = SignedContent CR SignedContent = CR PK, ID 추출 및 SignedContent 검증 데이터베이스에서 Passwd 및 ID N' 추출 H' = H ( M,Passw d ) H'? = H ( M, N ) 키분배용 인증서를 발급 받는 경우에는 여기서 nonce는 사용하지 않음 VID R = D(EVID) V ID? = H ( H ( ID N', R )) EVID를 생략함 -8-
o 전자서명 및 키분배를 동시에 요청하는 경우 R 생성 가입자 V ID = H ( H ( ID N,R )) EVID = E(VID R) SignValue 키분배 는 nonce를 로 서명한 값 M = type PK ID PK 키분배 SK 키분배 nonce 등록기관( 또는 공인인증기관) nonce 생성 SignValue 키분배 nonce EVID N = Passwd SignedContent = signtext(m H ( M,N ), 1, 0, ) CR = SignedContent CR SignedContent = CR PK, ID 추출 및 SignedContent 검증 데이터베이스에서 Passwd 및 ID N' 추출 PK 키분배 로 SignValue 키분배 검증 H' = H ( M,Passw d ) H'? = H ( M, N ) VID R = D(EVID) V ID? = H ( H ( ID N', R )) nonce로서명생성후요청하는데걸리는시간은인증기관의정책에따라결정하고, 키분배용 ECDH키는 ECDSA 서명 생성하는 것으로 POP 확인함 등록기관( 또는 공인인증기관) 의 응답형식은 [ 부록 3] 에 정의한다. 7.3 오프라인 요청형식 오프라인 요청형식은 [PKCS10] 을 준용하여야 한다. -9-
부록 1. VID 및 EVID 구조 1.1 VID 구조 enum { SHA1(0), (255) } HashAlgorithm ; HashAlgorithm hash_alg ; opaque virtualid<0..2^8-1> ; }VID; // virtualid는 아래에 정의된 HashContent를 HashAlgorithm으로 2번 해쉬한 값이다. opaque opaque }HashContent; idn<0..2^8-1>; randomnum[20]; 1.2 EVID 구조 enum { RSA(0), (255) } EncryptionAlgorithm ; Identifier issuer; opaque serialnumber<0..2^8-1>; }IssuerAndSerialNumber; uint8 version ; HashAlgorithm vid_hash_alg ; EncryptionAlgorithm vid_encyption_alg ; -10-
}EVID; IssuerAndSerialNumber certid ; opaque encryptedvid<0..2^16-1> ; // encryptedvid는아래에정의된encryptioncontent 를암호화한값이다. VID vid ; opaque randomnum[20] ; }EncryptionContent; -11-
부록 2. PK(Public Key) 의 구조 enum { rsa(2), ecdh(3), ecdsa(4), (255) } PublicKeyType ; select (PublicKeyType) { case ecdh : ECPublicKey ; case ecdsa : ECPublicKey ; case rsa : RSAPublicKey ; } }PublicKey; opaque rsa_exponent<1..2^16-1> ; opaque rsa_modulus<1..2^16-1> ; }RSAPublicKey; enum { ECunNamed(0), ECNamed(1), (255) } ECNameType ; select (ECNameType) { case ECunNamed : ECParameters ; case ECNamed : opaque oid<1..2^8-1> ; } opaque point<1..2^8-1>; }ECPublicKey; ECNamed 에 포함되는 타원곡선암호화(ECC) 커브는 [KCAC.TS.DSIG] 를 따름 enum { ec_prime_p(1), ec_characteristic_two(2), (255) } ECFieldID; -12-
enum { ec_basis_onb(1), ec_basis_trinomial(2), ec_basis_pentanomial(3), ec_basis_polynomial(4) } ECBasisType; opaque a <1..2^8-1>; opaque b <1..2^8-1>; opaque seed <0..2^8-1>; }ECCurve; ECFieldID field; select (field) { case ec_prime_p: opaque prime_p <1..2^8-1>; case ec_characteristic_two: uint16 m; ECBasisType basis; select (basis) { case ec_basis_onb: }; case ec_trinomial: uint16 k; case ec_pentanomial: uint16 k1; uint16 k2; uint16 k3; case ec_basis_polynomial: opaque irreducible <1..2^8-1>; } } ECCurve curve; ECPoint base; opaque order <1..2^8-1>; opaque cofactor <1..2^8-1>; }ECParameters; ECParameters 구조에 대한 설명은 [WAPWTLS] 를 참조한다. -13-
부록 3. 인증서 요청에 대한 응답형식 3.1 성공(Success) MIME Type : application/vnd.wap.cert-response Content : Base64 인코딩된 CertResponse enum { cert_info(0), cert(1), referral(2), (255) } CertRespType; CharacterSet character_set; opaque displayname <1.. 2^8-1>; }CertDisplayName; }UrlPoint; opaque url <0.. 128>; unit8 version; CertRespType type; select (type) { case cert_info: CertDisplayName Identifier UrlPoint case cert: CertDisplayName Identifier X509Certificate case referral: UrlPoint unit32 } }CertResponse; display_name[2]; ca_domain[2]; url[2]; display_name[2]; ca_domain[2]; cert[2]; url[2]; seconds_to_wait[2]; -14-
각배열의첫번째는전자서명용, 두번째는키분배용관련정보이다. CertResponse 구조에 대한 설명은 [WAPWPKI] 를 참조한다. 3.2 실패(Fail) MIME Type : text/plain Content : ascii text 값의 에러 메시지 -15-
부록 4. 규격 연혁 버전 제개정일 제개정내역 v1.00 2004년 11월 공인인증서 요청형식 프로토콜 규격 으로 제정 v1.10 2007년 4월 무선 인증서 요청형식 프로토콜 규격 v1.32 흡수 통합 v1.20 2008년 10월 관련 국내 표준 및 규격 갱신 내용 반영 법률 공포번호가 해당 법률 개정시마다 변경되는 점을 고려하여 법령명으로 개정 v1.21 2009년 9월 관련 국내 표준 참조 오류 정정 -16-
규격 작성 공헌자 본규격의개정을위해아래와같이많은분들이공헌을하였습니다. 구분 성명 소속사 규격 제안 전자인증팀 한국인터넷진흥원 규격 초안 제출 전자인증팀 한국인터넷진흥원 규격 검토 백종현 이석래 박상환 임진수 이원철 박윤식 박순태 정성아 이성진 국상진 심재성 한국인터넷진흥원 한국인터넷진흥원 한국인터넷진흥원 한국인터넷진흥원 한국인터넷진흥원 한국인터넷진흥원 한국인터넷진흥원 금융결제원 한국증권전산 한국무역정보통신 드림시큐리티 규격안 편집 박상환 한국인터넷진흥원 -17-