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

From: [email-masked]
Date: Wed, 30 Jan 2002 07:02:15 -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 Key Identifier Protocol (OKID)
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-pkix-okid-00.txt
	Pages		: 
	Date		: 29-Jan-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, or distribution of self-signed end-entity
certificates, requires a mechanism for establishing the authenticity of
the public key contained in such certificates.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-okid-00.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-00.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-00.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: Stephen Farrell <[email-masked]>
Date: Wed, 30 Jan 2002 14:37:14 +0000

Paul,

There's a similar scheme in the WAP forum's WPKI spec ([1], at the
end of section 7.1.3) that you might want to look at. I guess 
similarities between these two would be no harm, though I don't
feel strongly that they should/must be the same.

One feature of that spec is the inclusion of check-digits [2] so 
that the punters don't end up typing much after they've made an 
error and so that they don't hit the "mistrust" button just because 
of a typing error. I think this'd be useful to include, though
of course it makes things a bit longer.

Also - does your hash include the algorithm parameters & if not,
is that ok?

Only other comment is why is "protocol" in the title? Seems
a bit strange, but heh...

Regards,
Stephen.

[1] http://www1.wapforum.org/tech/terms.asp?doc=WAP-217-WPKI-20010424-a.pdf
[2] http://www.beachnet.com/~hstiles/cardtype.html

-----------------------------------------------------------------------------
Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 30 Jan 2002 08:44:33 -0800

>feel strongly that they should/must be the same.

Sorry, but that link takes me to a page with a legal agreement that I 
cannot meet. So, no, it is not appropriate to use their spec. If the 
WAP Forum decides to let people read and reference their documents 
without first making a legal agreement with them, I'll reconsider 
this. <sheesh>

>of course it makes things a bit longer.

Um, how does a check-digit help with either problem? The check digit 
can say whether or not you typed in the rest of the string correctly, 
but it can't say what you should change if you typed it incorrectly. 
So it is just an extra character or two that would give a second kind 
of response: "you typed the rest of this wrong".

>Also - does your hash include the algorithm parameters & if not,

No it doesn't include it; the OKID document clearly says it is over 
the public key only. I was thinking about RSA keys. The algorithm 
parameters should also be hashed. I'll fix this in the next draft.

>a bit strange, but heh...

Because it is a standard encoding for communication.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 30 Jan 2002 17:22:03 +0000

Paul,

> cannot meet.

Bummer. Never mind though - there really is a similar scheme behind
the legal nonsense. Interestingly, the URL below [1] gives access to 
a remarkably similar document without having to read license crud. 
(Maybe that's a secret though:-)

> Um, how does a check-digit help with either problem? 

Make every n-th digit a check-digit, that way s/w can stop the user
more quickly. I hate to type a long random string only to find out 
after typing and checking 30 digits, that the 1st character was 
wrong. Does make strings longer though all right.

Without a check digit the user has no way to distinguish the typo
case from the bad public key value case. I'd say that makes it more
likely that the user hits the "mistrust" button needlessly. ("Hey,
that public key you sent me is bad - it didn't match the okid I
typed in - maybe you should turn it off too.")

> parameters should also be hashed. I'll fix this in the next draft.

Watch out for inherited parameters (from the superior CA cert). Hard
to see a good way to handle those. Not sure if a "well known" curve
value would be ok either - wouldn't the punter have to validate that
oob as well, or is the probability of cheating so small in that case
that we can ignore it?

Stephen.

[1] http://www1.wapforum.org/tech/documents/WAP-217-WPKI-20010424-a.pdf

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 30 Jan 2002 10:07:54 -0800

>(Maybe that's a secret though:-)

We cannot use documents with these kinds of restrictions in the IETF. 
If you really want us to pursue this, we need to talk to the IETF's 
liaison to the WAP Forum.

But I don't think there is a reason to pursue this. I believe that 
the proposal I made (16 alphabetic characters broken into four groups 
of four) is significantly friendlier than the one that WAP is using 
(30 digits broken into five groups of six digits). Let me know if you 
disagree.

>more quickly.

Correct.

>  I hate to type a long random string only to find out

We are talking 18 characters, not 30, and the first two will be simple.

>case from the bad public key value case.

Please look at where OKID is being used. If the user gets a bad 
public key value from the out-of-band communication, the user can 
query the sender of the OKID ("could you read me that again"). Given 
the essential impossibility to forge OKIDs, the user will know that 
either they have mistyped something or that they are under a very 
amazing attack.

>  I'd say that makes it more

That scenario won't happen. You can compute the OKID on any cert you 
have in front of you; the OKID is not part of the cert.

Do other people think that the value of adding check digits is worth 
the cost (making the OKIDs longer and therefore less friendly)? In 
order to keep the symmetry of groups of four characters, we could add 
four check digits, making the string 22 characters instead of 18. 
Personally, I think it isn't worth it, but two people here (one 
off-list) have said they like the idea.

>Watch out for inherited parameters (from the superior CA cert).

OK, I'm no expert on DSA and Diffie-Hellman, but how does one get 
inherited parameters in a self-signed certificate?

>  Hard
>to see a good way to handle those.

Disallow certs that would have them.

>  Not sure if a "well known" curve

A good question for the cryptographers.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Al Arsenault" <[email-masked]>
Date: Wed, 30 Jan 2002 13:22:55 -0500

Paul,

    Do you (or Steve K., Russ or Stephen F. for that matter) know of any IPR
issues with this?  In the WAP Forum, Entrust claimed that they had IPR (a
patent application on file in the US) that covered this sort of thing.

            Al Arsenault
            Chief Security Architect
            Diversinet Corp.

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 30, 2002 9:37 AM
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt

> [1]
http://www1.wapforum.org/tech/terms.asp?doc=WAP-217-WPKI-20010424-a.pdf

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 30 Jan 2002 10:47:05 -0800

>patent application on file in the US) that covered this sort of thing.

I don't have any direct knowledge of any IPR. If Entrust has a patent 
or an application that might affect this, Carlisle Adams might be the 
best person to ask.

--Paul Hoffman, Director
--VPN Consortium

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 31 Jan 2002 17:11:00 +0100

Paul,

It is a good initiative that I welcomme.

However, I have strong reservations on this first draft.

1) The current document addresses only the verification of self-signed
   certificates, but is subject to security attacks (i.e. substitution 
   of self-signed certificates) because only the hash of the public key 
   contained in the self-signed certificate is verified: this would mandate 
   that a CA is not allowed to issue more than one self-signed certificate 
   with the same public key in it, which is indeed a restriction that is 
   not acceptable.

   So the document should be changed to consider the hash of the certificate
   instead of only the hash of the public key (and of the algorithm
   identifier).

   If we do so, then the "protocol" will also be usable for any type of
   certificate, not only self-signed certificates.

2) The abstract should rephrased as:

   The Out-of-Band Key Identifier Protocol (OKID) is a user-friendly
   out-of-band way to install certificates.

Denis 

>   ----------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <[email-masked]>

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 31 Jan 2002 11:53:46 -0800

At 5:11 PM +0100 1/31/02, Denis Pinkas wrote:
>    contained in the self-signed certificate is verified:

Correct. I have yet to hear of an interesting attack where Mallory 
has some good reason to substitute "Alice A" for "Alice B" on Bob's 
system when "Alice A" and "Alice B" are both self-signed.

>  this would mandate
>    with the same public key in it,

Where in the document did it say this? CAs and non-CA self-signers 
are allowed to do whatever they want.

>  which is indeed a restriction that is
>    not acceptable.

Agree; that's why it doesn't say it.

>    instead of only the hash of the public key (and of the algorithm

You then make Mallory's job many orders of magnitude easier. Instead 
of having to create 2^79 key pairs, he only has to create 2^79 hashes 
looking for one that matches Alice's OKID. That doesn't seem like a 
good security choice, particularly because we can assume that it is 
more likely that people will work on hardware hash acceleration than 
they will on hardware key generation.

>    certificate, not only self-signed certificates.

Correct, but at the cost of making the protocol much easier to break.

>    out-of-band way to install certificates.

Disagree. This protocol does not install certificates. It helps with 
only one step of that process.

--Paul Hoffman, Director

---

From: Dr S N Henson <[email-masked]>
Date: Thu, 31 Jan 2002 21:55:13 +0000

I have a few comments on the first draft. They all are roughly based on
whether 80 bits of SHA1 hash is sufficient.

Assuming that the current drafts method of hashing the public key only
is used then various optimizations could be performed to generate large
numbers of private keys. One way be to generate a large number of primes
and generate keys by selecting pairs. This would involve the generation
of ~2^40 primes and ~2^80 multiplication operations to generate each
key. Use of multi-prime RSA would reduce the number of primes that would
need to be generated further.

In any case this would seem to imply that the limiting factor in such an
attack would no longer be the speed of private key generation but the
speed of computing around 2^80 SHA1 hashes.

Could someone comment on whether such an operation is beyond the reach
of current technology?

Second issue is if Alice could gain anything by performing a birthday
attack (which would involve considerably less resources) and generating
two certificates with the same OKID.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [email-masked] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 01 Feb 2002 00:28:52 +0100

Paul Hoffman / IMC wrote:

> looking for one that matches Alice's OKID.

No.
Clearly  if finding a collision does not suffice for Mallory in the first case,
but that he has to find a collision for valid data, in that case a valid key, then
in the second case, he also has to find a collision for valid data, therefore a
valid certificate.
And the second case is as a minimum as difficult as the first, because there must
be a valid key inside the certificate.

If just finding a collision is dangerous, not matter if the data it comes from can
be parsed as valid, then the two cases are perfectly equal.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 31 Jan 2002 17:03:15 -0800

>be parsed as valid, then the two cases are perfectly equal.

We disagree here. Given Alice's OCID (it is now a cert ID, not a key 
ID), Mallory creates a template certificate with his own public key 
in it. In the template, he adds an extension that has an octet stream 
of length 10. He then cycles through all the combinations of 2^80 
values in the octet stream until the hash over the template 
certificate matches Alice's OCID, signs the cert, and is done.

Mallory does *not* need to change the public key in an OCID: he can 
change any value in the certificate to get the right hash.

--Paul Hoffman, Director