headers
Paul Hoffman / IMC | 1 Feb 2002 02:03
Picon

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


At 12:28 AM +0100 2/1/02, Jean-Marc Desperrier wrote:
>Paul Hoffman / IMC wrote:
>
>>  >    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).
>>
>>  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.
>
>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.

We disagree here. Given Alice's OCID (it is now a cert ID, not a key
(Continue reading)

Permalink | Reply | 5 comments |
headers
Peter Gutmann | 1 Feb 2002 03:08
Picon
Picon
Picon
Favicon

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


Stephen Farrell <stephen.farrell <at> baltimore.ie> writes:

>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.")

That's more or less the reason why I went with check digits, people didn't want
to get fifteen levels deep into a transaction only to discover that the user
had typed the wrong value at the start, and without it there was no way to
differentiate between typos and genuine errors.

I have a full implementation of this if anyone wants it, it'll encode and
decode with check digits, you can specify how many groups of five you want as
output and it'll use that many bits.  There's also a verification function to
identify keys formatted in this manner.

Peter.
Permalink | Reply | 0 comments |
headers
Peter Gutmann | 1 Feb 2002 03:04
Picon
Picon
Picon
Favicon

Re: Comments on draft-ietf-pkix-okid-00.txt


[Redirected back to PKIX since there's another thread on this as well]

>>>(Note that all the characters are uppercase and that the characters "0", "1",
>>>"8", and "9" are not used.)
>>
>>Hmm, you still run into confusion over O and I.  I've been using:
>>
>>static const char codeTable[] = \
>>
>>       "ABCDEFGHJKLMNPQRSTUVWXYZ23456789";     /* No O/0, I/1 */
>
>We discussed this in the IDN context. We decided that it wasn't that
>important, but I might change it to your string.

I've checked this with users/developers and it was generally regarded as a Good
Thing.

>>You also probably want to checksum the values to detect users mistyping the ID
>>(which is not that uncommon) rather than the cert not matching.
>
>Disagree. These will be used in environments where there is communication
>between the parties, and the person who got the "wrong" calculation would
>simply go back to the person who sent it and say "this doesn't seem right".
>With a checksum, you go from good/bad to good/bad/mistype, and I think that
>three states are much worse than two.

The masses (or at least the "developers" part of the masses) seem to think
otherwise.  There was a strong demand for a means of checking that the user had
entered a correct value before anything further was done - that's why the code
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Gutmann | 1 Feb 2002 02:57
Picon
Picon
Picon
Favicon

Re: TSP interop update


Denis Pinkas <Denis.Pinkas <at> bull.net> writes:

>It is simmple: if a client requests a policy and if the server supports that
>policy, why should the server choose a different policy ? Just to annoy the
>client ?

What if the client prefers policy X, but will accept anything if that's not
available?  This is standard procedure for restaurants, libraries, ...

Twitchen: "We'll have the duck".
Fawlty: "Duck's off, sorry".
Twitchen: "We'll have the trifle then".

TSP however requires:

Twitchen: "We'll have the duck".
Fawlty: "You ponce in here expecting to be waited on hand and foot. Well, I'm
         trying to run a TSA here. Have you any idea how much there is to do?
         Go away".

Ah, we have an RFC which standardises Fawlty Towers.

Peter.
Permalink | Reply | 2 comments |
headers
Peter Gutmann | 1 Feb 2002 03:55
Picon
Picon
Picon
Favicon

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


Denis Pinkas <Denis.Pinkas <at> bull.net> writes:

>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.

Actually I think the main problem with this draft (which others have also
alluded to indirectly) is that it's trying to do two things at once: Identify
certs using a hash, and provide a way of encoding binary values as user-
friendly keys.  I think it'd be better to split the two, create a universal
user-friendly key-encoding RFC and then move the identifying-certs bit
elsewhere.  The key-encoding is useful in lots of other places, for example
I've been using it with CMP for enrolment details.

Peter.
Permalink | Reply | 1 comment |
headers
Peter Gutmann | 1 Feb 2002 03:50
Picon
Picon
Picon
Favicon

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


Jean-Marc Desperrier <jean-marc.desperrier <at> certplus.com> writes:

>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.

Actually finding a collision for a cert isn't nearly that hard, because you can
trivially manipulate the bits of a cert which aren't protected by the signature
(through non-DER encodings, for example).  You can therefore get a large number
of (equally valid but with different hashes) variants of a single cert.  Using
a truncated hash to uniquely identify a cert is therefore somewhat risky.

Peter.
Permalink | Reply | 0 comments |
headers
Peter Gutmann | 1 Feb 2002 03:15
Picon
Picon
Picon
Favicon

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


Paul Hoffman / VPNC <paul.hoffman <at> vpnc.org> writes:

>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.

It's easier if you work backwards instead of forwards, my code takes as
parameter the number of groups of 5 characters which you want, then takes as
many bits of input as it needs (typically from an SHA-1 hash) to fill that.
It's a universal system so you can select the tradeoff between size and
collision-resistance.

(Given that people are going to implement this in all sorts of strange ways
 from a text-only specification, you could just take my code and stick an RFC
 header on it, that way it'll work for everyone with little or no effort).

Peter.
Permalink | Reply | 0 comments |
headers
Peter Gutmann | 1 Feb 2002 09:17
Picon
Picon
Picon
Favicon

Re: TSP interop update


Margus Freudenthal <margus <at> cyber.ee> writes:

>In addition, this makes the protocol more complex as the client must implement
>procedures for dealing with time stamps with funny and unexpected policy
>identifiers.

It's far easier to compare the returned ID with a known-good set than to submit
a string of requests going down a list of acceptable policies trying to find
one the TSA won't reject.

Peter.
Permalink | Reply | 4 comments |
headers
Margus Freudenthal | 1 Feb 2002 08:59
Picon
Favicon

Re: TSP interop update


Peter Gutmann wrote:
> 
> What if the client prefers policy X, but will accept anything if that's not
> available?  This is standard procedure for restaurants, libraries, ...
> 
The client doesn't request some specific policy just for the kicks. He
needs the time stamp for proving something to someone. This someone will
most likely have rules according which he verifies time stamps ("I
expect time stamps to be signed by TSA X and issued under policy Y").
Therefore, receiving time stamp with policy which may or may not be
equal or similar to the one requested, is of little value to the
time-stamping client. In addition, this makes the protocol more complex
as the client must implement procedures for dealing with time stamps
with funny and unexpected policy identifiers.

--

-- 
Margus
Permalink | Reply | 0 comments |
headers
Denis Pinkas | 1 Feb 2002 09:35
Picon

Re: TSP interop update


Peter,

> >It is simmple: if a client requests a policy and if the server supports that
> >policy, why should the server choose a different policy ? Just to annoy the
> >client ?
> 
> What if the client prefers policy X, but will accept anything if that's not
> available?  

Simple.

First exchange:  he asks for a given policy and does not get it.
Second exchange: he does not use the optional field reqPolicy and 
                 thus gets what the server has.

Denis 

> This is standard procedure for restaurants, libraries, ...
> 
> Twitchen: "We'll have the duck".
> Fawlty: "Duck's off, sorry".
> Twitchen: "We'll have the trifle then".
> 
> TSP however requires:
> 
> Twitchen: "We'll have the duck".
> Fawlty: "You ponce in here expecting to be waited on hand and foot. Well, I'm
>          trying to run a TSA here. Have you any idea how much there is to do?
>          Go away".
(Continue reading)

Permalink | Reply | 0 comments |

Gmane