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

Hi Steve,
Comments below.

On Thu, 2 Nov 2000, Steve Hanna wrote:

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

I don't see why not following X.509 isn't a good thing. And why would
interoperability 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.

I would like to point out that the AC in this case is stating that
attributes are only valid for the particular "context" of the contained
public key, which is something I would hope could be enforced. It means
that I want you to use a certain PKC certificate, whether it be for
auditing or validation characteristics of signature, i.e. he must use the
key that was certified for transactions over $1,000,000,000,000,000
Turkish Lire and whatever else is in the certificate, such as the
particular DN, a particular Issuer, or some proprietary critical
identifying v3 attribute extension. 

I think that is certainly critical, because I can create my public key.
Getting it certified for use in several different contexts is a definite
plausibility.

Remember the other two elements, entityName and baseCertificateID are only
"hints", as Sharon as stated, to finding the correct certificate. If the
Attribute Authority only certifies the publickey I can still fake PKCs and
Issuer PKCs with those names and serial numbers with the same public key,
with of course the ability to fool the relying party that those names
exist underneath alternate PKIs that it trusts.

In the cases, such as SSL, where the certificates are actually delivered
by the client, he is stating a particular context for the authentication.
You may want the AC to make sure that he is using that context. (for
auditing, logging, non-repudiation, etc).

I still see a need for this hash. However, I also agree that there are
cases where only the publicKey would matter and not the certificate.

> Using objectDigestInfo with publicKey hash
> should resolve the concern raised by Polar (problems with inconsistent
> or duplicative naming). 

That it should. :)

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

I'll certainly agree with that in cases where X.509 PKCs are used to
identify users.  However, If you are certifying a Kerberos Name, or a
rfc822 name, you have to do some mucking around to make sure that the AC
is actually talking about the same party you believe. It's the same
problem with verifying just DNs (except that Kerberos and rfc822 are a bit
better as they include both entity and name path of issuers all the way to
its root). Including a KerberosTicket Hash is not quite right, although
conceivable. (something like that would bring the use of Kerberos'
blazingly fast authentication to a screaming halt with all the public key
signature validations that have to be performed).

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

No, I don't think you have. However, now the only problem I have is what
is the definition of "interoperability"? Or I should say what is the scope
of "interoperability" with respect to users, attribute certificate
issuers, and relying parties.

If you constrain the definition that all three must subscribe to the same
"trusted" LDAP directory or PKI then some of these lesser options, i.e.
anything without an objectDigestInfo, can start taking hold.

Cheers,
-Polar

> -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 <sharon.boeyen <at> entrust.com>
> > > To: "'Steve Hanna'" <steve.hanna <at> sun.com>
> > > Cc: ietf-pkix <at> imc.org
> > > 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
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:polar <at> adiron.com       2-212 CST      
Phone: 315-443-3171           Syracuse, NY 13244-4100
Fax:   315-443-4745           http://www.adiron.com