Subject: RE: X.509 ACs vs. SPKI?

From: "Ellison, Carl M" <[email-masked]>
Date: Mon, 24 May 1999 17:32:36 -0700

Hi Russ,

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Monday, May 24, 1999 1:58 PM
> To: Carl Ellison
> Cc: Ari Huttunen; [email-masked]; [email-masked]; Carl Ellison; Carl
> Ellison
> Subject: Re: X.509 ACs vs. SPKI?
> 
> 
> At 09:22 AM 5/12/99 -0700, Carl Ellison wrote:
> >[snip]
> >
> >I see three problems doing the equivalent of SPKI within 
> X.509 and in 
> >particular with ACs.
> >
> >1.	The identification of issuer and subject is convoluted 
> at best.  Missing 
> >is the option that is needed for maximum security (not to mention 
> >anonymity): a public key or the hash of the key.  The 
> IssuerSerial option is 
> >subject to constraints not expressed in the certificate.  
> GeneralNames isn't 
> >constrained or defined, AFAIK, in this spec, so that too depends on

> >constraints not evident in the certificate.  The 
> ObjectDigestInfo might be 
> >used to refer to some public key, but that use isn't spelled 
> out -- and even 
> >then, it is only the subject ID that has this option so 
> identification of 
> >the Issuer is left troubled.
> 
> X.509 ACs offer three methods of binding the attributes to an 
> owner.  They
> each offer different advantages and disadvantages.
> 
> 	(1) Issuer Distinguished Name and Serial Number.  This binds the
> attributes to a particular X.509 public key certificate.
> 
> 	(2) Subject Distinguished Name.  This binds the 
> attributes to a collection
> of certificates that were issued to the same subject, perhaps 
> by different CAs.
> 
> 	(3) Hash of the Public Key.  This binds the attributes 
> to any certificate
> that contains the correct public key.
> 
> It is clear how (1) and (2) can be used.  And, (3) seems to 
> provide what
> Carl is looking for.  Right?  If so, maybe you can help flesh 
> out that part
> of the Internet-Draft.

Yes, if ACs allow the hash of the public key as the subject, then that
option makes what I call an authorization certificate and it works
just fine.  It's the first two cases that are broken because their
name spaces are not globally unique and meaningful to those involved
in making and using the certificate.

However, when I read the spec, I didn't see your case #3.  It must be
well hidden :)
 
> >2.	X.509 does not define the semantics of a certificate, 
> only the syntax.  I 
> >find this especially when mapping out the CDSA extensions 
> that extract SPKI 
> >authorization information from existing X.509 certificates 
> (so that our 
> >implementation will accept and use a mixture of certificate 
> types: X.509, 
> >PGP, SPKI, ....).  Interpreting an X.509v3 certificate 
> requires a different 
> >trust policy module (in CDSA terms -- the code module that 
> understands the 
> >semantics of each field) for each different CPS -- or, to an 
> approximation, 
> >for each different root key.  For example, SET cardholder 
> certificates 
> >define an authorization (permission to use a given PAN/EXP) 
> but plant that 
> >authorization in the CommonName field of the SubjectName.  
> Meanwhile, some 
> >extensions of the SET certificate carry authorization 
> information while 
> >others are to be used for chain validation only.
> 
> There should be common syntax and semantics for base 
> certificate fields.
> Certainly any private extension could be an issue.
> 
> I think that the semantics should be the same for any 
> certificate issued
> under the same Certificate Policy (CP), regardless of the 
> Certification
> Practice Statement (CPS) used by a particular CA.

Perhaps I used the wrong word.  The fact remains that the code that
interprets a full X.509 certificate (including all extensions) needs
to be aware of (to embody) the definitions found in some paper
document.  This is by contrast with SPKI certificates that can be
processed through tuple-reduction without any special knowledge about
such paper documents.  That is why SPKI can have a single Trust Policy
engine while X.509 requires a different one for each application (in
the limit, for each root key).

> >3.	X.509 may be able to define SDSI names, but there is no 
> mechanism for 
> >referring to a fully qualified SDSI name.  That means that the only

> >mechanisms for making an SPKI attribute certificate (one 
> that gives an 
> >authorization to a named entity or group) have to rely on 
> assumptions about 
> >naming conventions.  In particular, I see no way to express:
> >
> >	(name <key> N_1 N_2 ... N_k)
> >
> >in X.509.
> 
> The  X.509 public key certificate provides (name <key>).
> 
> The X.509 ACs could provide (name N_1), (name N_2 N_3), ... 
> (name N_k).
> Where a collection of ACs each contain one or more attributes.

I don't believe you're talking about the same thing I am, Russ.

Unless something has been added very recently to X.509 to accommodate
this, the spec does not permit me to use a list of the root key plus
all names in the certificate chain down to the leaf name and use that
list as the subject of an AC.  Have I missed something?

 - Carl

---

From: Russ Housley <[email-masked]>
Date: Tue, 25 May 1999 13:52:36 -0400

Hi Carl.

[snip]

>list as the subject of an AC.  Have I missed something?

Maybe we did miscommunicate.  I assumed that N_1 .. N_k were attributes
that you wanted to bind to name.

Russ

---

From: [email-masked]
Date: Tue, 25 May 1999 17:10:09 -0700

sorry i sent this to carl when i meant to copy the whole list

      hoyt
---------------------- Forwarded by Hoyt Kesterson/US/BULL on 05/25/99
05:09 PM ---------------------------

Hoyt Kesterson
05/25/99 03:33 PM

To:   "Ellison, Carl M" <[email-masked]>
cc:
Subject:  RE: X.509 ACs vs. SPKI?  (Document link not converted)

at the risk of disrupting such violent argreement - where is it written,
other than in spki land, that the same pubic key cannot be in more than one
certificate. if a key appears in two certificates of owner x, you cannot
link an attribute certificate to a specific one of those certificates via
the public key

    hoyt

"Ellison, Carl M" <[email-masked]> on 05/25/99 01:03:41 PM

To:   "'Stephen Kent'" <[email-masked]>, "Ellison, Carl M"
      <[email-masked]>
cc:   [email-masked], [email-masked] (bcc: Hoyt Kesterson/US/BULL)
Subject:  RE: X.509 ACs vs. SPKI?

Steve,

as I've said before, we tend to be in violent agreement :)

Sometime (not on this thread) we can resume our debate about
the meaning of names, but I'm glad we agree that for secure binding,
the hash of the public key is a fine globally unique identifier and an
unanchored text name is wide open to abuse.

If that can be made clear in the spec -- and if the issuer can also be
identified by hash of the public key -- then the AC begins to look
like a certificate I can readily use in an authorization computation.
[Sometime, I should show you the mechanism we've planned for CDSA that
does authorization computations for all certificate types, not just
SPKI.....]

 - Carl

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Tuesday, May 25, 1999 11:42 AM
> To: Ellison, Carl M
> Cc: [email-masked]; [email-masked]
> Subject: RE: X.509 ACs vs. SPKI?
>
>
> Carl,
>
> I agree that the only safe way to bind an attribute cert to
> an identity
> cert is via the public key hash. That's what I always recommend to
my
> clients.
>
> Look at the draft profile for attribute certs recently
> published by Stephen
> Farrell and it's easy to locate the key hash as pointer.  The real
> difference here is that X.509 believes that certs with public
> keys should
> contain a name that is not purely a local matter.
>
> The hash is the most secure way to bind an attribute (yes,
> "authorization"
> is a better name) cert to the identity cert, and I'll suggest that
we
> mandate it in our profile as we progress.
>
> Steve
>

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 28 May 1999 15:54:48 +0200

Aram,
One solution is to use a PKC containing a pseudonym but where the CA guarantees that
you can trace the individual in case of criminal actions. 

I think that you should consider another much more flexible model of using ACs where the original
subject has been authorized with a pseudonym  AC (or just a dynamic credential) but where the AC
subject is the authorizing organization and associated PKC.

                 http://www.mobilephones-tng.com/v100/dynamiccerts.html

This solution could be even applied to governmental (official) use as well as it may (or may not) be of particular
interest who the individual officer is, but where the authorizer has full control (logging) of each officer's activities.

E.g. if you try to authorize an immigration form, the authorizing organization can check that you
have this authority during the signing and return the authority's sign with an AC containing the
minimum external identity information required.   Like a digital replacement for the currently used
authority stamp and officer's handwritten signature.

May I ask you if the application is something along those lines or entirely different?

Regards
Anders Rundgren

----------
From:  Stephen Farrell [SMTP:[email-masked]]
Sent:  Friday, May 28, 1999 12:21
To:  Aram Perez
Cc:  [email-masked]; [email-masked]
Subject:  Re: X.509 ACs vs. SPKI? 

Aram,

> Does either path offer the ability to grant a permission without revealing
> the identity of who is being granted the permission? I was talking with some
> folks yesterday who want to implement a very large PKI system used to access
> control but they have legal requirements in certain cases to keep the
> identity of the user private.

Can't recall for spki, but the ACs I-D does have support
for encrypted attributes, but this is more a case
of concealing the permissions, rather than the identity
which is presumably visible in a public key cert anyway.

Regards,
Stephen.

---

From: [email-masked]
Date: Fri, 28 May 1999 13:56:55 -0400

The easiest ASN.1 to use for Denis' construct is probably:
ESSCertID ::=  SEQUENCE {
     certHash       DigestInfo,          -- see PKCS-1
     issuerSerial        IssuerSerial OPTIONAL
}

     The syntax of DigestInfo is, in RFC 2437 (PKCS-1 version 2):
DigestInfo     ::=  SEQUENCE {
     digestAlgorithm     AlgorithmIdentifier,
     digest         OCTET STRING }
     which is basically the same as your suggestion.

          Tom Gindin

"Aram Perez" <[email-masked]> on 05/28/99 01:12:30 PM

To:   [email-masked], [email-masked]
cc:    (bcc: Tom Gindin/Watson/IBM)
Subject:  Re: X.509 ACs vs. SPKI?

Hi Steve,

> Aram,
>
> We need to remain algotihm independent, and thus we cannot insist on just
> one hash function.  Our data structures that rely on hashes also specify
> which hash was employed, to prevent ambiguity.

The ASN.1 that Denis Pinkas wrote is:

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

Hash ::= OCTET STRING -- SHA1 hash of entire certificate

I'm not an ASN.1 expert, but where is the hash specified (other than in the
comment)? Is the definition of "Hash" wrong? Should it be something like:

Hash ::= SEQUENCE {
    hashAlgorithm AlgorithmIdentier,
    hashValue HashValue
}

HashValue ::= OCTET STRING

If I can paraphrase Solomon: "There is a time to be algorithm independent
and there is a time to be algorithm dependent." Why complicate and decrease
the performance of the software that has to look up a certificate. I doubt
that the data store/directory/database where the certificates are kept wants
to have a field/attribute for any and every possible hash we allow.

This also begs the question "Why the hash and not just the IssuerSerial?" It
might be my misunderstanding of X.509, but I was under the
impression/assumption that the Issuer and Serial Number uniquely identified
an X.509 certificate.

> The use of hashes as
> fingerprints for self-signed certs, to facilitate out of band verification
> has not been a subject of standardization so far, and that is the cause of
> some of the problems you cite.  We can try to encourage vendors to do the
> right thing, but if we don't standardize it, ...

Well I believe we should standardize it (i.e. pick 1 hash algorithm).

Regards,
Aram

---

From: "Flanigan, Bill" <[email-masked]>
Date: Fri, 28 May 1999 16:25:40 -0400

Hello Aram,

	Before this threat reaches total and complete entropy (and this
message should certainly do it!), the phenomenon of "uniqueness" applies
only to the PKI that issued the cert.  If you have a cert from each of the
30-40 or so self-signing CAs that come with your "out-of-the-box" browser,
chances are that there will be some duplications (say, in CN and/or cert
serial number) between but NEVER within PKIs--if there are any within a PKI,
I'd find myself another cert source pronto.  However, the combination of CN,
end-user public key, cert serial number, phase of the moon, and how many
times you've seen Episode I in the past 10 days all but guarantees the
uniqueness of ANY cert ever issued by ANY entity at least in this galaxy.

Best regards,
Bill Flanigan
 
> ----------
> From: 	Aram Perez[SMTP:[email-masked]]
> Sent: 	Friday, May 28, 1999 2:31 PM
> To: 	[email-masked]; [email-masked]
[snip]

> > Finally, an Issuer name and serial number SHOULD uniquely identify a
> cert,
> > but in reality there is insufficient control over Issuer names to
> guarantee
> > uniqueness.  
> 
[snip]

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 31 May 1999 09:44:12 +0200

Another possibility is to say that the ESSCertid hash should use
the hash function used for signing the authenticated attributes.