//////     //////    //\\         ELECTRONIC FRONTIERS AUSTRALIA
    //         //        //  \\        E-Mail:   secretary@efa.org.au  
   //         //        //    \\       URL:  http://www.efa.org.au 
  /////      /////     /////\\\\\      Fax:   08 295 6155
 //         //        //        \\     Phone: 08 384 7316 (+618) 
//////// * //      * //          \\ *  PO Box 382 North Adelaide SA 5006

3rd June 1996


Mr. C. Lim
Standards Australia
PO Box 1055
STRATHFIELD  NSW   2135
Fax:  (02) 746 8450

Re:    DR 96078

Title: Strategies for implementation of a Public Key Authentication 
       Framework in Australia.

Dear Sir,

Further to our fax of 31st May, attached are the comments of Electronic
Frontiers Australia (EFA) on the abovementioned draft standard.

If there are any questions concerning this submission the undersigned 
may be contacted on (07) 3370 6300.


Yours faithfully,




Greg Taylor
for Cryptography Committee
Electronic Frontiers Australia

Electronic Frontiers Australia (EFA)

Comments on draft standard DR 96078

GENERAL COMMENTS

EFA supports the general PKAF structure proposed in the draft standard. We appreciate the opportunity to comment on the draft but would like to make a general suggestion that draft standards, particularly those relating to electronic media and services, should be made available on-line so as to reach the widest possible audience.

Our general comments on the draft are:

• there needs to be a clearer statement that the key pairs involved in PKAF are designed for digital signature certification only. The use of private/public key pairs is also necessary for data encryption and there needs to be a clearly communicated understanding that these are entirely separate issues. This matter is alluded to in the very last part of the document (Appendix F.4) but in very confusing and contradictory language. We recommend that a clear distinction be drawn in the Introduction. It is also suggested that any such clarification should include a recommendation that separate key pairs be used for encryption and certification.
• the standard makes reference to certificate expiry dates. This matter perhaps needs some expansion since it not clear where responsibility for determining expiry lies, i.e. whether it is a user choice or a mandated period of time determined by the relevant CA and the intended usage.
• EFA strongly endorses the concept of user generation of key pairs as an important option to be available to users. Obviously this raises questions of "approved" methods of key generation. However, the legal framework of responsibility and liability in the event of key compromise is as yet unclear. Does, for instance, the user have similar cause for repudiation of a disputed transaction as he/she might have with a credit card transaction? The extent to which the user bears absolute responsibility for key protection and liability in the event of key compromise will have a bearing on this issue.
• The next best alternative to user key generation would be to use a key pair generated in an approved way, but via a third party using an audited and tamper-proof key generation facility. We have considered ways in which this might be achieved but further analysis of the problem will be necessary before we could suggest a particular approach.
• The concept of a non-statutory body to administer PKAF is endorsed but we would prefer to see more emphasis on this point.
• The question of whether PKAF certification can be made compatible with all potential digital signature standards needs to be addressed. As an example, the PKAF hierarchic structure of trust rooted in a national authority seems seriously at odds with PGP's `web of trust' idea, i.e. users certifying one another in a non-heirarchic structure. Can a Web of Trust system coexist with PKAF in some way, albeit with a lesser legal standing?
• The standard should be explicit that under no circumstances will CA's keep a copy of a private key. To do otherwise will destroy any public confidence in the system. To this end of maintaining public confidence, the standard should also explicitly deal with the question of other nations' root authories which might allow for CAs to keep a copy of a private key. The standard should optimally state that the PARRA will not interoperate with any root authority which allows private keys to be kept by CA or any other person or organisation other than the owner of the private key. Alternatively it should mandate that any key certificates obtained from such a root authority should mark the certificate as having come from a system which does not give the same level of gaurantee that the private key is secure, and under those circumstances the recipient need be under no obligation to accept the signature.
• Since new algorithms might involve keys of longer lengths than existing ones, the PKAF and its associated databases will need to cope with keys of aritrary length
• The privacy aspects of signature validation are not well defined. We believe there should be a clear statement that validation of a certificate is limited to certifying that a particular entity is bound to a specified unrevoked signature, i.e. it should not be possible to perform a "reverse" enquiry on the directory structure and determine if a particular entity or individual is listed.
• The need for "unlisted certificates" (p.59) is strongly endorsed.
• We concur with the preferred PKAF architecture option (p.38).

SPECIFIC COMMENT

p.10, Clause 2 (generally)
The Definitions do not include a number of key terms which are referred to in the text, often before the term is explained. The main terms are: PARRA, ICA, OCA, ORA, CRL, PCA (?)

p. 12, Clause 2.11
"Public Key Certificate" is defined here, as is "Certificate" in Clause 2.1 on p.10. Is one of these terms redundant?

p. 14, Clause 3.1.3, line 11
The term PCA appears here. This term does not appear to be defined or used elsewhere.

p. 15, Clause 3.1.6
Change "pubic keys" to "public keys".

p. 17, Clause 3.2.1, line 4
Change "chat" to "that"

p. 17, Clause 3.2.2
Some allowance may need to be made, perhaps with limited legal standing, for "Web-of-trust" certification systems such as those commonly associated with PGP.

p. 18, Clause 3.2.6
The construction of the first sentence is faulty.

p. 19, Clause 3.3.1, lines 1-2
"Approved method" needs elaboration. It is not clear where in the standards infrastructure approval responsibility would lie.

p. 19, Clause 3.3.1, para 3, line 7
"Perhaps it is of less concern ...." This sentence is speculative and does not appear to belong in a standards document. It might be reworded as "It may be of less concern".

p. 19, Clause 3.3.1, para 4, line 1
Suggest change to "The PKAF must"

p. 20, Clause 3.4.4
Sentence construction faulty in both sentences.

p. 20, Clause 3.4.6, line 2
The term "public server" needs elaboration, perhaps elsewhere in the document.

p. 21, Clause 3.4.7, line 2
"about to expire". The expiry term of a certificate, and responsibility for determining same, needs further explanation elsewhere.

p. 21, Clause 3.4.8, line 1
The term "out-of-band", although understood, needs definition.

p. 21, Clause 3.4.10
The term "Directory" appears here. In clause 3.4.6 CA's are designated as responsible for forwarding certificates to a "public server", whereas CRL's are distributed to a "Directory". The terminology appears to need some tidying up so that the same terms are used where the same meaning is intended.

p. 25, Clause 3.7.1, para 2, line 1.
"the PKAF can issue a single private/public key pair". This seems to imply that the PKAF is responsible for key pair generation. This should be an optional service.

p. 26, Clause 3.8.1, line 2
Change "user" to "users"

p. 28, Clause 4.3, line 1
Change "a as" to "as".

p. 30, Clause 4.12, sub-section (4)
It is questioned whether a CA needs to confirm that the key pair is functional, or indeed how it might go about doing this if key pair generation is optionally a user responsibility. Should not the CA's role be only to bind a public key to a particular user? Similar questions arise in relation to sub-section (2). If the user does not hold the corresponding private key, they will be unable to sign a document anyway.

p. 32, Clause 4.18, para 2, line 1
Change "photographic" to "photographs"

p. 32, Clause 4.18, para 2, last line
Remove apostrophe in "attestation's"

p. 32, Clause 4.18, para 4
Construction of both sentences is faulty and/or unwieldy.

p. 32, Clause 4.19
Safeguarding of a private key should be a user responsibility similar to the safeguarding of a cash card PIN no. It does not appear necessary to specify that access should require a password etc. since a breakdown in key security is potentially going to create a liability for the user.

p. 33, Clause 4.20, para 1, last line
The phrase "could not be unaware" is confusing. Perhaps "is aware" is the meaning intended?

p. 39, Clause 5.3, line 1
The reference to encryption capabilities here is questioned. Encryption should not be relevant to the authentication issue.

p. 43, Clause 6.1.3, 4th para
Change "Generate and publish" to "Generates and publishes".

p. 50, Clause 6.4.3, line 1
Change "Sub-OCA" to "Sub-OCAs"

p. 51, Clause 6.4.4, last bullet Change "actions a" to "actions"

p. 51, Clause 6.4.5, para 1
Faulty sentence construction.

p. 51, Clause 6.4.5, para 2
"token" may need to be defined elsewhere.

p. 56, Clause A.3
In relation to privacy of personal information, limits should be placed on what information is stored. It is not clear where in the standards structure this issue might be best addressed.

p. 58, Clause B.1.3.2, bullet 2
Remove "a such"

p. 59, Clause B.2, bullet 1
Change "a entity's" to "an entity's"

Appendix C

It is not clear whether this Appendix is meant to be included in the final standard. If it is, there are several places where the first person is inappropriately used in sentences. These instances are included below.

p. 60, Clause C.1, last bullet
Change "An digital" to "A digital"

p. 60, Clause C.2, para 1, line 1
Change "an digital" to "a digital"

p. 60, Clause C.2, para 1, line 7
The term "key pass" is not understood.

p. 60, Clause C.2, para 2, line 4
Change "I have suggested"

p. 61, Clause C.2, line 2
Change "draft" to "drafted"

p. 61, Clause C.2, line 3
Change "a entity" to "an entity"

p. 62, Clause C.5, para 1, line 3
Change "I have"

p. 62, Clause C.5, para 2, line 1
Change "we will"

p. 63, re X.501, line 3
Change "CovereC" to "covered".

p. 67, first para, line 5
Change "ProtecteC" to "protected"

p. 68, Clause F.4, para 2
It is suggested that the intent to clearly divorce PKAF services from data encryption would be better outlined in the Introduction to the Standard.

p. 68, Clause F.4, para 3
The reference to "secret keys, that can be distributed" is a mystery. Was it intended to say "public keys"? If the latter, the apparent meaning seems to be that PKAF might be used as an infrastructure to support public encryption key management. This entire section is very confusing, since on the one hand it states that PKAF has no role in data encryption, and on the other hand implies that there is scope for such a role. EFA believes that the use of the PKAF infrastructure to provide any kind of public encryption key management would be inappropriate and a confusion of its role.