Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt

From: "Covey, Carlin" <[email-masked]>
Date: Wed, 18 Oct 2000 09:56:09 -0700

The wording of 2. below seems a bit misleading.  My understanding is that
the security issue is a consequence of the fact that the entityName option
deliberately permits mapping to more than one of the holder's PKC's (hence
potentially to another user's PKC).  Perhaps instead of "... the holder's PK
certificate MUST be uniquely found under the same root CA..." the wording
should be "... a PK certificate MUST be found whose DN is unique under the
same root CA..."

- Carlin Covey
  Cylink Corp.

> To be valid an AC MUST satisfy all of the following:
>
>  <snip>
>
>2. When the AC holder is named by a DN using the entityName option,
>   the holder's PK certificate MUST be uniquely found under the same root
>   CA as the AC issuer. The entire certification path of that PKC MUST be
>   verified in accordance with [PKIXPROF].

-----Original Message-----
From: Polar Humenn [mailto:[email-masked]]
Sent: Wednesday, October 18, 2000 9:39 AM
To: Denis Pinkas
Cc: Al Arsenault; Sharon Boeyen; Russ Housley; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

On Wed, 18 Oct 2000, Denis Pinkas wrote:

>> [SNIP]
>    ESSCertID ::=  SEQUENCE {
>         certHash                 Hash,
>         issuerSerial             IssuerSerial OPTIONAL
>    }
> 
> and, in that case, having IssuerSerial present.
>
> Then we would need some additional text in the explanations to say that
the
> hash of the certificate should also be tested.
> 
> In this way, at the time of verification, there is no ambiguity about the
> link between the AC and the certificate, even if the CA has the same name
as
> another CA certified from a different root key.

Dennis,

I still think that this solution doesn't quite solve the problem, but is a
good start.  In fact Tom Gindin's suggestion just came in and includes
yours. So I'll sort of work off of that.

The fact is that the entityName option still contains a DN and the RP MUST
be prepared to accept it. However, on what conditions should the RP accept
the Holder as a DN? (Especially if this verification is offloaded to some
remote verification engine).

Perhaps there is a way to word the USE of a DN entityName? 

When using an AC that contains the Holder specification as a DN entityName
option, the DN MUST verifiable and uniquely name an entity within the PKI
of the AA, (i.e. resolved under the same RootCA as the AC). The AA MUST
ONLY create AttributeCertificates with the Holder as a DN entityName in
this fashion. This constraint is subject to the entire PKI for which the
AA belongs belongs to behave in its creation of unique DN. Therefore,
verification is subject to the trust the RP places in the AA and its PKI
together to conform to this behavior.

[Note: this approach still does not solve the problem that Denis brings up
below as comment 43. A subordinate CA may be compromised within the PKI of
the AA and create impostor certificates, grabbing privileges.]

Therefore, it would still probably be better to use the Issuer/Serial and
a hash of the Issuer's certificate, even if in the same PKI.

Of course, when an application authenticates to an RP using PKCs this ties
the authorization to a particular certificate. Apparently that was not
desirable due to the effect of key rollover and new certificates being
issued to the same subject entity.

However, I think that if as Carlise pointed out, that if the DN is only
used in the case of a single trusted Root, then everything will be fine.

So, as Russ asked me to propose text, here it goes:

Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
that is already defined in the document for the certificate Hash).

Section 4.1:

   Holder ::= SEQUENCE {
        baseCertificateID   [0] IssuerSerial OPTIONAL,
                -- the issuer and serial number of
                -- the holder's Public Key Certificate
        entityName          [1] GeneralNames OPTIONAL,
                -- the name of the claimant or role
        objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
                -- if present, version must be v2
        verifiedBaseCertificateID     IssuerSerialCertID OPTIONAL
   }

   IssuerSerialCertID ::=  SEQUENCE {
        isserCertDigest          ObjectDigestInfo,
        issuerSerial             IssuerSerial
   }

In section 4.2.2 Holder add:

When using an entityName that contains a DN, the DN MUST verifiably and
uniquely name an entity within the PKI of the AC issuer. The PKC named by
the DN MUST verify back to the root CA of the AC issuer. The AC issuer
MUST ONLY create AttributeCertificates with the Holder as a DN entityName
in this fashion. This constraint is subject to the entire PKI for which
the AC issuer belongs to behave in its creation of unique DNs. Therefore,
verification is also subject to the trust the RP places in the AC issuer's
PKI to conform to this behavior.

In Section 5 the AC Validation Criteria is as follows: (keeping 1 as 1,
inserting 2, 3, and 4 below, and renumbering accordingly).

To be valid an AC MUST satisfy all of the following:

1. The AC signature MUST be cryptographically correct, and the AC
   issuer's entire PKC certification path MUST be verified in
   accordance with [PKIXPROF].

2. When the AC holder is named by a DN using the entityName option,
   the holder's PK certificate MUST be uniquely found under the same root
   CA as the AC issuer. The entire certification path of that PKC MUST be
   verified in accordance with [PKIXPROF].

3. When the AC holder is named by a baseCertificateId, the issuer's PK
   certificate MUST be uniquely found under the same root CA as
   the AC issuer. The entire certificate path of that PKC MUST
   be verified in accordance with [PKIXPROF].

4. When the AC holder is named by a verifiedBaseCertificateID, the
   named holder issuer's PKC must be found, and that PKC MUST correctly
   digest to the digest value contained in the verifiedBaseCertificateID.
   The entire certificate path starting with the holder's PKC and the PKC
   of the issuer the holder's PKC MUST be verified in accordance
   with [PKIXPROF].

.....

Note: there is *still* a problem with AC targeting and proxying using
just DNs.

Cheers,
-Polar

-------------------------------------------------------------------
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: Polar Humenn <[email-masked]>
Date: Wed, 18 Oct 2000 13:53:09 -0400 (EDT)

> should be "... a PK certificate MUST be found whose DN is unique under the

Hi Carlin,

I agree with your observation, but with the stipulation that we are
talking about the AC's Holder. With that in mind, the new 2:

2. When the AC holder is named by a DN using the entityName option,
   a PK certificate MUST be found for which the holder's DN is unique
   under the same root CA as the AC issuer. The entire certification path
   of that PKC MUST be verified in accordance with [PKIXPROF].

Do you agree?

So, to keep the proposal all together, below is the same as before with
the new 2. and one minor editorial change in 4. I forgot an "of". :(

Cheers,
-Polar

Section 4.1:

   Holder ::= SEQUENCE {

2. When the AC holder is named by a DN using the entityName option,
   a PK certificate MUST be found for which the holder's DN is unique
   under the same root CA as the AC issuer. The entire certification path
   of that PKC MUST be verified in accordance with [PKIXPROF].

3. When the AC holder is named by a baseCertificateID, the issuer's PK
   certificate MUST be uniquely found under the same root CA as
   the AC issuer. The entire certificate path of that PKC MUST
   be verified in accordance with [PKIXPROF].

   of the issuer of the holder's PKC MUST be verified in accordance
   with [PKIXPROF].

Note: there is still a problem targets and proxies just using DNs.

Cheers,
-Polar

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Oct 2000 03:17:34 +0100

Regardless of any other text, if you want to change X.509(2000)
then you should contact ISO. PKIX compliant ACs have to be
X.509 compliant. 

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