notary-requirements review on 64th IETF

["Andreas U. Schmidt" <[e-mail]>]

Hello,

on the meeting we will present a short review of
draft-ietf-ltans-notareqs-02.txt. What follows is
a long-text version of that contribution. Find the
corresponding slides attached.

So far, the requirements are rather generic and
unspecific, and remain largely on a conceptual and
non-technical level. I think this is mainly due to
a too broad spectrum of potential applications,
which lead us only to generic, high-level use-cases.
Though this generic approach seems necessary in
order to not exclude important applications, it creates
some problems for further proceedings. In particular,
the demarcation of the scope of LTANS standardisation
of certification services, i.e., what part of reqs to be
turned into specs, remains vague. We seem to need
- More reqs that make contact to specs (beef up Section 5),
- some more operational & security reqs outside specs proper
to delineate its scope and give users a hint how to apply
the specs safely.

 From work on electronic conversions/transformations we
distilled some base requirements, some of which may be
applicable to to enrich ltans-notareqs.

1. Technical solutions are desirable
In most applications, ever more complex operations on/workflows
with E-Docs are to be attested by the envisaged services.
Therefore standardised technical proceedings should be used
primarily to mitigate human error in these contexts
-> This could be an additional motivation and fit into Sec. 1 or 2

2. Agreement of contents
That the content of the 'certified' document should agree to some
determined degree with that of a certain source document is a
requirement which is specific to use-cases like transformations,
format conversions, partial copies, attested translations,
-> This could be used to enhance and specify Sec. 5.1;
In particular, it should be stated that the assertion supported by a
certification must qualify its meaning at some point
(here ‘contents agree to the desired level’)
-> It is in turn also an operational requirement; The necessary degree
of agreement/correlation is determined in the context of the use-case,
again one needs a space to note and record this desired degree of
agreement.

3. Authentication of authorship
Signers of originals must be authenticated and auth. results recorded
in the process of certification
-> This is present in 5.4
-> Maybe one should take note that this kind of authentication is
hardly ever done in the context of notarisation of paper docs,
the necessity arises with use of otherwise anonymous technical
services
-> It entails an operational requirement, namely that the use-case
determines verification policies and one needs a space to record them.
The latter should be mentioned in Sec. 5.4

4. Data Integrity
-> Maintenance of data integrity is present in Sec. 7;

5. Attribution of certification and authorisation of the certifier
What is attested must be authenticated by a signature. Additionally, 
identity,
role (e.g. notary public, public official, authorised translator), and
her authorisation by the certifier can be of importance. Again, the proper
credentials are determined by use-case
-> Something to that end is presently buried in 5.1 last sentence.
Maybe we'd better explicate/expand
-> Note: Application of attribute certificates suggests itself;
Should capabilities to handle them and a space to contain them be
technical reqs?

6. Data protection and secrecy
Personal and other data must be collected in the course of operation of
cert. services but must not be disclosed to unauthorised parties.
However, it may sometimes be necessary for the service to keep records
containing personal data. Where applicable those should be kept encrypted
-> This seems to yield some points for Sec. 7

7. Retraceability and logging
This has three main aspects
a) The certification must keep a record of proceedings (esp. for
transformations) to enable forensic evaluation;
b) integrity of the protocol is to be assured during proceedings.
c) Retraceability must be possible independently of the cert. service
(in both technical and organisational sense)
-> a), b) are not yet present and would fit Sec. 5,
-> c) seems a rather important operational requirement to foster
trust in cert. services

8. Independent evaluation and certification of certification services
by independent or even public authorities.
Given the complexity and high security demands,
this seems an important req for the trust in such services
-> possibly a high-level note for Sec. 7, but maybe outside scope

I think from these and the points already present in the
requirements document, we can already generate some more
specific, yet still general requirements for data structures
used by certification services. In particular, those structures
should be flexible and extensible to support further development
and security levels, and they should be able to represent the
assertion of a certification service including, e.g., the identity
of participants, credentials of the certification service, etc.

In the context of electronic transformations we specified data
structures to meet these requirements. The highest level of these
concepts may be applicable to general certification services.
The main concept is that of a
+ Sealed Data Container
carrying a
+ Data Container containing the data to be attested and an
+ Electronic Seal attesting the integrity and authenticity
of the data container’s content and the correctness of the
proceedings.
Both are bound together by a signature

In turn the Data Container holds
+ Final Results, consisting of, e.g., documents like contracts,
agreements, oaths, etc.,
+ Report Data, in particular a documentation of the operations on
the original document, like data processing protocols, used components,
and parameters, acting parties, etc. It also holds, to enable 
retraceability,
intermediate results, like signature verification and authentication 
results,
(and used verification policies).
The data container thus provides for retraceability of data processing
and communication between parties, and authentication of authorship 
(signers).

Finally, the Seal holds an
+ Annotation consisting of (e.g.) Name(s) of signers of documents,
credentials of the certification service and its operators, 
authorisation & role,
date and time at which the service was performed, and of the 
certification, and
information on what is attested, e.g. the correctness of a transformation.
Secondly the Seal contains a
+ Signature which signs annotation and data container and has the usual 
components
signature, certificate and possibly attribute certificates
The Seal explicates the meaning of the assertion, e.g. all parties 
agreed to
a final document. It finally provides trustworthiness of the assertion,
and data integrity and authenticity of the annotation and the data 
container.

Please comment.
AUS