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

From: [email-masked]
Date: Thu, 12 Oct 2000 18:25:48 -0400

The reason I think that using SubjectAltName might sometimes be
preferred is related to Polar's concern about the adequacy of identities.
IMHO, both e-mail addresses and permanent identifiers are less likely to
have identity conflicts than DN's, while IP addresses and DNS names are
usually adequate identifiers only for devices.  There is also little reason
to prefer a secondary directoryName or x400Name to a subject DN.  I would
not be sure where to put ediPartyName, registeredID, or URI in such an
ordering - the last two are pretty immune from naming conflicts but they
don't usually indicate individuals.
     Using SubjectAltName fields would allow an AA to specify a user by
e-mail address or by PI and let that user use any of his PKC's with that
AC.  The only potential drawback I see is whether that allows an attacker
to get a PKC with a false value in that field from a legitimate CA, but I
hope that if there are others they will be pointed out.
     If this suggestion comes too late in the cycle, so be it.

          Tom Gindin

Stephen Farrell <[email-masked]> on 10/12/2000 05:33:25 PM

Please respond to [email-masked]

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

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.

[email-masked] wrote:
>
>      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

--
____________________________________________________________
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: "Manger, James H" <[email-masked]>
Date: Fri, 13 Oct 2000 10:53:57 +1100

I support making the change.

The separation of names between the 'subject' and 'subjectAltName' fields is
for historical reasons.  These two fields should not be distinguished for
future processing - i.e. together they provide the certificate holder's
names.

----------
From: Stephen Farrell [mailto:[email-masked]]

. 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

So, if a bunch of folks want this change, I'd agree to it.

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.