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

From: David Hopwood <[email-masked]>
Date: Sun, 03 Jul 2005 03:11:27 +0100

[resend due to "only members can post" on ietf-pkix]

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 <[email-masked]>

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 7 Jul 2005 10:32:39 +0200

David Hopwood wrote:

<snip>

>using a single certificate ensures that loss or compromise of one

The use of the word "problem" is not entirely correct, I would rather
say that this usage *solves* a number of serious real-life problems
that will face a future PKI-enabled user.

Compromise (=theft/loss): ONE revocation and all
associated services are blocked.

Recovery of lost IT-life: ONE renewal/RA process and you are back.

Economics: To pay for having a passport-like ID seems reasonable
if you have multiple uses.  This is probably also a pre-requisite for
creating globally working CA/RA networks.

Company or national CA networks including the US PIV-program
do not address these issues.

<snip>

Sincerely
Anders Rundgren

---

From: Stephen Kent <[email-masked]>
Date: Thu, 7 Jul 2005 10:03:36 -0400

Anders,

I refer you to a report by the U.S. National Research Council, 
entitled "Who Goes There? Authentication Through the Lens of 
Privacy."  The report was issued almost 2 years ago and it strongly 
recommends against the single cert per user model, for both privacy 
and security reasons.

Steve