Subject: I-D ACTION:draft-ietf-pkix-okid-01.txt

From: [email-masked]
Date: Fri, 01 Mar 2002 07:06:56 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Out-of-Band Certificate and Key Identifier Protocol 
                          (OCKID)
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-pkix-okid-01.txt
	Pages		: 
	Date		: 28-Feb-02
	
In general, certificates need not be communicated with communication or
storage media that are integrity-secure or authentic. This is because
certificates are digitally signed and users are expected to validate the
signatures using configured trust anchors. However, distribution of
trust anchor certificates, self-signed end-entity certificates, or bare
(unsigned) public keys requires a mechanism for establishing the
authenticity of the certificate or public key.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-okid-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-okid-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-okid-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 14 Mar 2002 18:19:03 +0100

Paul,

You made quite a good job, with this new specification since the hash is now
computed over the whole certificate instead of the public key only.

A few comments:

1. Editorial. Choose either OKID or OCKID. 
   I don't care as long as there is a single acronym.

2. I have some concerns with section 4 when it states:

Because the result of matching the OCKID to the CA certificate is that
the certificate will now become a trust anchor, the system MUST inform
the user of each of the following: 

- That the certificate has become a trust anchor

- The policies used by the issuer of this certificate to issue
subordinate certificates ([PKIX] section 4.2.1.5)

- The basic constraints placed on the issuer of this certificate, such
as the depth of subordinate chain that can be issued under this
certificate ([PKIX] section 4.2.1.10)

- The types of names for which the issuer of this certificate can create
certificates ([PKIX] section 4.2.1.11)

- The policy constraints placed on the issuer of this certificate
([PKIX] section 4.2.1.12)

The system SHOULD give the user a method for later removing the trust in
the CA certificate. The system MUST also check whether the certificate
is properly signed, that is, that the public key in the certificate is
in fact correctly verifies the contents of the certificate.

End of extract.

In most cases the user will only verify that the intended hash matches the
computed hash and will install the self-signed certificates. Controls like
checking the signature of the certificate may be recommanded but should not
be mandatory.

Hence I would propose a text along the following:

"Because the result of matching the OCKID to the CA certificate is that the
certificate will now become a trust anchor, the system MUST inform the user
that the certificate has become a trust anchor.

The system SHOULD give the user a method for later removing the trust in the
CA certificate. 

It MAY provide additional information to the user like:

- The policies used by the issuer of this certificate to issue subordinate
certificates ([PKIX] section 4.2.1.5)

- The basic constraints placed on the issuer of this certificate, such as
the depth of subordinate chain that can be issued under this certificate
([PKIX] section 4.2.1.10)

- The types of names for which the issuer of this certificate can create
certificates ([PKIX] section 4.2.1.11)

- The policy constraints placed on the issuer of this certificate ([PKIX]
section 4.2.1.12)

The system SHOULD also check whether the certificate is properly signed,
that is, that the public key in the certificate is in fact correctly
verifies the contents of the certificate."

Denis

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 14 Mar 2002 09:42:13 -0800

>    I don't care as long as there is a single acronym.

Yipes! I thought I had done it everywhere except in the draft name; 
turns out I missed a bunch. (And I left it in the draft name so I 
didn't have to recycle at -00...).

>verifies the contents of the certificate."

So, here is where we get into the discussion of enforcing good 
security policy. My wording had the bulleted list as MUSTs. You have 
reduced them past SHOULD to MAY. The result of this is that few 
implementations will tell end users the effects of what they are 
doing (a SHOULD would probably do more).

I think this reduction is dangerous in that it does not tell the end 
user enough about the effects of her or his actions; other people 
would say that it is not our responsibility to insist on telling the 
end user this.

Quite frankly, there are probably lots of implementors who use PKIX 
toolkits who don't realize all the ramifications of using a trust 
anchor are. Forcing them to tell their users will make them much more 
aware of their responsibility.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 14 Mar 2002 19:03:36 +0100

Paul,

Thank you for your *very* quick answer.

(some text deleted)
 
> aware of their responsibility.

Many people do not have your or my education in PKI. They are told to
install a new root. They only need to know how to install it properly. They
do not even know which key they are installing. They got a URL where to
fetch the self-sigend certificate and then must be sure that what they get
matches the hash. That's all. They have not the simplest idea of what means:

 - the policies used by the issuer of this certificate to issue subordinate
   certificates,

 - the basic constraints placed on the issuer of this certificate, 

 - the depth of subordinate chain that can be issued under this certificate,
 
 - the types of names for which the issuer of this certificate can create
   certificates,
  
 - the policy constraints placed on the issuer of this certificate.

I believe that the debate should now be between SHOULD and MAY.

Denis

---

From: "Max Pritikin" <[email-masked]>
Date: Thu, 14 Mar 2002 10:49:49 -0800

Possibly the end user MUST be informed of the new trust anchor and MUST have
the bulleted items *available* for inspection but only MAY be actually
informed of them.

Thus Paul's point is addressed; that the information is important and really
must be examined and handled -- implementors are coerced into paying
attention to it ("MUST be available"). Denis is correct though that many
users will only be confused by the additional information and thus they only
examine it when needed.

	- Max

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Denis Pinkas
> Sent: Thursday, March 14, 2002 10:04 AM
> To: Paul Hoffman / IMC
> Cc: pkix
> Subject: Re: I-D ACTION:draft-ietf-pkix-okid-01.txt
>
>
>
> Paul,
>