Subject: Re: X.509 ACs vs. SPKI?

From: "Aram Perez" <[email-masked]>
Date: Fri, 28 May 1999 10:12:30 -0700

Hi Steve,

> Aram,
> 
> We need to remain algotihm independent, and thus we cannot insist on just
> one hash function.  Our data structures that rely on hashes also specify
> which hash was employed, to prevent ambiguity.

The ASN.1 that Denis Pinkas wrote is:

ESSCertID ::=  SEQUENCE {
     certHash                 Hash,
     issuerSerial             IssuerSerial OPTIONAL
}

Hash ::= OCTET STRING -- SHA1 hash of entire certificate

I'm not an ASN.1 expert, but where is the hash specified (other than in the
comment)? Is the definition of "Hash" wrong? Should it be something like:

Hash ::= SEQUENCE {
    hashAlgorithm AlgorithmIdentier,
    hashValue HashValue
}

HashValue ::= OCTET STRING

If I can paraphrase Solomon: "There is a time to be algorithm independent
and there is a time to be algorithm dependent." Why complicate and decrease
the performance of the software that has to look up a certificate. I doubt
that the data store/directory/database where the certificates are kept wants
to have a field/attribute for any and every possible hash we allow.

This also begs the question "Why the hash and not just the IssuerSerial?" It
might be my misunderstanding of X.509, but I was under the
impression/assumption that the Issuer and Serial Number uniquely identified
an X.509 certificate.

> The use of hashes as
> fingerprints for self-signed certs, to facilitate out of band verification
> has not been a subject of standardization so far, and that is the cause of
> some of the problems you cite.  We can try to encourage vendors to do the
> right thing, but if we don't standardize it, ...

Well I believe we should standardize it (i.e. pick 1 hash algorithm).

Regards,
Aram

---

From: Stephen Kent <[email-masked]>
Date: Fri, 28 May 1999 14:00:26 -0400

Aram,

I see the structure that raised your concern, and we'll clearly have to do
something in our context to ensure that the ambiguity does not persist.  (I
assume that this was not an issue in the context where the structure was
used initially, due to the hash alg being identified elsewhere.)

We relly love algorithm independence here in the IETF, so I will not try to
spend time on the list justifying it.  Clearly it has been important in the
encryption algorithm arena, where independence is making it possible to
transition from DES to 3DES or AES, or whatever.  Similar arguments apply
to hash algorithms as well.

Finally, an Issuer name and serial number SHOULD uniquely identify a cert,
but in reality there is insufficient control over Issuer names to guarantee
uniqueness.  Use of the hash as a backpointer is more secure, though by
itself a hash is not a great way to ID a cert, due to searching
limitations, as discussed previously.

Steve

---

From: Russ Housley <[email-masked]>
Date: Fri, 28 May 1999 17:38:58 -0400

I aggree that including the hash algirith identifier would be preferable.
For ESS, it is too late, but we can do it in a backward compatible way:

  ESSCertID ::=  SEQUENCE {
     certHash  Hash,
     issuerSerial  IssuerSerial OPTIONAL }

  Hash ::= CHOICE {
     sha1Hash  HashValue,
     otherHash  HashAlgAndValue }

  HashAlgAndValue ::= SEQUENCE {
     hashAlgorithm AlgorithmIdentier DEFAULT (id-sha1),
     hashValue HashValue }

Russ

---

From: Moshe Litvin <[email-masked]>
Date: Sun, 30 May 1999 15:49:53 +0300

Russ,

There are two uses for unique certificate ID:

A. Certificate comparison: Alice has a certificate, Bob has a good guess about
the certificate and they want to make sure that the certificate they are signing
is the same.

B. Certificate search: Alice has a certificate, Bob has a large database of
certificates and alice want to tell Bob which certificate to look for.

If we want to allow only the first then there is no reason to fix a certain
algorithm and your suggestion is appropriate.

If we want to allow the second then the database should be indexed by the unique
identifier in order to be able to search by it. This means that Alice has to know
in advance what algorithm Bob uses before it sends the message.

There are several options to solve this problem:

1. Decide that algorithm independancy is not important enough in this context.

2. Ignore the problem - Hopefully every one will use the same hash and we will
have algorithm dependency not in the standard but in common use.

3. Decide that we use only one algorithm for indexing database but allow other
for comparison. The ASN.1 will be something like:

  ESSCertID ::=  SEQUENCE {
     certHash  Hash,

  Hash ::= SEQUENCE {
     sha1Hash  HashValue,
     otherHash  HashAlgAndValue OPTIONAL  }

That is the ESSCertID will always contain sha-1 for data base searches but we
want to compare with a stronger algorithm we can add other hash.

4. Allow Alice to send several hashes to Bob hoping that his database is indexed
by one of them. This option like option #2 assumes a common hash algorithm shared
by everyone but allows migration to other hash algorithm.

The ASN.1 one will be:

  ESSCertID ::=  SEQUENCE {
     certHash  Hash,

  Hash ::= CHOICE {
     sha1Hash  HashValue,
     otherHash  SEQUENCE OF HashAlgAndValue  }

Regards,

Moshe