Зарубежные нормативные документы и критерии на английском / CCPART2V21

641

This class describes requirements specifically of interest for TOEs that are used for

the transport of information. Families within this class deal with non-repudiation.

Communication

FCO_NRO Non-repudiation of origin

1

2

FCO_NRR Non-repudiation of receipt

1

2

Figure D.1 - Communication class decomposition

642

Figure D.1 shows the decomposition of this class into its constituent components.

643

In this class the concept of “information” is used. This information should be

interpreted as the object being communicated, and could contain an electronic mail

message, a file, or a set of predefined attribute types.

644

In the literature, the terms ‘proof of receipt’ and ‘proof of origin’ are commonly

used terms. However it is recognised that the term ‘proof’ might be interpreted in a

legal sense to imply a form of mathematical rationale. The components in this class

interpret the de-facto use of the word ‘proof’ in the context of ‘evidence’ that the

TSF demonstrates the non-repudiated transport of types of information.

August 1999

Version 2.1

Page 203 of 354

D - Communication (FCO)

Non-repudiation of origin (FCO_NRO)

D.1

Non-repudiation of origin (FCO_NRO)

645

Non-repudiation of origin defines requirements to provide evidence to users/

subjects about the identity of the originator of some information. The originator

cannot successfully deny having sent the information because evidence of origin

(e.g. digital signature) provides evidence of the binding between the originator and

the information sent. The recipient or a third party can verify the evidence of origin.

This evidence should not be forgeable.

User notes

646

If the information or the associated attributes are altered in any way, validation of

the evidence of origin might fail. Therefore a PP/ST author should consider

including integrity requirements such as FDP_UIT.1 Data exchange integrity in the

PP/ST.

647

In non-repudiation there are several different roles involved, each of which could

be combined in one or more subjects. The first role is a subject that requests

evidence of origin (only in FCO_NRO.1 Selective proof of origin). The second role

is the recipient and/or other subjects to which the evidence is provided (e.g. a

notary). The third role is a subject that requests verification of the evidence of

origin, for example, a recipient or a third party such as an arbiter.

648

The PP/ST author must specify the conditions that must be met to be able to verify

the validity of the evidence. An example of a condition which could be specified is

where the verification of evidence must occur within 24 hours. These conditions,

therefore, allow the tailoring of the non-repudiation to legal requirements, such as

being able to provide evidence for several years.

649

In most cases, the identity of the recipient will be the identity of the user who

received the transmission. In some instances, the PP/ST author does not want the

user identity to be exported. In that case the PP/ST author must consider whether it

is appropriate to include this class, or whether the identity of the transport service

provider or the identity of the host should be used.

650

In addition to (or instead of) the user identity, a PP/ST author might be more

concerned about the time the information was transmitted. For example, requests

for proposals must be transmitted before a certain date in order to be considered. In

such instances, these requirements can be customised to provide a timestamp

indication (time of origin).

FCO_NRO.1 Selective proof of origin

Operations

Assignment:

651

In FCO_NRO.1.1 the PP/ST author should fill in the types of

information subject to the evidence of origin function, for example,

electronic mail messages.

Page 204 of 354

Version 2.1

August 1999

Non-repudiation of origin (FCO_NRO)

D - Communication (FCO)

Selection:

652

In FCO_NRO.1.1 the PP/ST author should specify the user/subject who

can request evidence of origin.

Assignment:

653

In FCO_NRO.1.1 the PP/ST author, dependent on the selection, should

specify the third parties that can request evidence of receipt. A third

party could be an arbiter, judge or legal body.

654

In FCO_NRO.1.2 the PP/ST author should fill in the list of the

attributes that shall be linked to the information; for example,

originator identity, time of origin, and location of origin.

655

In FCO_NRO.1.2 the PP/ST author should fill in the list of information

fields within the information over which the attributes provide evidence

of origin, such as the body of a message.

Selection:

656

In FCO_NRO.1.3 the PP/ST author should specify the user/subject who

can verify the evidence of origin.

Assignment:

657

In FCO_NRO.1.3 the PP/ST author, dependent on the selection, should

specify the third parties that can verify the evidence of origin.

658

In FCO_NRO.1.3 the PP/ST author should fill in the list of limitations

under which the evidence can be verified. For example the evidence can

only be verified within a 24 hour time interval. An assignment of

‘immediate’ or ‘indefinite’ is acceptable.

FCO_NRO.2 Enforced proof of origin

Operations

Assignment:

659

In FCO_NRO.2.1 the PP/ST author should fill in the types of information

subject to the evidence of origin function, for example, electronic mail

messages.

660

In FCO_NRO.2.2 the PP/ST author should fill in the list of the attributes that

shall be linked to the information; for example, originator identity, time of

origin, and location of origin.

661

In FCO_NRO.2.2 the PP/ST author should fill in the list of information

fields within the information over which the attributes provide evidence of

origin, such as the body of a message.

August 1999

Version 2.1

Page 205 of 354

D - Communication (FCO)

Non-repudiation of origin (FCO_NRO)

Selection:

662

In FCO_NRO.2.3 the PP/ST author should specify the user/subject who can

verify the evidence of origin.

Assignment:

663

In FCO_NRO.2.3 the PP/ST author, dependent on the selection, should

specify the third parties that can verify the evidence of origin. A third party

could be an arbiter, judge or legal body.

664

In FCO_NRO.2.3 the PP/ST author should fill in the list of limitations under

which the evidence can be verified. For example the evidence can only be

verified within a 24 hour time interval. An assignment of ‘immediate’ or

‘indefinite’ is acceptable.

Page 206 of 354

Version 2.1

August 1999

Non-repudiation of receipt (FCO_NRR)

D - Communication (FCO)

D.2

Non-repudiation of receipt (FCO_NRR)

665

Non-repudiation of receipt defines requirements to provide evidence to other users/

subjects that the information was received by the recipient. The recipient cannot

successfully deny having received the information because evidence of receipt (e.g.

digital signature) provides evidence of the binding between the recipient attributes

and the information. The originator or a third party can verify the evidence of

receipt. This evidence should not be forgeable.

User notes

666

It should be noted that the provision of evidence that the information was received

does not necessarily imply that the information was read or comprehended, but only

delivered

667

If the information or the associated attributes are altered in any way, validation of

the evidence of receipt with respect to the original information might fail. Therefore

a PP/ST author should consider including integrity requirements such as

FDP_UIT.1 Data exchange integrity in the PP/ST.

668

In non-repudiation, there are several different roles involved, each of which could

be combined in one or more subjects. The first role is a subject that requests

evidence of receipt (only in FCO_NRR.1 Selective proof of receipt). The second

role is the recipient and/or other subjects to which the evidence is provided, (e.g. a

notary). The third role is a subject that requests verification of the evidence of

receipt, for example, an originator or a third party such as an arbiter.

669

The PP/ST author must specify the conditions that must be met to be able to verify

the validity of the evidence. An example of a condition which could be specified is

where the verification of evidence must occur within 24 hours. These conditions,

therefore, allow the tailoring of the non-repudiation to legal requirements, such as

being able to provide evidence for several years.

670

In most cases, the identity of the recipient will be the identity of the user who

received the transmission. In some instances, the PP/ST author does not want the

user identity to be exported. In that case, the PP/ST author must consider whether

it is appropriate to include this class, or whether the identity of the transport service

provider or the identity of the host should be used.

671

In addition to (or instead of) the user identity, a PP/ST author might be more

concerned about the time the information was received. For example, when an offer

expires at a certain date, orders must be received before a certain date in order to be

August 1999

Version 2.1

Page 207 of 354

D - Communication (FCO)

Non-repudiation of receipt (FCO_NRR)

Operations

Assignment:

672

In FCO_NRR.1.1 the PP/ST author should fill in the types of

information subject to the evidence of receipt function, for example,

electronic mail messages.

Selection:

673

In FCO_NRR.1.1 the PP/ST author should specify the user/subject who

can request evidence of receipt.

Assignment:

674

In FCO_NRR.1.1 the PP/ST author, dependent on the selection, should

specify the third parties that can request evidence of receipt. A third

party could be an arbiter, judge or legal body.

675

In FCO_NRR.1.2 the PP/ST author should fill in the list of the

attributes that shall be linked to the information; for example, recipient

identity, time of receipt, and location of receipt.

676

In FCO_NRR.1.2 the PP/ST author should fill in the list of information

fields with the fields within the information over which the attributes

provide evidence of receipt, such as the body a message.

Selection:

677

In FCO_NRR.1.3 the PP/ST author should specify the user/subjects

who can verify the evidence of receipt.

Assignment:

678

In FCO_NRR.1.3 the PP/ST author, dependent on the selection, should

specify the third parties that can verify the evidence of receipt.

679

In FCO_NRR.1.3 the PP/ST author should fill in the list of limitations

under which the evidence can be verified. For example the evidence can

only be verified within a 24 hour time interval. An assignment of

‘immediate’ or ‘indefinite’ is acceptable.

Page 208 of 354

Version 2.1

August 1999

Non-repudiation of receipt (FCO_NRR)

D - Communication (FCO)

Operations

Assignment:

680

In FCO_NRR.2.1 the PP/ST author should fill in the types of information

subject to the evidence of receipt function, for example electronic mail

messages.

681

In FCO_NRR.2.2 the PP/ST author should fill in the list of the attributes that

shall be linked to the information; for example, recipient identity, time of

receipt, and location of receipt.

682

In FCO_NRR.2.2 the PP/ST author should fill in the list of information

fields with the fields within the information over which the attributes

provide evidence of receipt, such as the body of a message.

Selection:

683

In FCO_NRR.2.3 the PP/ST author should specify the user/subjects who

can verify the evidence of receipt.

Assignment:

684

In FCO_NRR.2.3 the PP/ST author, dependent on the selection, should

specify the third parties that can verify the evidence of receipt. A third party

could be an arbiter, judge or legal body.

685

In FCO_NRR.2.3 the PP/ST author should fill in the list of limitations under

which the evidence can be verified. For example the evidence can only be

verified within a 24 hour time interval. An assignment of ‘immediate’ or

‘indefinite’ is acceptable.

August 1999

Version 2.1

Page 209 of 354

D - Communication (FCO)

Non-repudiation of receipt (FCO_NRR)

Page 210 of 354

Version 2.1

August 1999

Annex E

(informative)

Cryptographic support (FCS)

686

The TSF may employ cryptographic functionality to help satisfy several high-level

security objectives. These include (but are not limited to): identification and

authentication, non-repudiation, trusted path, trusted channel and data separation.

This class is used when the TOE implements cryptographic functions, the

implementation of which could be in hardware, firmware and/or software.

687

The FCS class is composed of two families: FCS_CKM Cryptographic key

management and FCS_COP Cryptographic operation. The FCS_CKM family

addresses the management aspects of cryptographic keys, while the FCS_COP

family is concerned with the operational use of those cryptographic keys.

688

Figure E.1 shows the decomposition of this class into its constituent components.

Cryptographic support

1

2

FCS_CKM Cryptographic key management

3

4

FCS_COP Cryptographic operation

1

689

For each cryptographic key generation method implemented by the TOE, if any, the

PP/ST author should select the FCS_CKM.1 component.

690

For each cryptographic key distribution method implemented by the TOE, if any,

the PP/ST author should select the FCS_CKM.2 component.

691

For each cryptographic key access method implemented by the TOE, if any, the PP/

ST author should select the FCS_CKM.3 component.

August 1999

Version 2.1

Page 211 of 354

692

For each cryptographic key destruction method implemented by the TOE, if any,

the PP/ST author should select the FCS_CKM.4 component.

693

For each cryptographic operation (such as digital signature, data encryption, key

agreement, secure hash, etc.) performed by the TOE, if any, the PP/ST author

should select the FCS_COP.1 component.

694

Cryptographic functionality may be used to meet objectives specified in class FCO,

and in families FDP_DAU, FDP_SDI, FDP_UCT, FDP_UIT, FIA_SOS,

FIA_UAU, to meet a variety of objectives. In the cases where cryptographic

functionality is used to meet objectives for other classes, the individual functional

components specify the objectives that cryptographic functionality must satisfy.

Page 212 of 354

2.1

August 1999