WPCL 2BJ|x H   X  6p&6p& I  Hh   c4 P  Fascicle VIII.8 Rec. X.518 PAGE1 ~  HH   c4 P PAGE16 Fascicle VIII.8 Rec. X.518 ~ Hh Hp P X`h!(# X  Ё c4 P  The drawings contained in this Recommendation have been done in AUTOCAD  HP X`h!(# H18.6.5 Find naming context procedure HP X`h!(#HH18.6.5.1Introduction  H Hp P X`h!(# Figure 8/X.518 shows this procedure in the form of a diagram. Below is a textual description. In this it is assumed that the current value of Operation Progress is always returned upon exit of the procedure. HP X`h!(#HH18.6.5.2Arguments Hp P X`h!(# The procedure makes use of the following arguments:   pthe target object name (the purported name);   poperation progress.  HH HP X`h!(#HH18.6.5.3Results Hp P X`h!(# There are two cases of successful outcome.  The first of these returns:   pa reference;   poperation progress (updated appropriately).  The second of these returns:  H   pan indication that a suitable naming context was found locally;   poperation progress (updated appropriately).  HH HP X`h!(#HH18.6.5.4Errors Hp P X`h!(# One of the following errors may be returned:   p ServiceError (unableToProceed);   p ServiceError (invalidReference). HP X`h!(#HH18.6.5.5Procedure  H Hp P X`h!(#  1)pIf nameResolutionPhase is set to completed on entry, attempt to match the purported name against the context prefixes of the superior naming contexts of all the locally held naming contexts. If a match is found, return all the appropriate locally held naming contexts. If no match is found, return an invalidReference ServiceError .  H   2)pIf nameResolutionPhase is not set to completed , attempt to match context prefixes against a sequence of one or more RDNs in the initial portion of the purported name. For a match to be found, all RDNs in a context prefix must be matched. The context prefixes used are those of Naming Contexts for which this DSA has administrative authority. In case of multiple matches the one with the maximum number of matched RDNs is chosen.  If a match is found, execute (3).  If a match is not found, execute (5).  H   3)pIf nameResolutionPhase is notStarted , execute (4). If the number of RDNs in the initial portion of the purported name, matched as described in (2) above, is greater or equal to the nextRDNToBeResolved component of OperationProgress , then execute (4), otherwise execute (9).  H   4)pThe nextRDNToBeResolved is set to the number of matched RDNs plus 1 and the nameResolutionPhase is set to Proceeding . The context is returned and this procedure terminated.  Hh  As a performance enhancement, the DSA may optionally match the purported name against the cross references held by the DSA. If more RDNs are matched against a cross reference than against the locally held context prefixes, then execute step (7).  H  Note ĩ The Name Resolution procedure will in case of this outcome call the Local Name Resolution.  H   5)pIf no match was found, the value of the nameResolutionPhase is checked. If the nameResolutionPhase is notStarted , execute (6).  If the nameResolutionPhase is proceeding or completed , then execute(9).  H   6)pUsing Cross Reference context prefixes, attempt to match against a sequence of one or more RDNs in the initial portion of the purported name. In case of multiple matches, the one with the maximum number of matched RDNs is chosen.  H   7)pIf a match was found to a cross reference, set the nextRDNToBeResolved to the number of RDNs in the chosen cross reference. The cross reference is returned and this procedure is terminated.  H   8)pIf no match was found to a cross reference, determine if the DSA is a first level DSA. If not, it will have a superior reference. Return this and terminate the procedure.  H  If the DSA is a first level DSA, set nextRDNToBeResolved to one, and nameResolutionPhase to proceeding . Return the root naming context and terminate the procedure.  H   9)pCheck the value of the referenceType component of the ChainingArgument . If a nonspecific subordinate reference was used, or the request came from a DUA, execute (10); otherwise, return ServiceError with invalidReference problem and terminate the procedure.  H   10)pCompare the initial portion of the purported name to the context prefixes (minus their last RDN) of the locally held naming contexts. This effectively is a comparison to some of the naming contexts of the immediate superior to this DSA.  H  f there is no match, return ServiceError with invalidReference problem and terminate the procedure.  H  f a match is found, and the number of RDNs matched is less than in nextRDNToBeResolved 1 , return ServiceError with invalidReference problem; otherwise, return ServiceError unableToProceed problem. Terminate the procedure.  HH HP X`h!(# H18.6.6 Local Name Resolution HP X`h!(#HH18.6.6.1Introduction  H Hp P X`h!(# The Local Name Resolution matches RDNs in the purported name against internal knowledge references. It returns Found, Remote Reference, Alias Dereferenced, or Error indication.  H  Figure 9/X.518 shows this procedure in the form of a diagram. Below is a textual description. HP X`h!(#HH18.6.6.2Arguments Hp P X`h!(# The procedure makes use of the following arguments:  H   pinternal reference to naming context (with pointer to the entry whose name is the same as the context prefix);   pthe target object name (the purported name);   poperation progress;   pthe value of the dontDereferenceAliases service control;   pthe value of the aliasedRDNs parameter;   pthe value of the aliasDereferenced parameter.  HH HP X`h!(#HH18.6.6.3Results Hp P X`h!(# There are three cases of successful outcome.  The first of these returns:   pa reference;   poperation progress (updated appropriately).  The second of these returns:   pan indication that the entry was found locally;   poperation progress (updated appropriately).  The third of these returns:   pan indication that an alias was dereferenced;   poperation progress (set back to "not started"). HP X`h!(#HH18.6.6.4Errors Hp P X`h!(# One of the following errors may be returned:   pname error. HP X`h!(#HH18.6.6.5Procedure  H Hp P X`h!(# The naming context returned by FindNaming Context will point to the entry of the root of the subtree. In the case of the root context, the entry is k+ only a null entry.  H   1)pf the internal reference is for an alias entry, execute step(7), otherwise step (2).  H   2)pf all the RDNs in the purported name have been matched, then the target entry has been found. Set nameResolutionPhase to completed . An internal pointer is returned and the procedure terminated.  Otherwise step (3) should be executed.  H  Note ĩ The matching could be attained with the context prefix on its own, or with the context prefix plus successive RDNs contained in internal references in the knowledge tree.  H   3)pIf an internal reference entry is found subordinate to the current entry in the knowledge tree which matches the next RDN in the purported name, then increment the nextRDNToBeResolved , set current entry to subordinate entry, and execute step (1) of this procedure again.  H   4)pIf the current entry has a subordinate reference whose RDN matches the next one in the purported name, return it and terminate the procedure.  H   5)pIf there are any nonspecific subordinate references, subordinate to the current entry in the knowledge tree, return them as references and terminate the procedure.  H   6)pIf an internal reference, subordinate reference, or nonspecific subordinate reference is not found, then check the number of RDNs in the purported name that have been matched. If more RDNs have been matched than in the aliasedRDNs component of ChainingArgument , then return NameError with noSuchObject problem. If less RDNs have been matched, then return NameError with aliasProblem .  H   7)pIf the number of RDNs in the purported name that have been matched is less than or equal to the aliasedRDNs component of ChainingArgument (if any), then the previous alias that was dereferenced (if any) points to another alias. If so, return NameError with aliasDereferencingProblem .  H   8)pIf the aliasedRDNs component is missing, or if the number of RDNs matched is greater than aliasedRDNs component of ChainingArgument , then check the dontDereferenceAlias service control. If aliases can be dereferenced, then execute step (9), otherwise step (10).  H   9)pDereference the alias. Set nameResolutionPhase of OperationProgress to notStarted . Set aliasDereferenced component of ChainingArgument to TRUE , and aliasedRDNs to the number of RDNs in the aliasedObjectName attribute of the alias entry. Set targetObject to the new name. Terminate the procedure. (The process of Name Resolution will be restarted.)  H   10)pIf all the RDNs in the purported name have been matched, execute step (2). Otherwise, return NameError with aliasDereferencingProblem .  HH HP X`h!(#18.7  Object evaluation procedures  H Hp P X`h!(# The object evaluation procedures specified comprise two categories of procedures:   a)psingleobject evaluation procedure;   b)pmultipleobject evaluation procedures.  HH  Figure 10/X.518 shows the object evaluation procedure. 8D c4 P FIGURE 10/X.518 T070460088  c4 P  HP X`h!(# H18.7.1 Singleobject evaluation procedures  H Hp P X`h!(# Singleobject evaluation procedures, which are common to the class of operations concerned with accessing a single object are carried out directly, with the result or error being returned to the invoker.  These operations comprise Read , Compare , AddEntry , RemoveEntry , ModifyEntry and ModifyRDN , and their Chained counterparts.  The action required on the entry is as described in the appropriate paragraph of RecommendationX.511.  H  AddEntry , RemoveEntry , and ModifyRDN operations affect knowledge. If the immediate superior of the entry is in a different DSA, correct external knowledge references shall be maintained. How this is done is outside the scope of this Recommendation.  H  How the DSA is chosen to contain the entry created by AddEntry is outside the scope of this Recommendation.  If the immediate superior of an entry to be created by AddEntry or modified by ModifyRDN has nonspecific subordinate references, procedures outside the scope of this Recommendation shall be followed to ensure that no two entries have the same distinguished name.  H  Requests which cannot be satisfied under these conditions shall fail with an UpdateError with problem affectsMultipleDSAs . HP X`h!(# H18.7.2 Multipleobject evaluation procedures  H Hp P X`h!(# Multipleobject evaluation procedures, which are common to the class of operations concerned with accessing multiple objects, are specified in the following subparagraphs.  H  These operations comprise List and Search , and their Chained counterparts. HP X`h!(#HH18.7.2.1List  H Hp P X`h!(# This paragraph specifies the evaluation procedure specific to List and ChainedList . (In what follows the term "List" applies to both.) HP X`h!(#H18.7.2.1.1P List procedure (I) Hp P X`h!(# This procedure applies where the List request has n ameResolutionPhase component of OperationProgress set to notStarted or proceeding and where the DSA, after performing Name Resolution The base object will be denoted by "e".  H   1)pGet each locally held immediate subordinate of e to form a local set of results. Set aliasEntry and fromEntry in ListResult as appropriate.  H   2)pGet the set of nonspecific subordinate references and subordinate references to DSAs which hold immediate subordinates of "e".  H   3)pPass the subrequest with base object = e, and OperationProgress set to completed to the Operation Dispatcher which subsequently forwards it to each DSA which holds immediate subordinates of e.  H  Note ĩ If the DSA holds subordinate references with an indication of whether or not the subordinate entry are aliases, and the dontUseCopy is FALSE , then this step can be omitted for those entries. The information about the subordinates is available directly. HP X`h!(#H18.7.2.1.2P List Procedure (II) Hp P X`h!(# This procedure applies to a List request with the nameResolutionPhase component of OperationProgress set to completed .  The base object will be denoted by "e".  H   1)pGet each locally held immediate subordinate of e to form a local set of results. Set aliasEntry and fromEntry in ListResult as appropriate.  H   2)pPass the results to the Operation Dispatcher which forwards them to the requesting DUA or DSA.  HH HP X`h!(#HH18.7.2.2Search  H Hp P X`h!(# This paragraph specifies the evaluation procedure specific to Search and ChainedSearch . (In what follows the term "Search" applies to both.)  H  Note that two circumstances exist, requiring two separate procedures. The first procedure (18.7.2.2.1) applies when the DSA executing the Search contains the targetObject as a local entry. The second procedure (18.7.2.2.2) applies when the DSA executing the Search does not hold the targetObject , but only subordinates of the targetObject . HP X`h!(#H18.7.2.2.1P Search procedure (I)  H Hp P X`h!(# This procedure applies to a Search request with the nameResolutionPhase component of OperationProgress set to notStarted or proceeding and where the DSA, after performing Name Resolution, determines that it holds the target object.  The base object will be denoted by "e". -Ԍ H   1)pIf the subset argument is baseObject or wholeSubtree , then apply the filter argument specified in the Search to the entry e, to form a set of local results. Return the results for Results Merging. If the subset argument is baseObject , terminate the procedure, otherwise continue at (2).  H   2)pIf the subset argument is oneLevel or wholeSubtree form a set E from the locallyheld immediate subordinates of e, except that:  H  If aliases are to be dereferenced, i.e. the searchAliases parameter is TRUE , then any alias entries that are found are handled in paragraph 5) below and do not contribute to these results.  H  Apply the filter arguments to E to give a filtered subset Ew'gE; return this set Ew' of local results for Results Merging.  H   3)pOther subordinates of e may reside in other DSAs, and if so will be referenced as subordinate or nonspecific subordinate references. For each DSA which is so referenced, prepare a new Search with targetObject = e, and with nameResolutionPhase of OperationProgress set to completed . Return each Search subrequest to the Operation Dispatcher for forwarding. If any error result is returned from a subrequest, it is ignored, as if no subrequest had been sent.  H   4)pIf the subset argument is oneLevel , the Search is now complete so terminate the procedure.  If the subset argument is wholeSubtree , then:  H  if the set E from paragraph (2) is empty, then the whole subtree held in this DSA has been searched, so terminate the procedure;  otherwise continue processing as follows:  H  let each entry that was in set E be denoted by e. Repeat the Search procedure from paragraph (2), for each entry e.  H   5)pIf aliases are to be dereferenced, any alias entries found in step(2) are placed in set D. For each entry d in D, dereference the alias, and formulate a new Search with nameResolutionPhase set to notStarted , and targetObject created from the aliasedObjectName attribute and the old targetObject name.  H  If the subset argument was oneLevel , set it to baseObject in the new subrequest, otherwise set it to wholeSubtree .  H  If any error result is returned from the subrequest, it is ignored, as if no subrequest had been made.  HH HP X`h!(#H18.7.2.2.2P Search Procedure (II)  H Hp P X`h!(# This procedure applies to a Search request with the nameResolutionPhase component of OperationProgress set to completed .  The target object will be denoted by "e".  For each locally held immediate subordinate ew' of e, formulate a new request with targetObject = ew'.  H  If the subset argument was oneLevel, set it to baseObject, otherwise leave it as wholeSubtree . Now carry out the procedure defined in steps (1) to (5) in 18.7.2.2.1. If there are no such subordinates, return unableToProceed ServiceError . HP X`h!(#18.8  Result merging procedure  H Hp P X`h!(# This procedure is called when external results and/or errors are present. There might also be one internal result. All results and errors are assumed to be held within the DSA until the procedure completes.  H  The external information could be due to chaining, multicasting or request decomposition.  H  In the case of chaining there will be a single result or error. In the case of multicasting there might be either no result, one result or several identical results. In addition, there may be some errors. If there is more than one result, all but one of them are arbitrarily discarded. A result is always returned in preference to an error. If there are no results, an error is returned, with the following exceptions:  H   i)pIf invalidReference was returned, the reference is marked as such, and the DSA may either use an appropriate alternate external reference to continue the request, or return ditError to the requestor. (The handling of invalid external references is beyond the scope of this Recommendation.)  H   ii)pIn the case of multicasting, unableToProceed errors should be ignored, unless all responses are of this type in which case  H   NameError noSuchObject should be returned to the responder. If at least one result is returned, then all errors can be ignored.  H   iii) In the case of referrals, these need not be treated as errors, and may be acted upon.  H  If the merging is required due to a request decomposition, the merging amounts to forming the union of the results.  H  In the case of decomposition, when there are both results and errors to be merged, an incomplete result is returned to the requestor.  H  A DSA might at this stage choose to extract referrals from the incoming results and errors that should be merged. It might then decide to explore all or some of these further, in which case operations are chained. The old result will have to be saved and later merged with the results or errors produced by the chaining.  H  The handling of signatures which may be present with the results being returned is specified in 18.9.2 below. HP X`h!(#18.9  Procedures for distributed authentication  H Hp P X`h!(# This paragraph specifies the procedures necessary to support the directory distributed authentication services. These services, and hence the procedures, are categorized as:  H   poriginator authentication, which is supported in either an unprotected (simple identity based) or secure (based upon digital signatures) form; and  H   presults authentication which is similarly protected (again based upon digital signatures).  HH HP X`h!(# H18.9.1 Originator authentication HP X`h!(#HH18.9.1.1Identity based authentication  H Hp P X`h!(# The identity based authentication service enables DSAs to authenticate the original requestor of information for the purpose of effecting local access controls. DSAs wishing to exploit this service must adopt the following procedure:  H   pfor a DSA requiring to authenticate a DAP request, the DSA acquires the distinguished name of the requestor through the Bind procedures at the time a DUA association (DUA or DSA) is established. Successful conclusion of these procedures does not in any way prejudice the level of authentication that may subsequently be required for processing operations using that association;  Hx   pthe DSA with which the DUA association exists must insert the requestor's distinguished name in the initiator field of the ChainingArgument for all subsequent chained operations to other DSAs;  H   pa DSA, on receiving a chainedoperation, may satisfy that operation, or not, depending upon the determination of access rights (a locally defined mechanism). If the outcome is not satisfactory a SecurityError may be returned with SecurityProblem set to insufficientAccessRights .  HH HP X`h!(#HH18.9.1.2Signaturebased originator authentication  H Hp P X`h!(# This signaturebased originator authentication service enables a DSA to authenticate (in a secure manner) the originator of a particular service request. The procedures to be effected by a DSA in realizing this service are described in this paragraph.  H  The signaturebased authentication service is invoked by a DUA using the SIGNED variant of an optionallysigned service request.  H  A DSA, on receiving a signed request from another DSA, shall remove that DSA's signature prior to processing the operation. Assuming the result of any signature verification proves to be satisfactory, the DSA will continue to progress the operation. If, during processing, the DSA requires to perform - chaining, multicasting or request decomposition, the argument set for each associated chained operation shall be constructed as follows:  H   pthe DSA forms an argument set which may be optionally signed; the argument set comprises the incoming signed argument set together with a modified ChainingArgument .  Hx  In the event that the DSA is able to contribute information to the response, originator authentication, based upon the signed service request, may be used for the determination of access rights to that information.  H  If a DSA receives an unsigned service request for information which will only be released subject to originator authentication, a SecurityError will be returned with SecurityProblem set to protectionRequired . HP X`h!(# H18.9.2 Results authentication Hp P X`h!(# This service is provided to enable requestors of directory operations (either DUA or DSAs) to verify (in a secure manner using digital signature techniques) the source of results. The results authentication service may be requested irrespective of whether originator authentication is to be used.  H  The results authentication service is initiated using the signed value of the protectionRequest component as contained within the argument set of directory operations; a DSA receiving an operation with this option selected may then optionally sign any subsequent results. The signed option in the protectionRequest serves as an indication, to the DSA, of the requestor's preference; the DSA may, or may not, actually sign any subsequent results.  In the case where a DSA performs chaining, multicasting or request decomposition of such a request, the DSA has a number of options in terms of the form of results sent back to the requestor, namely:  H   a)preturn a composite response (signed or unsigned) to the requestor;  H   b)preturn a set of two or more uncollated partial responses (signed or unsigned) to the requestor; within this set zero or more members may be signed and zero or one unsigned. In the event that an unsigned partial result is present, this member may in fact be a collation of one or more unsigned partial responses which have been received from other DSAs, contributed by this DSA, or both.  HH Ђ8O c4 P ANNEX A 8F c4 P (to Recommendation X.518) 8B ASN.1 for distributed operations  This Annex is part of the Recommendation.  H  This Annex includes all of the ASN.1 type, value and macro definitions contained in this Recommendation in the form of the ASN.1 module Distributed Operations .   DistributedOperations {jointisoccitt ds(5) modules(1) distributedOperations(3)}   DEFINITIONS ::=   BEGIN   EXPORTS  hp DirectoryRefinement, chainedReadPort, chainedSearchPort, chainedModifyPort,  hpDSABind, DSABindArgument,  hpDSAUnbind,  hpChainedRead, ChainedCompare, ChainedAbandon,  hpChainedList, ChainedSearch,  hpChainedAddEntry, ChainedRemoveEntry,  hpChainedModifyEntry, ChainedModifyRDN,  hpDsaReferral, ContinuationReference;   IMPORTS  H  hpInformationFramework, abstractService, distributedOperations,  hpdirectoryObjectIdentifiers, selectedAttributeTypes  Hx  hph FROM UsefulDefinitions {jointisoccitt ds(5) modules(1) usefulDefinitions(0)}  hp DistinguishedName, Name, RelativeDistinguishedName  Hh  hph   FROMX%InformationFramework informationFramework  H  hp idotdsa, idptchainedread, idptchainedsearch, idptchainedmodify  hph FROM DistributedDirectoryObjectIdentifiers, distributedDirectoryObjectIdentifiers   PresentationAddress  hph FROM SelectedAttributeTypes selectedAttributeTypes  hp directory, readPort, searchPort, modifyPort  hpDirectoryBind,  hpReadArgument, ReadResult,  hpCompareArgument, CompareResult,  hpAbandon  hpListArgument, ListResult,  hpSearchArgument, SearchResult,  hpAddEntryArgument, AddEntryResult,  hpRemoveEntryArgument, RemoveEntryResult,  hpModifyEntryArgument, ModifyEntryResult,  hpModifyRDNArgument, ModifyRDNResult,  H  hpAbandoned, AttributeError, NameError, ServiceError, SecurityError, UpdateError  hpOPTIONALLYSIGNED, SecurityParameters  HX  hp  FROM DirectoryAbstractService directoryAbstractService   objects and ports   DirectoryRefinement X%::= REFINE directory AS  hp dsa  RECURRING  hph readPort X%[S](*VISIBLE  hph searchPortX%[S](*VISIBLE  hph modifyPortX%[S](*VISIBLE  hph chainedReadPort$**/PAIRED WITH dsa  hph chainedSearchPort&*PAIRED WITH dsa  hph chainedModifyPort&*PAIRED WITH dsa   dsa OBJECT  hpPORTS { readPort(*[S],  hph   searchPort*/[S],  hph   modifyPort*/[S],  hph   chainedReadPort,  hph   chainedSearchPort  hph   chainedModifyPort}  hp ::= idotdsa   chainedReadPort PORT  hpABSTRACT OPERATIONS {  hp ChainedRead, ChainedCompare,  hp ChainedAbandon}  hp::= idptchainedread chainedSearchPort PORT  hpABSTRACT OPERATIONS {  hph  ChainedList, ChainedSearch}  hp::=  idptchainedsearch   chainedModifyPort PORT  hpABSTRACTOPERATIONS {  hph  ChainedAddEntry, ChainedRemoveEntry,  hph  ChainedModifyEntry, ChainedModifyRDN}  hp::= idptchainedmodify   DSABindP ::= ABSTRACTBIND  hpTOP {chainedRead,  hph  chainedSearch,  hph  chainedModify}  hpDirectoryBind   DSAUnbind ::= UNBIND  hpFROM  {chainedRead,  hph   X%chainedSearch,  hph   X%chainedModify}   operations, arguments and results   ChainedRead ::=  hpABSTRACTOPERATION  hph  ARGUMENT#X%OPTIONALLYSIGNED69SET{  hph   X%%**//`449ChainingArgument,  hph   X%%**//`449[0] ReadArgument}  hph  RESULT!X%OPTIONALLYSIGNED69SET{  hph   X%%**//`449ChainingResult,  hph   X%%**//`449[0] ReadResult}  hph  ERRORS {  H  hph   DsaReferral, Abandoned, AttributeError, NameError,  hph   ServiceError, SecurityError}   ChainedCompare X%::=  hpABSTRACTOPERATION  hph  ARGUMENT#X%OPTIONALLYSIGNED69SET{  hph   X%%**//`449ChainingArgument,  Hh  hph   X%%**//`449[0] CompareArgument}  hph  RESULT!X%OPTIONALLYSIGNED69SET{  hph   X%%**//`449ChainingResult,  HX  hph   X%%**//`449[0] CompareResult}  hph  ERRORS {  H  hph   DsaReferral, Abandoned, AttributeError, NameError,  hph   ServiceError, SecurityError}   ChainedAbandon X%::=(*Abandon   ChainedList ::=  hpABSTRACTOPERATION  hph  ARGUMENT#X%OPTIONALLYSIGNED69SET{  hph   X%%**//`449ChainingArgument,  hph   X%%**//`449[0] ListArgument}  hph  RESULT!X%OPTIONALLYSIGNED69SET{  hph   X%%**//`449ChainingResult,  hph   X%%**//`449[0] ListResult}  hph  ERRORS {  H  hph   DsaReferral, Abandoned, AttributeError, NameError,  hph   ServiceError, SecurityError } ChainedSearch ::=  hpABSTRACTOPERATION  hph  ARGUMENT#X%OPTIONALLYSIGNED69SET{  hph   X%%**//`449ChainingArgument,  H  hph   X%%**//`449[0] SearchArgument}  hph  RESULT!X%OPTIONALLYSIGNED69SET{  hph   X%%**//`449ChainingResult,  hph   X%%**//`449[0] SearchResult}  hph  ERRORS {  H  hph   DsaReferral, Abandoned, AttributeError, NameError,  hph   ServiceError, SecurityError}   ChainedAddEntry ::=  hpABSTRACTOPERATION  hph  ARGUMENT#X%OPTIONALLYSIGNED69SET{  hph   X%%**//`449ChainingArgument,  H  hph   X%%**//`449[0] AddEntryArgument}  hph  RESULT!X%OPTIONALLYSIGNED69SET{  hph   X%%**//`449ChainingResult,  H  hph   X%%**//`449[0] AddEntryResult}  hph  ERRORS {  H  hph   DsaReferral, Abandoned, AttributeError, NameError,  hph   ServiceError, SecurityError, UpdateError}   ChainedRemoveEntryX%::=  hpABSTRACTOPERATION  hph  ARGUMENT#X%OPTIONALLYSIGNED69SET{  hph   X%%**//`449ChainingArgument,  H  hph   X%%**//`449[0] RemoveEntryArgument}  hph  RESULT!X%OPTIONALLYSIGNED69SET{  hph   X%%**//`449ChainingResult,  Hx  hph   X%%**//`449[0] RemoveEntryResult}  hph  ERRORS {  hph   DsaReferral, Abandoned, NameError,  hph   ServiceError, SecurityError, UpdateError}   ChainedModifyEntryX%::=  hpABSTRACTOPERATION  hph  ARGUMENT#X%OPTIONALLYSIGNED69SET{  hph   X%%**//`449ChainingArgument,  H  hph   X%%**//`449[0] ModifyEntryArgument}  hph  RESULT!X%OPTIONALLYSIGNED69SET{  hph   X%%**//`449ChainingResult,  Hx  hph   X%%**//`449[0] ModifyEntryResult}  hph  ERRORS {  H  hph   DsaReferral, Abandoned, AttributeError, NameError,  hph   ServiceError, SecurityError, UpdateError}   ChainedModifyRDN ::=  hpABSTRACTOPERATION  hph  ARGUMENT#X%OPTIONALLYSIGNED69SET{  hph   X%%**//`449ChainingArgument,  Hx  hph   X%%**//`449[0] ModifyRDNArgument}  hph  RESULT!X%OPTIONALLYSIGNED69SET{  hph   X%%**//`449ChainingResult,  Hh  hph   X%%**//`449[0] ModifyRDNResult}  hph  ERRORS {  hph   DsaReferral, Abandoned, NameError,  hph   ServiceError, SecurityError, UpdateError} © errors and parameters   DSAReferral ::=  hpABSTRACTERROR  hph  PARAMETER SET {  hph   [0]#X%ContinuationReference,  H  hph   contextPrefix-/[1]2`4DistinguishedName OPTIONAL}   common arguments/results   ChainingArguments ::=#X%%*SET {  hporiginator X%%*[0]-/DistinguishedName OPTIONAL,  hptargetObject X%%*[1]-/DistinguishedName OPTIONAL,  hpoperationProgress#X%%*[2]-/OperationProgress DEFAULT {notStarted}  hptraceInformation"X%%*[3]-/TraceInformation,  hpaliasDereferenced#X%%*[4]-/BOOLEAN DEFAULT FALSE,  hpaliasedRDNs X%%*[5]-/INTEGER OPTIONAL,  hph   absent unless aliasDereferenced is TRUE   hpreturnCrossRefs!X%%*[6]-/BOOLEAN DEFAULT FALSE,  H  hpreferenceTypeX%%**/[7]2`4ReferenceType DEFAULT superior,  hpinfo  X%%**/[8]2`4Domaininfo OPTIONAL,  hptimeLimit X%%*[9]-/UTCTime OPTIONAL,  H  hp   X%%*[10].`4SecurityParameters DEFAULT { }}   ChainingResults ::=#X%%*SET {  hpinfo  X%%**/[0]2`4Domaininfo OPTIONAL,  H  hpcrossReferences!X%%*[1]-/SEQUENCE OF CrossReference OPTIONAL,  Hh  hph    X%%*[2]-/SecurityParameters DEFAULT { }}   CrossReference X% ::=)//`4SET {  hpcontextPrefix X%[0](**/DistinguishedName,  hpaccessPoint X%%*[1]-/AccessPoint}   ReferenceType X%::=(**/ENUMERATED {  hp superior X%%**//`449(1),  hp subordinate X%%**//`449(2),  hp cross X%%**//`449(3),  hp nonSpecificSubordinate+//`4499>(4)}   TraceInformation ::=#X%%*SEQUENCE OF  hpSEQUENCE {  hph  targetObject'**/Name,  hph  dsa Name,  hph  OperationProgress}   OperationProgress ::=#X%%*SET-/{  hpnameResolutionPhase%**//`4[0] ENUMERATED {  H  hph   X%%**//`4499>notStartedH8"I(1),  H  hph   X%%**//`4499>proceedingH8"I(2),  H  hph   X%%**//`4499>completedG!H(3)},  hpnextRDNToBeResolved%**/[1] INTEGER OPTIONAL}   DomainInfo  X%::=(*ANY   ContinuationReference"X%%*::=-/SET {  hptargetObject X%[0](*Name,  hpaliasedRDNs X%[1](*INTEGER OPTIONAL,  hpoperationProgress#X%[2](*OperationProgress  hprdnsResolved X%[3](*INTEGER OPTIONAL,  hpreferenceTypeX%%*[4]-/ReferenceType OPTIONAL,  hph   X% only present in the DSP  hpaccessPoints X%[5](*SET OF AccessPoint } AccessPoint ::=#X%SET {  hpaetitle [0]#X%Name,  hpaddress [1] PresentationAddress }  HH Ђ8O c4 P  ANNEX B 8F c4 P (to Recommendation X.518) 8G Modelling of knowledge  This Annex is not part of the Recommendation. HP X`h!(#B.1h  Example of knowledge modelling  H Hp P X`h!(# The following example illustrates the knowledge information that would have to be maintained by the DSAs shown in Figure5/X.518 (9). Figure5/X.518 depicts a hypothetical DIT logically partitioned into five Naming Contexts (A, B, C, D and E) and physically distributed over three DSAs (DSA1, DSA2, DSA3). In the example, DSA1 holds context C, DSA2 holds contexts A, B, and E, and DSA3 holds context D.  The following abbreviations have been used in Figures B1/X.518 to B3/X.518.   SUPR:  superior reference   SUBR:  subordinate reference   INTR:  internal reference   NSSR:  nonspecific subordinate reference   CROSSR:P cross reference   DSAn:  Distinguished Name of DSAn   PS:p  Presentation Address   CP:p  context prefix   RDN:  Relative Distinguished name   DSA:  Distinguished name of a DSA   PTR:  Pointer   AON:  Aliased Object Name .  H  Note ĩ The following figures are intended only to provide a pictorial example of the concepts defined in this paragraph. How knowledge information is actually stored and managed in a particular DSA implementation is a local matter and is outside the scope of this Recommendation. J c4 P FIGURE B1/X.518 T070461088  c4 P   H Ё Figure B1/X.518 illustrates the knowledge information that must be held by DSA1. This must include the following context prefixes and set of references:   Context Prefixes: {C=WW, O=ABC}, context C.   Cross References: { }   Superior References:!X%{DSA2, presentation address of DSA2}   Internal References   for Context C: X%%*{C=WW, O=ABC},  hph   {OU=G}, {OU=H}  hph   {OU=G, CN=1},  hph   {OU=G, CN=m},  hph   {OU=G, CN=n}.   Subordinate References:$**/{ }   Nonspecific subordinate  H   References:  X%%*{DSA2, presentation address of DSA2}.  HH Ђ8C c4 P FIGURE B2/X.518 T070462088  c4 P   H Ё Figure B2/X.518 illustrates the knowledge information that must be held by DSA2. This must include the following context prefixes and set of references:   Context Prefixes: {C=WW}, context A  hph   {C=VV}, context B  hph   {C=WW}, O=ABC, OU=I}, context E.   Cross References: { }   Superior References:!X%{ }   Internal References   for Context A: X%%*{C=WW}   Internal References   for Context B: X%%*{C=VV}   Internal References   for Context E: X%%*{C=WW, O=ABC, OU=I},  hph   {CN=o},  hph   {CN=p},  hph   {CN=q}.   Subordinate References   for Context A: X%%*{C=WW, O=ABC}   Subordinate References   for Context B: X%%*{C=VV, O=DEF}   Nonspecific subordinate   References:  X%{ }  HH Ђ8C c4 P FIGURE B3/X.518 T070463088  c4 P   H Ё Figure B3/X.518 illustrates the knowledge information that must be held by DSA3. This must include the following context prefixes and set of references:   Context Prefixes: {C=VV, O=DEF}, context D  H   Cross References: {{C=WW, O=ABC, OU=H}, DSA1, presentation address of DSA1} (not shown  X%%**/inthe figure above)   Superior References:!X%{DSA2, presentation address of DSA2}   Internal References  Hh   for Context D: X%%*{DSA1, presentation address of DSA1}  hph   {C=VV, O=DEF},  hph   {OU=J},  hph   {OU=K} alias for {C=WW, O=ABC, OU=I, CN=o}  Hx  hph   (alias information is not part of the knowledge)   Subordinate References:$*{ }   Nonspecific subordinate   References:  X%{ }  HH HP X`h!(#B.2h  Example of distributed name resolution  H Hp P X`h!(# The following is an example of how Distributed Name Resolution is used to process different directory requests. The example is based on the hypothetical DIT shown in Figure5/X.518 (9) and the corresponding DSA configuration(s) shown in FiguresB1/X.518 to B3/X.518 (Annex B).  H  Assuming a chaining mode of propagating, the following requests addressed to DSA1 would be processed as follows:  Hh   1)p A request with distinguished name {C=WW, O=ABC, OU=G, CN=1}  H  ©pWill match context prefix {C=WW, O=ABC} of context C for which DSA1 has administrative authority. Therefore, name resolution will begin in DSA1 with context C.  H  ©pName resolution will proceed downwards in context C successfully matching each remaining RDN, until CN=1 is located.   2)pA request with distinguished name {C=WW, O=JPR}  H  ©pWill not match any context prefix held by DSA1, therefore DSA1 will use its superior reference to forward the request to its superior DSA, DSA2.  H  ©pIn DSA2, the request will match context prefix {C=WW} and name resolution will begin in DSA2 with context A.  H  ©pName resolution will not find a subordinate of C=WW to match RDN O=JPR, therefore the request will fail and the name will be determined to have been invalid (i.e. reference a nonexistent object).   3)pA request with distinguished name {C=VV, O=DEF, OU=K}  H  ©pDSA1 will therefore forward the request to its superior DSA, DSA2.  H  ©pThe request will match context prefix {C=VV} of context B held by DSA2. Therefore, name resolution will begin in DSA2 with context B.  H  ©pAs name resolution attempts to match O=DEF, it will find a subordinate reference indicating that {C=VV, O=DEF} is the start of a new context held in DSA3. -ƌ H  ©pName resolution will continue in DSA3 until {C=VV, O=DEF, CN=K} is located.  H  ©pAssuming that aliases are to be dereferenced, a new name will be constructed using the aliased name contained in the entry {C=VV, O=DEF, CN=K}. The resulting new name will be: {C=WW, O=ABC, OU=I, CN=o}.  Hx  ©pDSA3 will resume processing of the request using the new name obtained by dereferencing. HH Ђ c4 P  8OANNEX C 8F c4 P (to Recommendation X.518) 8B Distributed use of authentication  This Annex is not part of the Recommendation. HP X`h!(#C.1h  Summary  H Hp P X`h!(# The security model is defined in 10 of RecommendationX.501. The following is a summary of the main points of the model.  H   a)pSimple Authentication of the operation initiator is not supported in the DSP.  H   b)pStrong Authentication, by the signing of the request and of the result, is supported in the DSP.  H   c)pEncryption of the request, or of the result, is not supported in the DSP.  H   d)pAuthentication of errors, including referrals, is not supported in the DSP.  Hh  This Annex describes how b) above is realized in the distributed Directory. It makes use of terminology and notation defined in Recommendation X.509. HP X`h!(#C.2h  Simple authentication  H Hp P X`h!(# The DUA will be authenticated as part of the Bind Operation of the DAP. Thereafter, only the name of the DUA will be carried in the DSP, in the initiator field of the Chaining Argument. HP X`h!(#C.3h  Distributed authentication model Hp P X`h!(#ЂJ c4 P FIGURE C1/X.518 T070464088  c4 P   Figure C1/X.518 illustrates the model to be used to specify the distributed authentication procedures. The model identifies the sequence of information flows for the general case of a list or search operation. The operation is considered as originating from DUA "a" citing a target object which resides in DSA "c"; in performing the operation, DSAs "b", "c", "d" and "e" are to be involved.  DUA "a" initially contacts any DSA (DSA "b") which does not hold the target object, but which is able to navigate, via chaining, to the DSA (DSA"c") holding the target object. If all the DSAs were operating in referral mode, then the model would be significantly simplified, and each DUA/DSA exchange would equate, in authentication terms, to the interaction between DUA "a" and DSA"b". HP X`h!(#C.4h  DUA to DSA  H Hp P X`h!(# Originator authentication is realized as a consequence of exchange (1). In FigureC1/X.518 the authentication procedure is as follows:   Let  H   OA = the Operation Argument i.e. Search, Read, Compare etc. Argument as defined in Part3.   and   a(OA) = the Operation Argument signed by DUA "a".  Hx   Authentication will be determined by verification of the signature.  HH HP X`h!(#C.5h  Transference from the DAP to the DSP  H Hp P X`h!(# This procedure is effected by DSA "b" in Figure C1/X.518 and represents the transference of the signed identity of the initiator from the DAP to the DSP.  H  DSA "b" formulates the appropriate Chaining Argument as described in 12.3 of this Recommendation and combines it with the Operation Argument from the DAP thus forming a Chained Operation, i.e. Chained Read, Search, List etc. of the DSP. The Chained Operation so formed will be signed prior to passing it to other DSAs (DSA "c" in Figure C1/X.518). The data structure can be represented as:   b{ChA,a{OA}} = the Chained Operation signed by  hph  DSA b   where   ChA = Chaining Argument.  H  Authentication information carried in the DSP between two DSAs [labelled exchange (2) in Figure C-1/X.518] therefore comprises two parts:  Hx   pthe Operation Argument, signed by the initiator, which allows authentication of the initiator;  H   pthe Chained Operation, signed by the sending DSA, which allows authentication of the sending DSA.  HH HP X`h!(#C.6h  Chaining through intermediate DSAs  H Hp P X`h!(# This procedure would be effected by DSA "c" in the model depicted in FigureC1/X.518. DSA "c" will discard the signature provided by the sending DSA (DSA"b" in FigureC1/X.518), and will modify the Chaining Argument, as described in 12.3 of this Recommendation. DSA "c" shall then combine the modified Chaining Argument with the signed Operation Argument, and sign the result to create a modified signed Chained Operation. This can be represented by:   c{ChAw', a{OA}} = the Chained Operation signed by DSA "c"   where   ChAw' = modified Chaining Argument.  H  This procedure would be effected by DSA "c" in the model depicted in Figure C1/X.518. DSA "c" upon the nature of the operation, and upon the type of knowledge held, DSA "c" may perform request decomposition prior to chaining or multicasting any resultant operation(s). This has been represented in FigureC1/X.518 by DSA "c" sending operations to DSA "d" and DSA "e"; in each case the authentication procedure is identical. HP X`h!(#C.7h  Results authentication Hp P X`h!(# The results authentication service is requested by an initiator of a directory operation using the signed option within the protectionRequest SecurityParameter . In providing a response to such a request a DSA may optionally decide whether or not to sign any or all of the results; the results authentication service does not provide for the authentication of error responses.  Within the context of a particular DSA processing results from an arbitrary number of DSAs (each of which are associated with a particular service request) the following distinct cases are possible:  H   pthe DSA provides a complete set of results for an operation without the need to perform any collating function (represented by DSA "d" and DSA "e" in FigureC1/X.518);  H   pthe DSA collates local results (sourced by this DSA) with the results from one or more other DSAs (represented by DSA "c" in Figure C1/X.518);  H   pthe DSA chains a result from a DSA to either another DSA or a DUA and does not contribute to the result set as it does so (represented by DSA "b" in FigureC1/X.518).  HH HP X`h!(# HC.7.1 DSA results no collation  H Hp P X`h!(# This paragraph addresses the role of a DSA in being the sole source of results to a particular operation request, i.e. the DSA has no collation function to perform. The paragraph considers the case for both the DSP and the DAP. HP X`h!(#HHC.7.1.1DSP Hp P X`h!(# The DSA can choose to perform either of the following procedures:   preturn the results unsigned, this can be represented by:  ChR,OR = Chained Operation Result (unsigned)  where  ChR = Chaining Results  OR = Operation Result;  H   psign only the Operation Result, this can be represented by:  ChR, d(OR) = Operation Result signed by DSA "d";  H   psign only the Chained Operation Result, which can be represented as:  d (ChR, OR) = Chained Operation Result signed by DSA "d"  H   psign both the Operation Result and the Chained Operation Result, which can be represented by:  H  d{ChR, D{OR}} = Operation Result and Chained Operation Result signed by DSA "d".  H  Note ĩ For the case where the Operation Result is signed, the signed -  result will be carried back to the initiator; for the case where the  H Chained Operation Result has been signed, the receiving DSA will have to discard the signature in order to modify the Chaining Results argument prior to forwarding the Chained Operation Result. HP X`h!(#HHC.7.1.2DAP  H Hp P X`h!(# This is fully described in Recommendation X.511, a summary is reproduced here for completeness.  H  The DSA can choose to either return the results unsigned, which can be represented by:   OR = Operation Result   or, signed, which can be represented by:   d{OR} = Operation Result signed by DSA "d".  HH HP X`h!(# HC.7.2 DSA results collation included  H Hp P X`h!(# This paragraph addresses the role of a DSA in returning the result of particular service requests where collation and integration of results from other DSAs is a necessary prerequisite. The paragraph considers the case for both the DSP and the DAP. HP X`h!(#HHC.7.2.1DSP Hp P X`h!(# Recognizing that zero or more results received from other DSAs may be signed, this procedure enables a DSA to collate and integrate the results  H and sign zero or more constituent parts of the composite result and optionally, sign the composite result as a whole. HP X`h!(#HC.7.2.1.1P Production of the chaining results argument  H Hp P X`h!(# This procedure requires that a DSA (represented by DSA "c" in FigureC1/X.518) remove all of the Chained Operation Result signatures from the results received from external DSAs (DSA "d" and DSA "e" inFigureC-1/X.518). DSA "c" then possesses a set of unsigned Chaining results, a set of signed Operation Results, and a set of unsigned Operation Results.  H  All the Chaining Results are manipulated as described in 12.4 of this Recommendation to create a single modified Chaining Result, denoted by:  i)pChRw' = modified Chaining Results. HP X`h!(#HC.7.2.1.2P Unsigned locally derived result  H Hp P X`h!(# If the DSA does not wish to sign the locally generated results, the set of unsigned Operation Results are merged with the local result to form a modified set of Operation Results, denoted by:   ORw' = Merged Operation Result.  H  The complete set of Operation Results is then the union of the set of externally signed Operation Results denoted by:   d{OR}, e{OR} ...   and the Merged Operation Result, collectively denoted by:  HH  (ii) ORw', d{OR}, e{OR} ...= Operation Result. HP X`h!(#HC.7.2.1.3P Signed locally derived result  H Hp P X`h!(# If the DSA does wish to sign the locally generated results, then the externally generated set of unsigned Operation Results are first merged together. The complete set of Operation Results is then the union of the locally signed set of Operation Results denoted by C{OR}, the merged set of externally unsigned Operation Results denoted by, OR", and the set of externally signed Operation Results denoted by:   d{OR}, e{OR}, ..., which are collectively denoted as:  HH  (iii) c{OR}, ORw", d{OR}, e{OR}, ... = Operation Result. HP X`h!(#HC.7.2.1.4P Unsigned chained operation result  H Hp P X`h!(# If the DSA does not wish to sign the Chained Operation Result, then the latter will comprise the Chaining Results (identified in (i) above) added to the Operation Result identified in either (ii) or (iii) above, collectively, these are denoted by:   either:  H   ChRw', ORw', d{OR}, e{OR}, ... = Chained Operation Result (unsigned).   or,  H   ChRw', c{OR}, OR", d{OR}, e{OR}, ... =39Chained Operation Result (unsigned) and Operation  hp   X%%*Result signed by DSA "c".  HH HP X`h!(#HC.7.2.1.5P Signed chained operation result  H Hp P X`h!(# If the DSA does wish to sign the Chained Operation Result, then the result will comprise the Chaining Results (identified in (i) above) added to the Operation Result (identified in either (ii) or (iii) above), collectively denoted as:   either:  H Hp X`h!(#  c{ChRw', ORw', d{OR}, e{OR}, ...} =0`4Chained Operation Result signed by DSA "c" Hp P X`h!(#  or,  H Hp X`h!(#  c{ChRw', c{OR}, ORw", d{OR}, e{OR}, ...} =79Chained Operation Result and Operation Hp P X`h!(# hp   X%%**/Result signed by DSA "c".  HH HP X`h!(#HHC.7.2.2DAP  H Hp P X`h!(# The procedure is very similar to that described in C.7.2.1, with the exception that the Chaining Results argument is not passed in the DAP. HP X`h!(# HC.7.3 DSA chained results Hp P X`h!(# This paragraph addresses the procedures to be effected by a DSA in chaining an operation result back to the requestor, DSA or DUA, within the DSP and DAP respectively. HP X`h!(#HHC.7.3.1DSP  H Hp P X`h!(# The DSA initially removes the signature (if one exists) from the Chained Operation Result. It then manipulates the Chaining Results argument as described in this Recommendation, to produce a modified Chaining Results argument. The latter is then merged back with the Operation Result argument to produce a modified Chained Operation Result. Finally, the DSA may optionally sign the Chained Operation Result before passing it to the next DSA in the chain. HP X`h!(#HHC.7.3.2DAP Hp P X`h!(# A DSA (represented by DSA "b" in Figure C1/X.518) first removes the signature (if one exists) from the Chained Operation Result. It then analyses and discards the Chaining Results argument and, finally, it optionally signs the remaining Operation Result argument before passing the result to the DUA. c4 P  VANNEX D M c4 P (to RecommendationX.518) E Distributed directory object identifiers  This Annex is part of the Recommendation.  H  This Annex includes all of the ASN.1 object identifiers contained in this Recommendation in the form of the ASN.1 module DistributedDirectoryObjectIdentifiers .  H   DistributedDirectoryObjectIdentifiers2`4{jointisoccitt ds(5) modules(1)  H  hph   X%%*distributedDirectoryObjectIdentifiers(13)}   DEFINITION ::=   BEGIN   EXPORTS  hpidotdsa, idptchainedRead, idptchainedSearch, idptchainedModify;   IMPORTS  hpidot, idpt  H  hph FROM UsefulDefinitions {jointisoccitt ds(5) modules(1) usefulDefinitions(0)};   objects   idotdsa OBJECT IDENTIFIER ::= {idot 3}   part types   idptchainedRead OBJECT IDENTIFIER1`449::=<>{idpt 4}  HX   idptchainedSearch X%OBJECT IDENTIFIER699>::=AhC{idpt 5}  HX   idptchainedModify X%OBJECT IDENTIFIER699>::=AhC{idpt 6}   END  HH