テーマ：CACAnet福岡のリポジトリについて
発表者：桑山 雅行（CACAnet福岡）
最終修正：２００１年７月１２日
1. Status of this Memo
まだまだ「たたき台」の領域を越えていません．
こんなことを考えないといけないよね，という点をとりあえず挙げてみたというレベルです．
Table of Contents
1. Status of this Memo
2. 適用範囲
3. 概要
4. リポジトリの仕様
4.1 概要
4.2 naming context
4.3 schema
4.3.1 オブジェクトクラス
4.3.1.1 証明書を格納するエントリのオブジェクトクラス
4.3.1.2 CRLを格納するエントリのオブジェクトクラス
4.3.2 属性
4.3.2.1 証明書を格納する属性
4.3.2.2 CRLを格納する属性
5. 登録側へのインターフェイス仕様
5.1 概要
5.2 Bind操作
5.3 Search操作
5.4 Add操作
5.5 Modify操作
5.6 Unbind操作
5.7 アクセス制御
6. リポジトリからの取得のためのインタフェース仕様
6.1 取得処理の概要
6.2 証明書の取得
6.2.1 DNがわかっている場合
6.2.2 DNがわかっていない場合
6.3 CRLの取得
6.4 アクセス制御
7. Security Considerations
8. Acknowledgments
9. 参考文献
10. 著者のアドレス
2. 適用範囲
この文書は，「個人証明書発行手続き5.8.doc」[1]に基づき個人証明書を発行し利用する場合に，
CACAnet福岡のリポジトリを証明書およびCRLの配布点として用いる場合に適用する．
＃サーバ証明書など他の証明書の配布点として用いる場合，
＃セッション管理など他のサービスに利用する場合，
＃などについては，別途定める仕様書による．
＃また，証明書の有効期限が切れた場合や廃棄された場合，新しい証明書が発行された
＃場合などに，リポジトリに登録されている証明書をどうするかといったことについても
＃ここでは触れない．
3. 概要
この文書では，「個人証明書発行手続き5.8.doc」で述べられている，
「リポジトリへの証明書登録」処理を実現するために，
大きく次の二つのことについて述べている．
・リポジトリの仕様
・リポジトリへの登録処理を行うための，登録側へのインタフェース仕様
また，その後の利用のために，
・リポジトリからの取得処理を行うための，ユーザ側へのインターフェース仕様
についても述べる．
＃これらは，つまり，リポジトリを実現するためのOpenLDAPの設定と，
＃リポジトリにアクセスするためのrubyプログラムの仕様となる．
4. リポジトリの仕様
4.1 概要
ここでは，リポジトリの仕様として，
・naming context
・schema
の2項目について規定する．
基本方針としては，
RFC2587 Internet X.509 Public Key Infrastructure: LDAPv2
Schema[3],
draft-ietf-pkix-ldap-schema-01.txt Internet X.509 Public Key
Infrastructure: Additional LDAP Schema for PKIs and PMIs[4],
RFC2256 A Summary of the X.500(96) User Schema for use with
LDAPv3[5],
RFC2252 Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions[6],
RFC2798 Definition of the inetOrgPerson LDAP Object Class[7]
に従うものにする．
4.2 naming context
CACAnet福岡のリポジトリでは，ユーザ証明書は，証明書に書かれたDNと同じDNのディレクトリエントリに登録されるものとする．
つまり，CACAnet福岡のCPS[2]の「3.1.1 名前の種類」より，
E=(ユーザのe-mailアドレス),CN=(ユーザの氏名),OU=User,O=CACAnet Fukuoka,C=JP
となる．
CRLは，CACAnet福岡のCAを表すエントリ「・・・,O=CACAnet,c=JP」に登録されるものとする．
4.3 schema
4.3.1 オブジェクトクラス
4.3.1.1 証明書を格納するエントリのオブジェクトクラス
RFC2587より
pkiUser OBJECT-CLASS ::= {
SUBCLASS OF { top}
KIND
auxiliary
MAY CONTAIN {userCertificate}
ID joint-iso-ccitt(2) ds(5) objectClass(6)
pkiUser(21)}
pkiCA OBJECT-CLASS ::= {
SUBCLASS OF { top}
KIND
auxiliary
MAY CONTAIN {cACertificate |
certificateRevocationList |
authorityRevocationList |
crossCertificatePair }
ID joint-iso-ccitt(2) ds(5) objectClass(6)
pkiCA(22)}
RFC2256より
7.16. strongAuthenticationUser
( 2.5.6.15 NAME 'strongAuthenticationUser' SUP top AUXILIARY
MUST userCertificate )
7.17. certificationAuthority
( 2.5.6.16 NAME 'certificationAuthority' SUP top AUXILIARY
MUST ( authorityRevocationList $
certificateRevocationList $
cACertificate ) MAY crossCertificatePair )
RFC2798より
( 2.16.840.1.113730.3.2.2
NAME 'inetOrgPerson'
SUP organizationalPerson
STRUCTURAL
MAY (
audio $ businessCategory $
carLicense $ departmentNumber $
displayName $ employeeNumber $
employeeType $ givenName $
homePhone $ homePostalAddress $
initials $ jpegPhoto $
labeledURI $ mail $ manager $ mobile
$ o $ pager $
photo $ roomNumber $ secretary $ uid
$ userCertificate $
x500uniqueIdentifier $ preferredLanguage
$
userSMIMECertificate $ userPKCS12
)
)
4.3.1.2 CRLを格納するエントリのオブジェクトクラス
RFC2587より
pkiCA OBJECT-CLASS ::= {
SUBCLASS OF { top}
KIND
auxiliary
MAY CONTAIN {cACertificate |
certificateRevocationList |
authorityRevocationList |
crossCertificatePair }
ID joint-iso-ccitt(2) ds(5) objectClass(6)
pkiCA(22)}
cRLDistributionPoint OBJECT-CLASS::= {
SUBCLASS OF { top }
KIND
structural
MUST CONTAIN { commonName }
MAY CONTAIN { certificateRevocationList
|
authorityRevocationList |
deltaRevocationList }
ID joint-iso-ccitt(2) ds(5) objectClass(6) cRLDistributionPoint(19)
}
RFC2256より
7.17. certificationAuthority
( 2.5.6.16 NAME 'certificationAuthority' SUP top AUXILIARY
MUST ( authorityRevocationList $
certificateRevocationList $
cACertificate ) MAY crossCertificatePair )
7.20. certificationAuthority-V2
( 2.5.6.16.2 NAME 'certificationAuthority-V2' SUP
certificationAuthority
AUXILIARY MAY ( deltaRevocationList ) )
7.21. cRLDistributionPoint
( 2.5.6.19 NAME 'cRLDistributionPoint' SUP top STRUCTURAL
MUST ( cn ) MAY ( certificateRevocationList $
authorityRevocationList $
deltaRevocationList ) )
4.3.2 属性
4.3.2.1 証明書を格納する属性
RFC2587より
userCertificate ATTRIBUTE ::= {
WITH SYNTAX Certificate
EQUALITY MATCHING RULE
certificateExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4)
userCertificate(36) }
cACertificate ATTRIBUTE ::= {
WITH SYNTAX Certificate
EQUALITY MATCHING RULE
certificateExactMatch
ID joint-iso-ccitt(2) ds(5) attributeType(4)
cACertificate(37) }
RFC2256より
5.37. userCertificate
This attribute is to be stored and requested in the binary form,
as
'userCertificate;binary'.
( 2.5.4.36 NAME 'userCertificate'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
5.38. cACertificate
This attribute is to be stored and requested in the binary form,
as
'cACertificate;binary'.
( 2.5.4.37 NAME 'cACertificate'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
RFC2798より
( 2.16.840.1.113730.3.1.40
NAME 'userSMIMECertificate'
DESC 'PKCS#7 SignedData used to support S/MIME'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
4.3.2.2 CRLを格納する属性
RFC2587より
certificateRevocationListATTRIBUTE::={
WITH SYNTAX
CertificateList
EQUALITY MATCHING
RULE certificateListExactMatch
ID joint-iso-ccitt(2) ds(5)
attributeType(4)
certificateRevocationList(39)}
RFC2256より
5.40. certificateRevocationList
This attribute is to be stored and requested in the binary form,
as
'certificateRevocationList;binary'.
( 2.5.4.39 NAME 'certificateRevocationList'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
5. 登録側へのインターフェイス仕様
5.1 概要
リポジトリへの登録処理は，
1. Bind
2. 証明書を登録しようとするDNが存在するかどうかのSearch操作による確認
3-a. 存在しない場合には，Add
3-b. 存在する場合には，Modify
4. Unbind
という流れとなる．
そのために，これらの操作に必要な要素を規定する必要がある．
また，各操作を行った場合のリターンコードおよびアクセス制御についても述べる．
なお，
RFC2559[8]
raft-ietf-pkix-ldap-v3-03.txt[9]
をベースに考える．
5.2 Bind操作
5.2.1 BindRequest
BindRequestはRFC2251[10]において，次のように規定されている．
BindRequest ::= [APPLICATION 0]
SEQUENCE {
version
INTEGER (1 .. 127),
name
LDAPDN,
authentication
AuthenticationChoice }
AuthenticationChoice ::= CHOICE {
simple
[0] OCTET STRING,
-- 1 and 2 reserved
sasl
[3] SaslCredentials }
SaslCredentials ::= SEQUENCE {
mechanism
LDAPString,
credentials
OCTET STRING OPTIONAL }
CACAnet福岡リポジトリでは，これらの要素を以下のように使用する．
・version
LDAPv3を用いることとし，「3」とする．
・name
"cn=manager,o=CACAnet,c=JP"
・authentication
simpleではなくsaslを用いることとする．
・mechanism
SASLメカニズムとしては，
・PLAIN
・CRAM-MD5
・DIGEST-MD5
・KERBEROS_V4
・GSSAPI
等があるが，xxxを採用する．
・credentials
秘密
5.2.2 BindResponse
BindResponse ::= [APPLICATION 1]
SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
LDAPResultは，同じくRFC2251の 4.1.10. Result Message で次のように規定されている．
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success
(0),
operationsError
(1),
protocolError
(2),
timeLimitExceeded
(3),
sizeLimitExceeded
(4),
compareFalse
(5),
compareTrue
(6),
authMethodNotSupported (7),
strongAuthRequired
(8),
-- 9 reserved --
referral
(10), -- new
adminLimitExceeded
(11), -- new
unavailableCriticalExtension (12), -- new
confidentialityRequired (13), -- new
saslBindInProgress
(14), -- new
noSuchAttribute
(16),
undefinedAttributeType (17),
inappropriateMatching (18),
constraintViolation (19),
attributeOrValueExists (20),
invalidAttributeSyntax (21),
-- 22-31 unused --
noSuchObject
(32),
aliasProblem
(33),
invalidDNSyntax
(34),
-- 35 reserved for undefined isLeaf --
aliasDereferencingProblem (36),
-- 37-47 unused --
inappropriateAuthentication (48),
invalidCredentials
(49),
insufficientAccessRights (50),
busy
(51),
unavailable
(52),
unwillingToPerform
(53),
loopDetect
(54),
-- 55-63 unused --
namingViolation
(64),
objectClassViolation (65),
notAllowedOnNonLeaf (66),
notAllowedOnRDN
(67),
entryAlreadyExists
(68),
objectClassModsProhibited (69),
-- 70 reserved for CLDAP --
affectsMultipleDSAs (71),
-- new
-- 72-79 unused --
other
(80) },
-- 81-90 reserved for APIs --
matchedDN LDAPDN,
errorMessage LDAPString,
referral [3] Referral OPTIONAL }
○○の場合にはxxを返す．
△△の場合にはyyを返す．
□□の場合にはzzを返す．
5.3 Search操作
5.3.1 SearchRequest
SearchRequestはRFC2251において，次のように規定されている．
SearchRequest ::= [APPLICATION 3]
SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject
(0),
singleLevel
(1),
wholeSubtree
(2) },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways
(3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeDescriptionList }
Filter ::= CHOICE {
and [0]
SET OF Filter,
or
[1] SET OF Filter,
not [2]
Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7]
AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion }
SubstringFilter ::= SEQUENCE {
type
AttributeDescription,
-- at least one must be present
substrings SEQUENCE OF CHOICE {
initial [0] LDAPString,
any [1] LDAPString,
final [2] LDAPString } }
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2]
AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
5.3.2 Search Result
SearchRequestに対しては，他の操作と同じようにSearchResponseというものが返されるわけではなく，
SearchResultEntry，SearchResultDone，SearchResultReferenceのいずれかが返される．
SearchResultEntry ::= [APPLICATION
4] SEQUENCE {
objectName LDAPDN,
attributes PartialAttributeList }
PartialAttributeList ::= SEQUENCE OF
SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
-- implementors should note that the
PartialAttributeList may
-- have zero elements (if none of
the attributes of that entry
-- were requested, or could be
returned), and that the vals set
-- may also have zero elements (if
types only was requested, or
-- all values were excluded from the
result.)
SearchResultReference ::=
[APPLICATION 19] SEQUENCE OF LDAPURL
-- at least one LDAPURL element must
be present
SearchResultDone ::= [APPLICATION 5]
LDAPResult
5.4 Add操作
5.4.1 AddRequest
AddRequestはRFC2251において，次のように規定されている．
AddRequest ::= [APPLICATION 8]
SEQUENCE {
entry LDAPDN,
attributes AttributeList }
AttributeList ::= SEQUENCE OF
SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
CACAnet福岡リポジトリでは，これらの要素を以下のように使用する．
entry
証明書を登録する個人を表すディレクトリエントリのDN．
User証明書の場合には，
E=(ユーザのe-mailアドレス),CN=(ユーザの氏名),OU=User,O=CACAnet Fukuoka,C=JP
となる．
5.4.2 AddResponse
5.5 Modify操作
5.5.1 ModifyRequest
ModifyRequestはRFC2251において，次のように規定されている．
ModifyRequest ::= [APPLICATION 6]
SEQUENCE {
object LDAPDN,
modification SEQUENCE OF SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues } }
AttributeTypeAndValues ::= SEQUENCE
{
type AttributeDescription,
vals SET OF AttributeValue }
CACAnet福岡リポジトリでは，これらの要素を以下のように使用する．
・object
証明書を登録するDNである．
CACAnet福岡のリポジトリでは，証明書のDNと同じにする．
・modification
証明書を登録する操作であるので，add(0)となる．
・type
証明書なので，certificateを用いる(;binary?)．
・vals
生成された証明書が入る．
5.5.2 ModifyResponse
5.6 Unbind操作
UnbindRequestはRFC2251において，次のように規定されている．
UnbindRequest ::= [APPLICATION 2]
NULL
UnbindRequestには規定する必要のある要素は無い．
5.7 アクセス制御
RA Serverのみが登録可能
6. リポジトリからの取得のためのインタフェース仕様
6.1 取得処理の概要
リポジトリからの取得処理には，
・証明書の取得
・CRLの取得
の２通りがある．
6.2 証明書の取得
リポジトリから証明書を検索する場合の処理には，
・取得しようとする証明書が格納されているディレクトリエントリのDNがわかっている場合
・取得しようとする証明書が格納されているディレクトリエントリのDNはわからないが，
取得しようとする証明書のsubjectの電子メイルアドレス等の情報がわかっている場合．
の２通りがある．
6.2.1 DNがわかっている場合
6.2.2 DNがわかっていない場合
DNはわからないが証明書を取得したい場合というのは，
例えば，暗号化メイルを送りたい相手のメイルアドレスはわかっているが，
DNはわからない，というような場合である．
6.3 CRLの取得
6.4 アクセス制御
誰でも可能(anonymousでも可)．
7. Security Considerations
8. Acknowledgments
9. 参考文献
[1] 「個人証明書発行手続き5.8.doc」, CACAnet福岡
[2] 「CACAnet福岡 Class A CA CPS 第1.0版」
[3] RFC2587 Internet X.509 Public Key Infrastructure:
LDAPv2 Schema
[4] draft-ietf-pkix-ldap-schema-01.txt
Internet X.509 Public Key Infrastructure
Additional LDAP Schema for PKIs and PMIs
[5] RFC2256 A Summary of the X.500(96) User Schema for
use with LDAPv3
[6] RFC2252 Lightweight Directory Access Protocol
(v3):
Attribute Syntax Definitions
[7] RFC2798 Definition of the inetOrgPerson LDAP
Object Class
[8] RFC2559 Internet X.509 Public Key Infrastructure
Operational Protocols - LDAPv2
[9] draft-ietf-pkix-ldap-v3-03.txt
Internet X.509 Public Key Infrastructure
Operational Protocols - LDAPv3
[10] RFC2251 Lightweight Directory Access Protocol
(v3)
10. 著者のアドレス
桑山 雅行(くわやま まさゆき)
CACAnet福岡
E-mail: kuwayama@cacanet.org