Subject: Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)

From: "Tom Gindin/Watson/IBM" <[email-masked]>
Date: Thu, 2 Nov 2000 18:11:50 -0500

I won't argue with a preference for case 9 over case 11 - entityName
and baseCertificateID are indeed redundant with each other when
objectDigestInfo is present, and entityName is usually better for
searching.  I do think we should align the RP MUST's with the AA SHOULD's.
Thus, an RP MUST support cases 2, 8 (assuming that that's more popular than
4) and 9.  For backward compatibility, should we say that an RP MUST
support case 1 as well, or can we just skip it?
     An RP which only supported 2, 8, and 9 would have relatively simple
code to locate the PKC - find by entityName.

          Tom Gindin

"David P. Kemp" <[email-masked]> on 11/02/2000 05:27:25 PM

Please respond to "David P. Kemp" <[email-masked]>

To:   [email-masked]
cc:
Subject:  Re: Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)

> From: Steve Hanna <[email-masked]>
>
> As described above, I don't agree that option 11 is necessarily superior
> to option 10. However, I do agree that option 11 is superior to option
> 3.

Here is a regrouping of the options by purpose, with the search hints
appearing after the "+":

AC attached to              Holder
--------------      -----------------------
Name                 2) entityName

Public Key           4) Digest(publicKey)
                     8) Digest(publicKey) + entityName
                     6) Digest(publicKey) + baseCertificateID
                    10) Digest(publicKey) + baseCertificateID, entityName

PK Certificate       1) baseCertificateID
                     3) baseCertificateID + entityName
                     5) Digest(Cert)
                     9) Digest(Cert) + entityName
                     7) Digest(Cert) + baseCertificateID
                    11) Digest(Cert) + baseCertificateID, entityName

Bob and Sharon have pointed out that baseCertificateID is not very
useful as a search hint; it is only useful to identify one specific
PKC.  If you are looking for certificates that contain a particular
public key, baseCertificateID is not likely to help you find one.  For
that reason, I agree with Tom that 6) and 10) do not serve any purpose
and should not be used.  Including baseCertificateID with a hash of a
public key is more confusing than helpful.

I believe the profile should require support for at least one Holder
option for each purpose.  But I'm not sure that there is much
simplification
to be gained by not supporting certain combinations of search
hints.  In other words, if RPs are required to support 11, could they be
made any simpler by not also supporting 5, 7, and 9?

> Tom Gindin:
>
> So I would recommend that RP's MUST support cases 2 and 11, SHOULD
> support cases 7 and 9, and I'd poll the group on whether 4 is better than
8
> or not.

I'd recommend that AAs:
  MUST support 2,
  MUST support at least one of {4, 8}, and
  MUST support at least one of {1, 3, 5, 7, 9, 11}.

I'd recommend that AAs SHOULD NOT generate ACs using 6 or 10.

I'd recommend that AAs SHOULD generate 8 instead of 4, and SHOULD
generate 9 instead of 1, 3, 5, 7, or 11.  In the case of 9 vs. 11, its
not a case where "more is better" applies.  BaseCertificateID doesn't
help with searching or with security, it just takes up space in the
AC.

I don't have a preference concerning RPs.  As above, if the profile
were to say RPs MUST support 10 and 11, then an RP developer would only
be hurting interoperability without simplifying code by choosing not to
support the other combinations.  If the profile were to say RPs MUST
support 1, 2, and 3, and SHOULD support the others, the minimum
interoperable RP is simpler, and the recommended RP is more complex but
more robust in unmanaged PMI environments.

Dave