RE: Meaning of Non-repudiation

[Peter Williams <peterw@xxxxxxxxxxxx>]

http://www.itsec.gov.uk/docs/pdfs/sectarg/EntAuth51.pdf
http://www.itsec.gov.uk/docs/pdfs/certreps/crp153.pdf

Further to my memo earlier today, I inspected the
security target for Entrust/RA and Entrust/Authority for which the UK Certification
Body recently issued certification report P.153.

The target claims

 

9.	Q.QRIGIN	FCO_NRO.2	This requirement ensures that the TOE generates
			evidence of origin fortransmitted public key
	The TOE must generate evidence of		certificates:
	origin for transmitted public key
	certificates.		FCO_NRO.2 ensures that evidence of origin is
			generated for certificates, CRLs, and ARLs so the
			identity of the originator can be related to the
			information.
10.	Q.RECEIPT	FCO_NRR.2	This requirement ensures that the TOE generates
			evidence of receipt for transmitted public key
	The TOE must generate evidence of		certificates:
	receipt fortransmitted public key
	certificates.		FCO_NRR.2 ensures that evidence of receipt is
			generated automatically for public key certificates
			received via SEP or PKIX-CMP.

 

The certification report indicates that Entrust/RA provides both SFRs: FCO_NRO(2) and

SFR_NRR(2) (Section O).

 

This implies, given the criteria, that 'the sub-protocol in PKIX-CMP for returning the

necessary evidence of receipt of a public-key certificate' is "correct".

 

This implies that, should any "user data" be attached to the message that

delivers the certificate via PKIX-CMP, and the automatic receipt is

generated, then there is now, a citable method for NR for arbitrary data.

Any protocol using receipt-evidentary methods compatible with PKIX-CMP can

now realistically get certified as doing "proof of receipt with non-repudiation."

It would be fascinating to know if the PKIX-CMP certificates involved have the

NR bit set, in practice. Perhaps the Entrust ITSEC engineers will tell us.

Set or not set, there are interesting implications of the certification

report due to the design of PKIX-CMP "receipt-oriented" security services.

 

The CC do say, in informational annexes that:

 

"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."

 

I have not found the words in the Entrust ST which satisfy this requirement,

yet. When we do, we can see some of the legal implications.

 

We seem to be making some concrete progress on NR, both technical

and legal, thanks to the world of public disclosure of STs.

 

Peter.

 

 

 

-----Original Message-----
From: Peter Williams [mailto:peterw@xxxxxxxxxxxx]
Sent: Friday, April 20, 2001 12:06 PM
To: 'Tom Gindin'
Cc: ietf-pkix@xxxxxxx
Subject: RE: Meaning of Non-repudiation


When NIST?NSA folk evaluate a US network product/system, formally,
they must, traditionally, use the following conceptions of NR.
(Steve's notions of subject intent, and presumptions of signature
binding, are not relevant to a formal evaluation of a product/system
claiming to provide NR.)

It would be useful for some of our friends from NCSC/NIST
to perhaps find an actual evaluation/certification report
that certified an actual network product/system as meeting the
evaluation criteria for NR. This would provide us
with an example protocol under the Red Book
that was deemed "correct", as required by the criteria.