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

From: Steve Hanna <[email-masked]>
Date: Thu, 02 Nov 2000 09:50:45 -0500

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: Polar Humenn <[email-masked]>
Date: Thu, 2 Nov 2000 11:58:18 -0500 (EST)

Hi Steve,
Comments below.

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

> 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
> or duplicative naming). 

That it should. :)

> So I suggest that we not recommend the use of

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

> implementors without substantial loss of functionality.

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

> > > tried to lump it all together.

-------------------------------------------------------------------
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: Steve Hanna <[email-masked]>
Date: Thu, 02 Nov 2000 12:57:40 -0500

> interoperability be impossible?

The goal of the ac509prof draft is to define a profile of X.509
attribute certificates for use with Internet protocols. As such, it is
to be expected that we will make recommendations about which features
SHOULD or MUST be supported.

It's unlikely that most implementors will want to support all 11 formats
listed above. If we can identify one or two formats that are sufficient
for use with Internet protocols and recommend that those formats be
supported, then we can increase the chances of successful
interoperation. If we make no such recommendations, it's unlikely that
we can achieve this.

> cases where only the publicKey would matter and not the certificate.

If it is crucial that a particular AC be used only in combination with a
particular PKC, then I have no objection to allowing format 11. However,
I would be more convinced if you had a specific example.

> signature validations that have to be performed).

So you are arguing that we should support format 2 (entityName only),
for cases where the holder doesn't have a public key (or where it's
easier to authenticate them via some other mechanism)?

This would also allow us to support role specification certificates
(which assign privileges or attributes to a role). I realized after
sending my email that we cannot support them with formats 4-11, because
a role does not have a public key. And I suppose that we do want to
support them, since we discuss them in section 4.4.5.

So we should recommend that AC verifiers support format 2 for this use
case. Now we're up to three formats: 2 (where a name is the holder), 10
(where a public key is the holder), and 11 (where a PKC is the holder).
I hope that's all!

-Steve

---

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

Hi Steve!

<snip>

> attribute certificates for use with Internet protocols. 

Below you asked me for specific examples. So, can you please give me an a
definite list of which Internet protocols are supposed to support this
attribute certificate?

> As such, it is to be expected that we will make recommendations about
> which features SHOULD or MUST be supported.
> 

I understand that. But different applications and different protocols need
different things.

> I would be more convinced if you had a specific example.

I thought I just did.

> easier to authenticate them via some other mechanism)?

That would have to be if you want to support AC outside of PKI. I don't
have any specific examples.

> support them, since we discuss them in section 4.4.5.

Well, that's problematic on how you define the role. A role also needs
scoping information, like "who's role". Is a role defined by a DN? 

> (where a public key is the holder), and 11 (where a PKC is the holder).

I think that was Tom Gindin's conclusion as well. which is:

[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 would say that 2 should be supported in cases such that the naming
mechanism is unique to the application, i.e. Kerberos, RFC822, DN's only
where they can be considered verifiably unique (although I don't know how
that would be accomplished in the "interoperable" sense, due to the name
collision problem with DNs and their issuers).

Option 11 is definitely preferable where PKCs are used. Options 7 and 9
are desirable from a stand point of verifying the certificate being
pointed to, i.e. in those Internet protocols where the RP must look up
certificates.

And as for 4 and 8, I would say 4 is preferable to 8, because, 8 can lead
to inconsistencies. Where only the public key matters (i.e. the holder of
the matching private key)  it shouldn't matter what DN it has. If it does
matter, then it should hash the certificate that ties the DN to the key.
In SSL, if the AC is only concerned with the public key, then the DN may
yield an inconsistency. The user may have delivered PKC with his public key
but a different DN. 

Cheers,
-Polar

---

From: Steve Hanna <[email-masked]>
Date: Thu, 02 Nov 2000 14:50:36 -0500

> definite list of which Internet protocols are supposed to support this

ac509prof says "The profile places emphasis on attribute certificate
support for Internet electronic mail, IPsec, and WWW security
applications." So I expect that S/MIME, IPsec, and TLS would be the most
important protocols for this profile.

> I understand that. But different applications and different protocols need

Sure. If you can identify an important reason why one of these formats
is needed for the protocols of concern to us, then we should keep it.
Otherwise, we should not.

> > I would be more convinced if you had a specific example.

Could you be more specific?

> scoping information, like "who's role". Is a role defined by a DN?

The roleAuthority field defines the scope for a role.

> pointed to, i.e. in those Internet protocols where the RP must look up

Why would 7 (BCID & PKC ODI) or 9 (EN & PKC ODI) be preferable to 11
(BCID, EN, & PKC ODI) when the RP must look up certificates? I would
expect that 11 would indisputably be the best in this circumstance,
since it provides more hints to the RP.

> yield an inconsistency. The user may have delivered PKC with his public key

I don't see how including hints that might help the RP find certs would
hurt anything. If the user has presented a PKC whose subject name does
not match the entityName but the public key matches the PK ODI, then
there's no problem. The entityName is just a hint.

-Steve

---

From: Eric Rescorla <[email-masked]>
Date: 02 Nov 2000 12:12:42 -0800

> important protocols for this profile.
TLS, at least, would need to be modified to use ACs. The issue is that
RFC 2246 explicitly specifies the order in which certificates must
appear:

   certificate_list
       This is a sequence (chain) of X.509v3 certificates. The sender's
       certificate must come first in the list. Each following
       certificate must directly certify the one preceding it. Because
       certificate validation requires that root keys be distributed
       independently, the self-signed certificate which specifies the
       root certificate authority may optionally be omitted from the
       chain, under the assumption that the remote end must already
       possess it in order to validate it in any case.

-Ekr

---

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

> important protocols for this profile.

Do any of these protocols have facility for AC's?

> Otherwise, we should not.

Well, I think I did identify that you at least need a tie to the public
key.

> Could you be more specific?

PKCs delivered via TLS, RP pulls the AC from somewhere and wants to make
sure the correct PKC is used. Make sure the "context" in which he is
operating is defined by the correct certificate, because the certificate
contains "certified" information, such as the key is used to sign
transactions over $1,000,000,000 Turkish Lire. (or should I add a couple
more zeros?) :)

> since it provides more hints to the RP.

Okay, I'll agree. If that is your point, then 7 and 9 should be excluded
in favor of always using 11. So, that means any inconsitency in the EN and
the BCID should be ignored as long as the hash checks out. Just as long as
that is explicitly said.

So anyway, whats the harm in supporting 7 and 9 then? Would you say that
if an RP is presented with 7 and 9 you should always reject it,
regardless?

I think there has to be a dual notion of "support" here, one for issuers
and one for "verifiers", in sort of along the lines of "be conservative in
what you send and generous in what you receive". Perhaps, verifiers should
support 7,9,and 11, but issuers SHOULD only issue 11 in the cases where
ACs are tied to PKCs.

> there's no problem. The entityName is just a hint.

As long as that is explicitly stated in the document. So, in TLS if I am
delivered a PK certificate, I can ignore the EN and BCID from the AC
altoghether and just go for the PKC hash. However, I think there is
something in profile that states that the Entity Name MUST match the PK
certificate's subject DN.

Cheers,
-Polar

---

From: Steve Hanna <[email-masked]>
Date: Thu, 02 Nov 2000 16:04:03 -0500

> Do any of these protocols have facility for AC's?

I'm certainly not an expert with all of these protocols. S/MIME does
include attribute certificate support. IPsec and TLS seem to need more
work.

> Well, I think I did identify that you at least need a tie to the public

Yes, thank you for pointing that out.

> transactions over $1,000,000,000 Turkish Lire. (or should I add a couple

If the RP has a PKC that he trusts which says that the user's key is
trusted for billion lire operations, what difference does it make
whether it's the same PKC that the AC issuer had in mind? The RP trusts
the PKC because the PKI says it's trustworthy. Or are you saying that
the RP should trust the PKC because its hash is in the AC. In that case,
why all the indirection? If you don't trust the PKI to get you a valid
PKC, don't use the PKI. Just use ACs with a PK ODI. And put any
security-sensitive information (like the billion lire signing authority)
in the AC.

> support 7,9,and 11, but issuers SHOULD only issue 11 in the cases where

If we see no reason to use formats 7 and 9, we shouldn't tell verifiers
that they SHOULD implement them. Certainly, they MAY implement them. But
there's no reason for them to waste the time, money, and code space on
doing so.

> certificate's subject DN.

That note predates this discussion. Clearly the Holder and ODI sections
need to be rewritten.

-Steve

---

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

<snip>

> the PKC because the PKI says it's trustworthy. 

I guess what I meant was that, at least in protocols where the PKC is
delivered by the client, it places a context on the signatures done by its
public key. The AC is stating that attributes only apply to that context.
The PKC can have other pertinent information in it, such as a bank account
number, an audit identity, all that kind of stuff you didn't want to copy
into an AC (otherwise, we'd just include the entire PKC!).

> Or are you saying that the RP should trust the PKC because its hash is
> in the AC. In that case, why all the indirection? If you don't trust
> the PKI to get you a valid PKC, don't use the PKI. 

No, what I am saying is that the RP shouldn't trust the AC if the hash
doesn't match the PKC.

> And put any security-sensitive information (like the billion lire
> signing authority) in the AC. Just use ACs with a PK ODI.

If that was the case, why wouldn't we just use to Bob Jeunman's suggestion
of just including all the Attribute information in a different PKC with
the users private key, certifying the signature, identity constraints,
attributes, etc, etc. which contains all the information in a delegated
sense. We'd be down to one certificate chain verification instead of two,
and some correlation work. The need for the AC goes away, S/MIME, IPsec,
TLS does not need to be reworked.

Unfortunately, this approach is not desirable,and also issuing attributes
to alternate naming schemes, such as Kerberos or RFC822, or Roles names
would be problematic.

> there's no reason for them to waste the time, money, and code space on

I don't get it. Are you saying that they have to spend the time money and
code space to look for 7 and 9 and REJECT the AC? Or should it just core
dump? :)

> That note predates this discussion. Clearly the Holder and ODI sections

Agreed.

Cheers,
-Polar

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 3 Nov 2000 09:24:57 +0300

> include attribute certificate support. IPsec and TLS seem to need more

IPsec (IKE) has build-in facility to transport AC certificates.

Regards,
Valery.