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

From: Polar Humenn <[email-masked]>
Date: Wed, 18 Oct 2000 16:19:04 -0400 (EDT)

Hi, 

Okay, on Russ's suggestion that only an attribute extension will be
acceptable. 

I think this approach does the following:

1. Addresses Carlisle's points about when using DNs that "everything"
   belongs to one PKI, i.e. under a single trusted root. So using DNs for  
   the Holder, or the Holder's issuer in IssuerSerial are okay.

2. Addresses my points solving name collisions by either impostor or
   coincidence.

3. If everything was previous working in accordance with Carlisle's
   assumptions of a single PKI, it doesn't break anything.

4. Doesn't change X.509.

5. There is no need to put a security consideration in the document 
   refering to DN name collisions. 

6. The sentence appearing in Section 4.2.2 Holder,

	"See the security consideration section which mentions some
        name collision problems that may arise when using the entityName
        option."

   can probably be eliminated. (Since there isn't a section currently
   in the security consideration section mentioning name collision
   problems.)

Here is the entire proposed text:

Section 4.1 Remains:

   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
   }

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.

When using the baseCertificateID, if the DN contained in
holder.baseCertificateID.issuer construct does not verifiably and uniquely
name an entity within the PKI of the AC issuer, the
VerifiedBaseCertificateID critical extension, as defined in Section 4.3.?,
MUST be present. The AC issuer MUST only create AttributeCertificates with
the Holder as a baseCertificateID in this fashion.

Add the following subsection to Section 4.3 Extensions:

4.3.? Verifying Base Certificate ID

When the holder is named by the baseCertificateID, if the DN contained in
the holder.baseCertificateID.issuer construct does not verifiably and
uniquely name an entity within the PKI of the AC Issuer, a verifiable link
to that issuer's PKC is required by Section 4.2.2. This extension provides
that link by using a digest of the holder issuer's PK certificate.

The digest contained in this extension MUST be a digest of the PKC of the
entity named by the DN in the holder.baseCertificateID.issuer field.

  name           id-pe-ac-verfiedBaseCertificateID
  OID            { id-pe ??? }
  syntax         ObjectDigestInfo
  criticality    MUST be TRUE

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,
   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, one of the
   following cases MUST hold: 

   (a) If the VerifiedBaseCertificateID critical extension is not present,
       a PK certificate MUST be found for which the DN contained in
       the holder.baseCertificateID.issuer construct is unique under the
       same root CA as the AC issuer. The entire certificate path of that
       PKC MUST be verified in accordance with [PKIXPROF].
   (b) If the VerifiedBaseCertificateID critical extension is present,
       a PK certificate MUST be found for the DN contained in
       the holder.baseCertificateID.issuer construct, and that PKC MUST
       correctly digest to the digest value contained in the
       extension. The entire certificate path beginning with the holder's
       PKC and the PKC of the holder's issuer MUST be verified
       in accordance with [PKIXPROF].

Note: there is still a problem targets and proxies just using 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: "Covey, Carlin" <[email-masked]>
Date: Wed, 18 Oct 2000 13:48:02 -0700

Polar,

Evidently the assumption in the "snippet" below is that when the holder of
an AC is identified by a DN, some PKC with the same DN will be used to
authenticate the holder.  Is this actually required?  Couldn't the AC, even
if it identified the holder by a DN, specify some other authentication
criterion, such as a biometric?  The holder of the AC may in fact have zero,
one or more PKC's that may also be used for authentication.

- Carlin Covey
  Cylink Corp.

> -----Original Message-----
> From: Polar Humenn [mailto:[email-masked]]
> Sent: Wednesday, October 18, 2000 1:19 PM
> To: Russ Housley
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt (fwd)
> 
> 
> 
<snip> 
> 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.
> 
<snip>