Ian Brown <I(_dot_)Brown(_at_)cs(_dot_)ucl(_dot_)ac(_dot_)uk> writes:
Hal Finney <hal(_at_)rain(_dot_)org> writes:
PGP now offers an extensible signature format. This allows key
signatures, both self-signatures by a key on itself, and ordinary key
signatures by keys on other keys, to do more than before. The extensions
are in the form of subpackets within the signature packet. Various
subpackets have been defined, and Open-PGP would be an excellent forum
to propose and design new subpacket types and corresponding data formats...
Other subpacket types are intended to be used with self-signatures,
allowing a key to make assertions about itself.
OK, just re-spotted this in Hal's post. This is obviously the place for
a key to assert that it is to be used for transient message encryption,
signing or (recovery-enabled) storage - or other purposes, as Adam's
message about Norwegian standards suggested. Can we discuss and design
such a sub-packet now?
Sounds like the correct place for them to go.
How are PGP's signature and encryption keys usages currently
differentiated? Do they use the sub-packet type in the self-signature
mechanism?
One problem which will need to be worked out is what will it imply for
interoperability if some implementations can understand more
sub-packet types.
Say that some Norwegian people wanted to use OpenPGP to implement to
their standard which defines the 5 key purposes I listed, does that
mean that all PGP versions have to understand them all to interperate?
Or can we get away with some minimum set for WILL implement, with the
remainder being MAY implement, where implementations are defined to
flag keys with unrecognized key types as beyond their ken.
My vote for a minimum set would be the 3: signature, encryption and
storage.
What would be the effect on behaviour of implementations which chose
not to implement say authentication and certification keys defined in
the Norwegien standard when they received messages using such key
types.
Now that I've dug out a copy of the document I was referring to, I'll
provide you with the desired security functions they list. (The keys
and their functionalities required to implement it aren't in this
document):
It's I think part of "EEMA", you may be able to find that with a web
search, or some may be familiar with that acronym. The document
doesn't really identify itself properly -- it's some kind of draft
working document which was passed around at another standardisation
meeting for background. There is more to it, I've just extracted
their summary security functions definitions:
: - Authentication
: - Authorization
: - Notarized Authorization
: - Non-Repudiation of Content Received
: - Confidentiality
Where these are defined later on as:
: - Authentication: Authentication gives the recipient guarantees of the
: accuracy of an object, the identity of it's originator and optionally,
: it can assure that the originator cannot repudiate having originated
: the object. It shall not be used for, nor be interpreted to be a
: legally binding contractual commitment to the informatino content of
: the object.
:
: - Authorisation: Authorisation provides all of the protection and
: guarantees defined for Authentication. In addition, it provides a
: means for the originator to express a contractual binding to the
: information content of an object. The meaning of the contractual
: binding is expressed by the information content of the object itself -
: eg if the information is a contract, the Authorizatino function is
: used to `sign' the contract. If the information is a command, the
: authorization signals the recipient to carry out the command.
:
: Notarised Authorisation provides all of the protection and guarantess
: defined for Authentication and Authorisation. In addition, it
: provides a long term proof of origin and contractual binding of
: originator to information object. This is achieved by using the
: services of a trusted third party (eg. a Notary) which securely
: attaches an accurate time stampt to the object.
:
: Business Scenario - users wish to exchange a long term documents (eg
: an agreement or contract) which will outlast the validity time of the
: private key used to uathorise the document.
:
: Non-repudiation of Content Received: this function provides a secured
: acknowledgement of receipt of a secured object. It provides object's
: originator with:
:
: - guarantees of intact delivery of the information object;
: - irrefutable proof of the identity of the recipient
:
: Confidentiality: The confidentiality function allows the originator to
: conceal the information contained in an object so that only the
: indended recipients can access the original information.
Anyway, those functionalities should give y'all a flavour for the
kinds of things different countries would like to define as legally
understood security functions. They do actually look quite useful,
and I was quite impressed with the thought that went into the argument
for notarized (time-stamped) signatures on long term contracts with
longer expected life-time than the signatories keys.
I'm not suggesting we go ahead and do anything about these functions,
as that kind of thing will surely have to come after some major
international standardisation efforts agreeing on legal definitions.
But I hope it is useful to read, and perhaps other people can throw in
some other definitions from other countries signature standards
processes to give us a feel for the kinds of signatures people might
want to use.
Adam
--
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/
print pack"C*",split/\D+/,`echo "16iII*o\U(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`