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

From: Darren Harter <[email-masked]>
Date: Tue, 1 Jun 1999 09:12:21 +0100

Russ,

Looks good to me.  Also, this would allow for easy searching when multiple hash algorithms are deployed by indexing with the ESSCertId encoding rather than the HashValue - after all they're both streams of octets.

I have one suggestion though. Having id-sha1 as the default in the otherHash seems at odds with the structure's naming.  I think the following would be better:

  HashAlgAndValue ::= SEQUENCE {
     hashAlgorithm AlgorithmIdentier DEFAULT (id-md5),
     hashValue HashValue }

Regards,

Darren

------------------------------------------------------------------------
Darren Harter BSc (Hons) CEng MBCS
Entegrity Solutions Corp
http://www.entegrity.co.uk
http://www.entegrity.com
Tel:  +44 (0) 1452 371383
Fax: +44 (0) 1452 371384
Cell: +44 (0) 7801 812850
Email: mailto:[email-masked]

-----Original Message-----
From:	Russ Housley [SMTP:[email-masked]]
Sent:	Friday, May 28, 1999 10:39 PM
To:	Aram Perez
Cc:	[email-masked]; [email-masked]
Subject:	Re: X.509 ACs vs. SPKI?

I aggree that including the hash algirith identifier would be preferable.
For ESS, it is too late, but we can do it in a backward compatible way:

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

  Hash ::= CHOICE {
     sha1Hash  HashValue,
     otherHash  HashAlgAndValue }

  HashAlgAndValue ::= SEQUENCE {
     hashAlgorithm AlgorithmIdentier DEFAULT (id-sha1),
     hashValue HashValue }

  HashValue ::= OCTET STRING

Russ

At 10:12 AM 5/28/99 -0700, Aram Perez wrote:
>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: "Fillingham, David W." <[email-masked]>
Date: Tue, 1 Jun 1999 10:34:06 -0400

Steve:

Thanks for the response!

I think the security concern you mention, that CAs might assert names in
authentication certificates that overlap with names independently asserted
by Attribute Authorities in Attribute Certificates is also a concern for
implementations of access control lists (I think your response more or less
acknowledges this).  It seems to me that the situation of many separate
organizations independently building access control lists is very similar to
that of many Attribute Authorities independently issuing attribute
certificates.  I think it would be difficult to find a vulnerability
associated with the use of distinguished names to link subscribers to
attribute certificates that would not also apply to the use of distinguished
names to link subscribers with access control list entries.

I am concerned that managing attribute certificates bound to specific keys
or certificates may be difficult in large, distributed systems.  After all,
one of the reasons for separating authorizations from authentication
certificates is that the authorization managers may be different from the
identity managers.  If one is not careful, one could find that every time an
authentication certificate is renewed or rekeyed, the subscriber's attribute
certificates all become invalid all at once.  Binding attribute certificates
to specific certificates or public keys requires a management interaction
between Certification Authorities and Attribute Authorities that may be
difficult to establish and maintain.

So I hope the IETF does not come down too hard against using names to link
authentication certificates and attribute certificates.

Dave

> ----------
> From: 	Stephen Kent[SMTP:[email-masked]]
> Sent: 	Thursday, May 27, 1999 11:34 AM
> To: 	Fillingham,  David W.
> Cc: 	[email-masked]
> Subject: 	RE: X.509 ACs vs. SPKI?
> 
> Dave,
> 
> Good point.  One really needs to check the name from an identity cert in
> context, e.g., after making sure that the whole cert chain is acceptable
> for the context in question.  if we made more use of nameConstraints, this
> would be easier to manage and less error/attack prone.  I suspect that
> part
> of the alarm cited here arises from a concern that imeplementations of
> access controllers will fail to impose the necessary constrain checks and
> thus will open up new avenues of attack.  For example, say you receive an
> attribute cert and identity cert from a user. The module for identity cert
> validation is invoked and it returns OK, because the user in question is
> authorized to do something in your system.  However, the attribute cert
> was
> really bound to another user with the same subject name, due to inadeqaute
> controls over name spaces, or due to malicious behavior on the part of a
> CA
> in some other administrative domain.  The result might be a granting of
> inappropriate access to the user.  While it is true that the same thing
> could happen based solely upon subject name mismanagement, the
> opportunities for these sorts of errors may be even greater when we add
> the
> additional complexity of processing ACs.  I won't claim that this is an
> airtight argument, but I think it captures the flavor of the concerns that
> motivate soem fo the discussion you are seeing on the list.
> 
> Steve
>

---

From: [email-masked]
Date: Thu, 17 Jun 1999 16:06:52 -0500

Steven Kent wrote:

>Denis,
>
>I tend to agree with Russ and Stephen on this one.  It seems reasonable to
>be able to encrypt some parameters in an AC, for any of the application
>examples cited.  If we want to be able to store ACs in directories without
>having to rely exclusively on directory access controls for
>confidentiality, then encryption of the attributes seems like a good
>mechanism. Yes, this may mean that the encrypted fields in the AC will be
>accessable by a limited set of entities, who may often be known at the time
>of AC creation. (Thye don't have to be know at this time, since it may be
>feasible to dynamically distributed the necessary decryption material
>later, e.g., incrementally.) I don't see this as a problem; often an AC may
>be quite constrained in the set of entities that will accept it anyway, if
>one views ACs as capabilities.
>
>Steve

More generally, I think there will be many instances where
selected entries in the directory will need to be cryptographically
protected, *in addition* to robust directory access controls.
This is especially true as more and more "user account" type
of information is stored/_aggregated_ in the directory.

David K. Hemsath, Team Lead (Security)
SecureWay SysMgmt/Architecture/Standards
IBM Corporation; 11400 Burnet Road; Austin, TX 78758 USA
Tel.: +1(512)838-3618 T/L 678; Fax: 0156
Pager: 800-946-4646/PIN=1400035/www.mobilecomm.com
[email-masked]

---

From: [email-masked]
Date: Fri, 18 Jun 1999 11:43:29 -0500

My preference is for the use of CMS.  It's proven very useful for the Kerberos
PK-Init work in the CAT WG.  And, as you said, it's relatively easy to pick up
freeware or vendor S/MIME tooklits with CMS/PKCS#7 support.

Stephen Farrell <[email-masked]> on 06/18/99 08:59:56 AM

To:   "Miklos, Sue A." <[email-masked]>
cc:   David Hemsath/Austin/IBM@IBMUS, [email-masked], [email-masked]
Subject:  Re: X.509 ACs vs. SPKI?

Sandi,

I did look at EncryptedAttributeSyntax when I was writing up the
draft but chose to go with CMS EnvelopedData for a few reasons:-

- CMS (or at least pkcs#7) is much more widely implemented today
- referencing CMS requires much less work for the group than
  profiling EncryptedAttributeSyntax from scratch
- I find it handy to use EnvelopedData, since I can check
  interop easily (I extract the ciphertext attribute value,
  put on some MIME headers and feed it to our S/MIME
  product)
- ignorance:-) Personally, I just don't understand what bytes
  to generate for things like:

      keyProtection PROTECTION-MAPPING ::=
               SECURITY-TRANSFORMATION {genEncryption}

However, if there were significant advantages from, or lots of
support for, moving to the X.501 syntax then I guess we should
consider it.

Regards,
Stephen.

---

From: "Miklos, Sue A." <[email-masked]>
Date: Fri, 18 Jun 1999 13:27:32 -0400

Stephen, I see your point!  thanks for the feedback.

Sandi Miklos

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Friday, June 18, 1999 10:00 AM
To: Miklos, Sue A.
Cc: [email-masked]'; [email-masked]; [email-masked]
Subject: Re: X.509 ACs vs. SPKI? 

Sandi,

Regards,
Stephen.