Subject: AttributeCertificates: Why is the holder DN preferred?

From: [email-masked]
Date: Wed, 11 Oct 2000 17:41:09 -0400

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Oct 2000 10:30:30 +0100

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.

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