Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets andProxies

From: "David P. Kemp" <[email-masked]>
Date: Wed, 11 Oct 2000 09:17:39 -0400 (EDT)

This discussion has already played out, in a different context, in the
S/MIME working group.

The concern is not that there is a logic hole; there is not.  If the
relying party does his job and the CAs and AA do theirs, names will
be coordinated so that they don't collide.  I can't see any reasonable
record company authorizing "John Smith" to listen to their tunes; John
will have an account number issued by the record company, a PI,
something formerly known as a QC unmistakeable identity, or some other
unique name form agreed to among the parties involved.

Mandating a reference to a particular PK certificate is unnecessarily
heavy-handed; it precludes, for example, rollover (rekeying the
subscriber's certificate.)  Designing applications that identify users
by their public keys is one choice, but it cannot be the only one
permitted by PKIX.

On the other hand, limiting the damage that can occur when parties do
not do their jobs properly is a legitimate security concern, so PKIX
should offer ObjectDigest as an option for environments where RPs
"trust" all 137 roots built into their browsers.

This is the solution adopted by S/MIME - the SigningCertificate
attribute identifies a PKC as:

  ESSCertID ::= SEQUENCE {
     certHash       Hash,
     issuerSerial   IssuerSerial OPTIONAL }

but use of that attribute is an option, not a requirement, of RFC 2634.

> 
> On Tue, 10 Oct 2000, Carlisle Adams wrote:
> 
> > Hi Polar,
> > 
> > > ----------
> > > From: 	Polar Humenn[SMTP:[email-masked]]
> > > Sent: 	Tuesday, October 10, 2000 3:27 PM
> > > To: 	Al Arsenault
> > > Cc: 	Stephen Farrell; Patrik  Faltstrom; [email-masked];
> > > [email-masked]; Thumrongsak Kosiyatrakul; Shiu-Kai Chin; Susan Older
> > > Subject: 	Re: Fwd: AttributeCertificates: Path Names to AC Holders,
> > > Targets  andProxies
> > > 
> > (...some text deleted...)
> > 
> > > The start of the solution is mandating the use of ObjectDigest, where
> > > a digest can be verified against the Holder's Public Key or Public Key
> > > Certificate. The question after that is where does one pull the
> > > Holder's cert or public key from, should it not be readily available,
> > > i.e. wasn't delivered with the AttributeCertificate. This would
> > > constitute having the entire DN path to the Holders public key
> > > certificate anyway, and using the ObjectDigest for verification of the
> > > identity.
> > 
> > > Could we suggest a critical attribute extension that will contain the
> > > path to the ObjectDigest?
> >  
> > Actually, the syntax in X.509 (2000) is that holder is a SEQUENCE of three
> > optionals (general name, issuer/serial, and object digest).  If the group
> > decides to do what you're suggesting, no new critical extension would be
> > necessary; all the profile would have to do is mandate two (or all three) of
> > the optional fields.
> 
> Not good enough. You still need a proper full DN path, (i.e. sequence of
> DNs) from the root CA of the Holder's certificate. You need it to locate
> the Holder's certificate to verify it against the ObjectDigest.

You don't "need" a sequence of DNs carried in a protocol or in an
attribute certificate to do path development; and it's not obvious why
it would even help.  If you know the Holder's DN and/or an IssuerSerial
reference and cannot find the Holder's PKC using that information, how
would knowing the DNs of CAs above the Issuer aid in finding it?

Dave

---

From: Polar Humenn <[email-masked]>
Date: Wed, 11 Oct 2000 10:07:55 -0400 (EDT)

On Wed, 11 Oct 2000, David P. Kemp wrote:

> The concern is not that there is a logic hole; there is not. 

I really beg to differ on this one. We have already figured out that
information was lost if the AC names a holder by only its first DN.
That is a hole in the logic of naming of the holder in general.

> If the relying party does his job and the CAs and AA do theirs, names
> will be coordinated so that they don't collide.  I can't see any
> reasonable record company authorizing "John Smith" to listen to their
> tunes; John will have an account number issued by the record company,
> a PI, something formerly known as a QC unmistakeable identity, or some
> other unique name form agreed to among the parties involved.

You are *suggesting* ways of how you think organizations will operate and
co-operate. The whole purpose of this AA exercise, at least as I see it,
is so that John Smith doesn't have to get his own ID at the record
company, or every company he wishes to do business with. He just uses his
own. 

I'm sure in something like the Military, one might have a common mandated
naming scheme, so this might not be an issue. It's a constrained
environment.

> by their public keys is one choice, but it cannot be the only one

I agree with respect to the key rollover issue. But as I said in my last
message, I think you need to have the objectDigest of the RootCA and not
the holder's certificate. That might not change as much. If it does, you
got a big problem anyway.

However, I think that AA's and users of AC that agree on a common
resolution to naming of RootCAs just might do it. That's not unreasonable
and is currently done with DNS.

> "trust" all 137 roots built into their browsers.

I know, it gets to be ludicrous after a while. :)

> but use of that attribute is an option, not a requirement, of RFC 2634.

I think that is what the objectDigest does. However, I think there is
still some problem.

Given that the AC can be used in CONSTRAINED environments of which,
something like a military can agree on a unique naming scheme for DN's,
then the Holder as a single DN should be fine.

However, there can be a DN path critical extension that completes the
Holder's Name. For widely interoperable environments this criticial
extension must be used.

Also, the same problem exists for ProxyInfo and TargetInfo attribute
extensions.

Care to tackle that one?

Cheers,
-Polar

> would knowing the DNs of CAs above the Issuer aid in finding it?

-------------------------------------------------------------------
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: Stephen Farrell <[email-masked]>
Date: Wed, 11 Oct 2000 15:30:24 +0100

FWIW I guess I agree with David (and Russ and Carlisle and James and ...)

Stephen.

Polar Humenn wrote:
> I really beg to differ on this one. 
[snip]

-- 
____________________________________________________________
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: Polar Humenn <[email-masked]>
Date: Wed, 11 Oct 2000 11:24:05 -0400 (EDT)

> > I really beg to differ on this one. 

What about adding a non-critical Attribute Extension that completes the DN
path of the Holder? That way, CONSTRAINED environments that emphatically
know where the DNs are defined need not have to deal with it.

However, widely scaled interoperable environments can deal with it
effectively and with assurance.

--
-- Full Directory Name of a Subject
--
DirectoryNamePath ::= SEQUENCE OF (1..MAX) OF DirectoryName 
	-- First is the subject's DirectoryName.
        -- Intermediates are the issuer of the previous DirectoryName
        -- Last is the RootCA of the Holder

--
-- Specific Type Alias for holderIssuerName attribute
--
HolderIssuerName ::= DirectoryNamePath
	-- Name path of the Holder's Issuer CA.

--
-- This attribute completes the Holder's name path up to its RootCA.
--
Attribute Extension:
      name           id-ce-holderIssuerName
      OID            { id-ce ? }
      syntax         HolderIssuerName
      criticality    MUST be FALSE

I think this or something like would solve the problem for Holders when
DN's are applicable.

I think there are still have problems for ProxyInfo and TargetInfo when
using GeneralNames and IssuerSerial.

Regards,
-Polar