Re: Last Call: 'Required functions of User Interface for the Internet X.509 Public Key Infrastructure' to Informational RFC

[David Hopwood <david.nospam.hopwood at blueyonder.co.uk>]

Re: http://www.ietf.org/internet-drafts/draft-choi-pkix-ui-03.txt

Dave Crocker wrote:
> > - 'Required functions of User Interface for the Internet X.509 Public Key
> > Infrastructure '
> > <draft-choi-pkix-ui-03.txt> as an Informational RFC
>
> RFC document titles should not carry language that states or implies that their 
> contents mandate conformans.
>
> Hence, the word "Required" should be removed from this document title.
>
> The issue is only exacerbated by the fact that it is seeking non-standards 
> status.

Also, the document has received no review in Working Groups for which it is
relevant, such as TLS and PKIX (there are references to its existence in the
PKIX archives, but no discussion). It seems to have been in desperate need
of such review:

#  Compatibility shall be accomplished for using one certificate to many
#  PKI applications. Generally, PKI application such as the Internet
#  Banking or E-mail application defines the user's certificate and
#  private key location by their own way. Thereby, when using those
#  applications, users are at a loss whenever receiving a question where
#  their certificates are. Most users do not know the answer, and they
#  want to use different PKI programs with their own certificate without
#  answering the question. It comes true as a certificate sharing
#  function and transfer function that mainly aim for increasing
#  certificate compatibility, which benefits the user's convenience.

The grammar here, and elsewhere in the document is bad enough to obscure
the meaning. More importantly, the argument given is inadequate motivation
for "using one certificate [for] many PKI applications":

 - the described usability problem could be solved even with multiple
   certificates
 - it is not clear that, in the situations where user certificates
   are typically used, implicitly selecting a certificate rather than
   prompting the user to select one would be a good thing
 - there are privacy implications of using a certificate for multiple
   applications, which are not discussed in the document
 - different relying parties may have requirements, for example on the
   algorithms used and on optional cert fields, that cannot be met by a
   single certificate
 - using a single certificate ensures that loss or compromise of one
   private key necessarily implies loss or compromise of the user's
   identity for many different applications. (This problem is not solved
   just by using multiple certificates, but at least it is not precluded
   from being solved.)

#  For example, a common storage location of a user's certificate and
#  private key in HARD DISK driver of different operating systems can be
#  assigned to be:
#
#      - MS  Windows :  C:Program Files/IETF/PKIX
#      - Linux/Unix  : (User Account)/IETF/PKIX
#      - Mac OS X    : (Hard disk label):Library/IETF/PKIX

Is this a joke? It ignores, at least, the fact that MS Windows and
Mac OS X are multi-user operating systems, and existing conventions for
where user certificates are stored.

#  Lastly, the user interface shall contain certificate management
#  commands as followings;
#
#      - Integrity verification function of trust anchor : defined in
#        [2.2.1]
#      - Import and export : defined in [2.1.2]
#      - Certificate verification : when a user wants to know whether
#        his or her certificate is valid or not

Valid for what purpose? User software *cannot* validate the cert in
a way that is guaranteed to match the validation result of any relying
party; it doesn't have enough information.

The Security Considerations section is totally inadequate. As an example,
consider this statement:

#  The PKI client software must provide a secure method to update PKI
#  client software and trust anchor's certificate. This document defines
#  it as automatic update function, which makes user involvement
#  minimized.

which has security considerations that are left entirely unaddressed.
(Just saying "a secure method" doesn't mean anything: How should it be
secured? Who should be trusted? What happens if keys are compromised?)

In summary, the document is not of adequate quality for publication as
an Informational RFC. It is not clear that anything useful is salvageable
from it.

--
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf