Subject: Re: AttributeCertificates: Why is the holder DN preferred?

From: [email-masked]
Date: Thu, 12 Oct 2000 14:30:46 -0400

I am not misquoting the draft in any important way.  The third
paragraph (excluding the note) of section 4.2.2 of your current draft
begins as follows: "If the holder field uses the entityName option and the
underlying authentication is based on a PKC, then the entityName MUST be
the same as the PKC subject field, unless the PKC subject field contains an
empty distinguished name. If the PKC subject field contains an empty
distinguished name, then the entityName field MUST be identical to one of
the values of the PKC subjectAltName field extension."  This forbids the
use of a value from subjectAltName, whether e-mail or PI, as an entityName
if the subject DN is present.  The preference for baseCertificateID makes
the issue somewhat less important, but does not eliminate it.
     As for PI's (whose draft is -01 rather than -00), I cited them as one
of two reasonable global identifiers for a user in SubjectAltName.  I
understand that you would not want to hold up this draft for that one, but
I'm looking for re-wording of this statement to allow SubjectAltName
components including e-mail, but excluding IP address, DNS name, and
probably some others.  It might be appropriate to state that the use of
"OTHER-NAME components specifying the identity of the subject as an
individual" may be supported as well.

          Tom Gindin

Stephen Farrell <[email-masked]> on 10/12/2000 05:30:30 AM

Please respond to [email-masked]

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   Russ Housley <[email-masked]>, pkix <[email-masked]>
Subject:  Re: AttributeCertificates: Why is the holder DN preferred?

Tom,

I think you're misquoting the draft. basdCertificateID is the SHOULD for
holder
when PKCs are used for authentiation. When entityName is used, the text
tells
you how it should compare to the subject and/or subjectAltName from the
PKC. It
does not say that the PKC must use any particular form of subject naming.

There is no reference to PI since right now that's a -00 draft with who
know
what future (bright, I'm sure:-) and the AC profile is in IETF wide last
call.

Stephen.

[email-masked] wrote:
>
>      Russ:
>
>      On one subject which is connected to what Polar brought up, I am
> inclined to think that he is right.  In the AC509Prof draft, section
4.2.2
> states that for PKC-based authentication the entityName MUST be the same
as
> the PKC subject field unless that field is empty.  Why should it be
> mandatory to prefer the subject DN to either permanent ID's or e-mail
> addresses, both of which identify individuals in a globally unique way?
> Name collisions are more likely in the DN space than in either of the
other
> two, except for PI's with a default assignment authority, and PI's of
that
> sort should be forbidden as entityName's.  This does not imply that most
of
> the options within GeneralName are appropriate as entityName's, as I
don't
> think they are.
>
>           Tom Gindin
>
> Russ Housley <[email-masked]> on 10/11/2000 01:50:42 PM
>
> To:   Polar Humenn <[email-masked]>
> cc:   Al Arsenault <[email-masked]>, Stephen Farrell
>       <[email-masked]>, Patrik Fältström <[email-masked]>,
>       [email-masked], [email-masked], Thumrongsak Kosiyatrakul
>       <[email-masked]>, Shiu-Kai Chin <[email-masked]>, Susan
>       Older <[email-masked]>
> Subject:  Re: Fwd: AttributeCertificates: Path Names to AC Holders,
Targets
>       andProxies
>
> Polar:
>
> > > Okay, I think I finally figured out what Polar is getting at here,
but
> > > I'm not sure what the fix is.  Let me try to illustrate with an
> example.
> > >
> > > (We'll be picking on Stephen a little bit in this; nothing personal
> > > intended; apologies for any offense.  :-)
> > >
> > > Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> > > Technologies, OU=Public CAs, CN=The CA".
> > > That CA has a self signed certificate with subject and issuer both
> equal
> > > to the DN above.
> > >
> > > Now, there is an end-user certificate issued under that CA.  The
issuer
> > > field of that certificate will be the DN above; the subject field is
> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> > > CN=Stephen".
> > >
> > > The serial number field will be something like "4434".
> > >
> > > Now, an attribute authority has issued our friend Stephen an AC
> > > consistent with the proposed profile.  The "Holder" field in that AC
> can
> > > be one of three things, according to the proposed profile:
> > >
> > >       - it can be the issuer and serial number of the base PKC; that
is
> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> > >
> > >       - it can be the entity name, which by the I-D MUST be "C=IE,
> > > O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> > >
> > >       - it can be an ObjectDigest - for which the I-D does not
require
> > > support.
> >
> >I think the ObjectDigest is truly the only way to go. However, it still
> >has problems. The object that is talked about must be able to be
recalled
> >and identified. Otherwise the Attribute Certificate MUST ALWAYS be
> >delivered with the Holder's Public Key Certificate.
> >
> >I don't believe that requiring the delivery of the Holders certificate
is
> >unreasonable. Can something like this be mandated in this profile? I
don't
> >see how. I only see that in specific protocols. Or am I wrong?
>
> PKCs bind a public key to an identity.
>
> ACs bind attributes to an identity.
>
> Authentication, which includes validating the PKC certification path and
> having the remote party perform some operation that involves the private
> key associated with the identity.  Without authentication of the
identity,
> who cares what attributes are associated with it?
>
> Russ

--
____________________________________________________________
Stephen Farrell
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Oct 2000 22:33:25 +0100

Tom,

Sorry, I misinterpreted your mail a bit (being mixed up with figuring out how 
many identities could dance on the subject field of a certificate:-). You're right 
in what you said below, but I think its ok anyway on the following basis:

If a PKC is used to authenticate the holder to the relying party, and that PKC 
contains a non-null subject field, and the AA chose to put the entityName in on 
the basis of that PKC, then there's no reason not to just stick with 
AC.holder.entityName being compared to PKC.subject.

I guess the (now explicit) assumption in there is that the same PKC (well at least
the same PKC.subject value) is the basis on which the AA issued the AC and is also
used for holder to relying party authentication - in which case the subject field 
is available to both, so why not just use it? 

I suppose a circumstance where this wouldn't hold would be e.g. where the holder
uses Keberos to authenticate to the AA, which then produces an AC containing 
the holder's KerberosName in AC.holder.entityName.OTHER-NAME and where the holder
then uses her PKC to authenticate to the relying party when using the
AC, and where the KerberosName is in PKC.subjectAltName.OTHER-NAME, but 
PKC.subject is not empty. I hadn't really considered such "mixed" authentication 
schemes, but if there were consensus that they were important then I'd be ok 
with changing the draft to allow AC.holder.entityName to be compared against 
either the PKC.subject or any of the PKC.subjectAltName values.

So, if a bunch of folks want this change, I'd agree to it. If its not important 
enough right now (which is what I think) then we're ok as is (Russ?).

Stephen

PS: If we made the change, I wouldn't agree to distinguish some types of alt name
from others (e.g. disallowing ip-address as you suggested), but would treat all 
equally since that's what the CA put in the PKC.