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

From: "David P. Kemp" <[email-masked]>
Date: Thu, 2 Nov 2000 17:27:25 -0500 (EST)

> 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

---

From: Polar Humenn <[email-masked]>
Date: Thu, 2 Nov 2000 17:46:42 -0500 (EST)

Dave,

I like your summary below and I agree with it.

Question, would a suggestion adding that AA's SHOULD generate one of the
4,8,1,3,5,7,9,11 that they support instead of 2.

Note that statement would only apply to where Public Key Certificates are
the link to the holder.

Cheers,
-Polar

> Here is a regrouping of the options by purpose, with the search hints

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[email-masked]       2-212 CST      
Phone: 315-443-3171           Syracuse, NY 13244-4100
Fax:   315-443-4745           http://www.adiron.com

---

From: Ron Monzillo <[email-masked]>
Date: Thu, 02 Nov 2000 18:08:01 -0500

"David P. Kemp" wrote:
<snip>

> help with searching or with security, it just takes up space in the

I agree with the rest, but doesn't the relative value of
11(BCId+EN+ODCERT) 
vs 9(EN+ODCERT) depend on whether you look up your PKC's by issuer or by
by subject. It would seem that both options are possible with 11, 
but not with 9.

I think we should focus on 2,8, and 11

Ron

<snip>

---

From: Polar Humenn <[email-masked]>
Date: Thu, 2 Nov 2000 18:42:42 -0500 (EST)

On Thu, 2 Nov 2000, Ron Monzillo wrote:

> 11(BCId+EN+ODCERT)  vs 9(EN+ODCERT) depend on whether you look up your
> PKC's by issuer or by by subject. It would seem that both options are
> possible with 11, but not with 9.

Can you give me an example of when you look up certificates by issuer
instead of subject?

I don't disagree with using 11, because the subject may have many
certificates stored under its DN, and the IssuerSerial is probably a
plausible way to different it that (with of course, ODCert).  But it is
redundant with the ODcert, because you can just go down your list of certs
under the entityName, hash and compare. Okay, it's not that fast, but it's
doable. Time/space trade off. However, in things like SSL and S/MIME you
are going to be handed the certificates, and although not required, you'll
probably use them, so you are looking for verification of the link, not
looking for the certificate itself.

On the public key hash issue, I still think using 8 over 4 is problematic.
I think that if only a public key is relied upon, there shouldn't be a DN
associated with it. The DN is certificate specific and really has no
relation to a public key without a certificate. So hash the certificate
tying the DN to the public key, option 9 or 11, if the DN is needed at
all.

I really don't understand how you try to find a public key with a DN, i.e.
without regard to a certificate. Second of all, if you're doing any kind
of verification at the RP, you've probably already FOUND the public key
before you started working with the AC.

If you have a public key and your looking for the the matching AC out of
list of ACs you have, then just match on the hash. The EN becomes extra
space.

Also, if the entity name in the AC is different than the one the client
may have gave you, it could cause confusion. Same public key, different
CAs.

I would still go for generating 4 instead of 8 for simplicity and less
confusion. If there is a need to include the DN of the Holder, the
certificate hash should be there, which is one of 5,7,9,11. Preference of
which I don't really care. I think 1 and 3 should be avoided due to the DN
naming conflict issue. Option 2 should only be supported when PKCs are not
involved.

Cheers,
-Polar

---

From: Steve Hanna <[email-masked]>
Date: Fri, 03 Nov 2000 17:43:32 -0500

"David P. Kemp" wrote:
> option for each purpose.

Agreed. I think we have reached consensus on this.

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

Requiring support for more Holder formats will make the spec more
complex. This may or may not increase the amount of coding required. It
will certainly increase the effort required for product testing and
interoperability testing. It will also increase the complexity of the
spec. And it may increase the probability that implementations will
choose to not implement all required features in the spec, potentially
leading to incompatibilities (if I implement formats 5 and 7 and you
implement 9 and 11). Several recent IETF standards suffer from having
too many required options (or too few).

With respect to formats 5, 7, 9, and 11, the holder is a PKC. The AC
issuer has the PKC. Why not include all the hints available that might
help the AC verifier find the PKC? Someone asked why it might be useful
to include BCID. With BCID, the AC verifier can query its certificate
repository using the issuer name and serial number (and maybe the
subject name) and get a small number of certificates (probably one),
whose hash can then be compared against the PKC hash in the AC. With
only the entityName, the query to the certificate repository may return
many more certificates.

So I suggest again that there's little reason to use formats 5, 7, and
9. If the holder is a PKC, include all the available hints by using
format 11.

On the question of whether 4, 6, 8, or 10 is better, I want to consider
that over the weekend.

-Steve