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

From: "Aram Perez" <[email-masked]>
Date: Fri, 28 May 1999 11:31:57 -0700

Hi Steve,

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

If I'm not mistaken, the definition for ESSCertID came from *IETF's S/MIME*
effort, so is appears that someone else at IETF does not "love algorithm
independence".

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

Believe me, I'm a strong believer is algorithm independence but only where
it makes sense. And in the case of using the hash to identify a certificate
I don't believe it makes sense. I agree with the current definition of
ESSCertID. My objection was to Denis Pinkas comment about allowing more hash
algorithms to be used as the identifier of a certificate.

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

You seem to agree that there will be "searching limitations" by having
algorithm independence. So why should PKIX impose these "searching
limitations" if there is no security risk/extra cost/Y10K/etc issue with
having one hash algorithm used to help identify a certificate?

Regards,
Aram

---

From: Stephen Kent <[email-masked]>
Date: Fri, 28 May 1999 15:24:58 -0400

Aram,

>effort, so is appears that someone else at IETF does not "love algorithm

Have you looked at the larger context in S/MIME where it is used?  if not,
then this statement seems premature.

>algorithms to be used as the identifier of a certificate.

I would find it most convenient to use the same hash here as the one used
in signing the cert, since that hash alg is, by definition, one that both
the CA and any relying party must implement.  But, since we don't mandate
any single algorithm for that purpose, why do so for this hash?

>having one hash algorithm used to help identify a certificate?

No, the seacrching problem I refer to is due to the use of ANY hash as an ID.

Steve

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 28 May 1999 13:20:24 -0700

>No, the seacrching problem I refer to is due to the use of ANY hash as an ID.

Slight digress from single/multiple hash algorithm support (I tend to agree
with Steve - a fixed algorithm seems destined for trouble...)

I have always been a bit puzzled by the position that indexing by hash value
is a "problem".  Technically, it seems simple to structure/index an efficient
tree (order log n) search by hash value.  Previous discussions reveal perhaps
that the culprit is distributed DB/Directory management:  Its easy to say
that a given party controls the "OU=xxx" branch of the space, whereas division
of the tree by arbitrary numeric values does not lend itself to this kind of
delegated management.

However, the DN-based tree structure seems (unfortunately) to lend itself all
to easily to "trolling".  (Let's see what lies in the C=X, OU=Y,... area.)

Comments?

___tony___

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8002               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

---

From: Stephen Kent <[email-masked]>
Date: Fri, 28 May 1999 18:50:08 -0400

Tony,

>to easily to "trolling".  (Let's see what lies in the C=X, OU=Y,... area.)

The problem with searching based on an arbitrary number, like a hash, is
the flip side of the featrure you cite for such schemes.  We find that most
naming schemes are tree structured, in part because that allows delegation
of parts of the name space, and that facilitates management and searching.
The downside is that it also facilitates trolling, but we assume the use of
local access controls to make sure that searching a (local) directory is
authorized.

A hash creates a nominally flat name space, which can be aggregated into
clumps, to allow distributed searching.  but who manages the clumps?
because the clumps don't aling with organizational boundaries, there are no
natural organizations to assume responsibility for the repositories, and
access control to entries now requires reliance on third parties.

So, that's the basis for my comments re the appropriateness of hashes as
keys for searching in a large scale, distributed system that crosses
administrative boundaries.

Steve