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 12:21:11 -0500

My own recommendations would run almost opposite yours.  In the
extreme case, option 7 is clearly preferable to option 6 because both
options specify a specific certificate (as does option 1), and option 7
locks down the whole certificate while option 6 does not.  It is also
clearly preferable to option 5, which specifies a single certificate
without making it locatable.  A similar argument prefers option 11 to
option 10 and option 3.  So now we have reasons IMO to prefer 7 or 11 to 1,
3, 5, 6 or 10.
     This leaves 2, 4, 8, and 9.  Case 2 is of independent value and should
be permitted.  Case 4 is somewhat debatable - its meaning is "I'll accept
any unrevoked and unexpired certificate with this particular key" and case
8 is more secure, but case 4 permits a name change while 8 doesn't.  Case 9
is a simplified case of 11 (as 7 also is) and is not particularly
necessary.

     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.

          Tom Gindin

Steve Hanna <[email-masked]> on 11/02/2000 09:50:45 AM

To:   "David P. Kemp" <[email-masked]>
cc:   [email-masked]
Subject:  Holder (was Re: Comments on draft-ietf-pkix-ac509prof-05.txt)

We now have 11 possible formats for the Holder field:

1) baseCertificateID only
2) entityName only
3) baseCertificateID and entityName
4) objectDigestInfo only with publicKey hash
5) objectDigestInfo only with publicKeyCert hash
6) baseCertificateID and objectDigestInfo with publicKey hash
7) baseCertificateID and objectDigestInfo with publicKeyCert hash
8) entityName and objectDigestInfo with publicKey hash
9) entityName and objectDigestInfo with publicKeyCert hash
10) baseCertificateID, entityName, and objectDigestInfo with publicKey
    hash
11) baseCertificateID, entityName, and objectDigestInfo with
    publicKeyCert hash

Given that we're designing a *profile* of X.509 ACs, can we choose one
or two of these formats, recommend that AC issuers only use those, and
require that AC verifiers be able to process them? If not, then I'm
afraid interoperability will be impossible.

Let's see if I can narrow things down a bit. I'll start by pointing out
that using objectDigestInfo with publicKeyCert hash may cause problems
if the holder wants to use a different PKC to authenticate than the one
whose hash is in the AC. Using objectDigestInfo with publicKey hash
should resolve the concern raised by Polar (problems with inconsistent
or duplicative naming). So I suggest that we not recommend the use of
formats 5, 7, 9, and 11 above.

Is there any reason *not* to include a publicKey hash in the Holder?
Perhaps the holder will want to use a different key than the one whose
hash is in the AC. But that sounds unlikely to me. In that circumstance,
they should probably get an AC for the second key. Getting a new AC
should not be hard. So I suggest (somewhat contrary to my earlier
comments) that our recommended format should include a publicKey hash.

According to Sharon, if we include objectDigestInfo in any form,
baseCertificateID and entityName are only hints to be used for searching
purposes. So is there any reason not to include them? If not, I suggest
that we recommend that AC issuers use format 10 above. And that we
require that AC verifiers support that format. Support for other formats
would be optional. This should simplify things substantially for
implementors without substantial loss of functionality.

Have I missed anything?

-Steve

"David P. Kemp" wrote:
>
> Sharon,
>
> Thanks for clarifying the distinction between the "controlling" Holder
> option and other options used only as search aids.  That's what I get
> for reading the AC profile without being thoroughly familiar with the
> base X.509 document :-(.
>
> I agree that the precedence shown below is correct, and withdraw my
> suggestion for mutual exclusion between entityName and the other
> options.
>
> Dave
>
> > From: Sharon Boeyen <[email-masked]>
> > To: "'Steve Hanna'" <[email-masked]>
> > Cc: [email-masked]
> > Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
> > Date: Fri, 27 Oct 2000 15:51:34 -0400
> >
> > Yep I can explain - the second text is not text from the standard, but
my
> > explanation of what I believe is intended and you are correct that in
the
> > Holder, the order is not as I indicated (it is in issuer though and
that's
> > where the confusion krept in). What I meant specifically was:
> >
> > - if entityName and baseCertificateID are present, then ONLY
baseCertificateID
> >   may be used and entityName is a potentially helpful search tool
> > - if entityName and objectDigestInfo are present, then ONLY
objectDigestInfo may
> >   be used and entityName is a potentially helpful search tool
> > - if baseCertificateID and objectDigestInfo are present, then ONLY
objectDigestInfo
> >   may be used and baseCertificateID is a potentially helpful search
tool
> >
> > - if entityName, baseCertificateID and objectDigestInfo are present,
the ONLY
> >   objectDigestInfo may be used and entityName and baseCertificateID are
potentially
> >   helpful search tools.
> >
> > Sorry for the confusion and thanks for catching it. I shouldn't have
> > tried to lump it all together.
> >
> > Sharon

---

From: Steve Hanna <[email-masked]>
Date: Thu, 02 Nov 2000 13:02:32 -0500

Tom Gindin/Watson/IBM wrote:
> locks down the whole certificate while option 6 does not.

You assume that baseCertificateID specifies a particular PKC. When used
in combination with objectDigestInfo, it does not. It only specifies a
searching hint (as Sharon said). Other PKCs that meet the requirements
of the objectDigestInfo will suffice. So option 6 would work with any
PKC that has the specified public key. If this is desirable, option 6 is
superior to option 7. I see little argument for option 1 over option 7,
however. It specifies a particular PKC without the extra protection of a
hash.

> It is also
> without making it locatable.

Agreed. Option 5 is not very useful.

> A similar argument prefers option 11 to
> option 10 and option 3.

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.

So now we have reasons IMO to prefer 7 or 11 to 1,
> be permitted.

Yes, I agree (as noted in my recent email to Polar).

> Case 4 is somewhat debatable - its meaning is "I'll accept
> 8 is more secure, but case 4 permits a name change while 8 doesn't.

Actually, case 8 is no more secure. The entityName is only a hint (as
Sharon said). Formats 4, 6, 8, and 10 are equivalent from a security
standpoint.

>  Case 9

Agreed.

> support cases 7 and 9, and I'd poll the group on whether 4 is better than 8

Why support 7 and 9? If you have a PKC in hand, why not provide its
issuer name, serial number, and subject name as hints?

After my discussion with Polar, I'm leaning toward supporting 2, 10, and
11, so we're not so far apart, after all.

-Steve