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

From: "Miklos, Sue A." <[email-masked]>
Date: Fri, 18 Jun 1999 08:35:26 -0400

I've excerpted the following clause from the 1997 X.501 with respect to an
encrypted attribute template.  Any comments on the usefulness of the
structure are most appreciated.

Sandi

18.2.2	Encrypted Attribute Value Template
If an encrypted variant is required of an existing directory attribute type,
the following syntax is used:
EncryptedAttributeSyntax {AttributeSyntax} ::= SEQUENCE {
		keyInfo		SEQUENCE OF KeyIdOrProtectedKey,
		encAlg		AlgorithmIdentifier,
		encValue		ENCRYPTED { AttributeSyntax } }
KeyIdOrProtectedKey ::= SEQUENCE {
		keyIdentifier	[0]	KeyIdentifier OPTIONAL,
		protectedKeys	[1]	ProtectedKey OPTIONAL}
-At least one key identifier or protected key must be present 
				}
ProtectedKey  ::=  SEQUENCE  {
	authReaders		AuthReaders,
					-- if absent, use attribute in
authorized reader entry
	keyEncAlg		AlgorithmIdentifier  OPTIONAL,
					--  algorithm to encrypt encAttrKey
	encAttKey		EncAttKey  }
					-- confidentiality key protected
with authorized user's
					-- protection mechanism
AuthReaders  ::=  SEQUENCE OF Name
EncAttKey ::= PROTECTED {SymmetricKey, keyProtection}
SymmetricKey ::= BIT STRING
keyProtection PROTECTION-MAPPING ::= 
	SECURITY-TRANSFORMATION {genEncryption}

NOTE -  It is not reasonable that ordering matching rules or sub-string
matching rules be used for encrypted attributes. It is also recommended that
encrypted attributes are only defined for user attributes.

AttributeSyntax is the clear text syntax of the attribute and
EncryptedAttributeSyntax the syntax of the equivalent confidential
attribute. 
The keyIdentifier may be the identifier of a certified public key as held in
the Subject Public Key Identifier extension field defined in ITU-T X.509|
ISO/IEC 9594-8 Clause 12, or the identifier of a symmetric key and
associated security control information. 
The authReaders identifies those subjects who are permitted to retrieve the
ProtectedKey. 
The keyEncAlg is the identifier for the algorithm used to encrypt the
encAttKey, which is the  identifier for the key used to apply the
confidentiality service.
The genEncryption SECURITY-TRANSFORMATION defines the transformation which
is used for key distribution. This is further defined in Clause 15.3.1. This
transformation may be used with any encryption algorithm, including
reversible public key algorithms and symmetric key algorithms. 
NOTE -  Key management, which includes key distribution, is within the
purview of some administratively controlled security policy. Therefore, this
specification does not constrain the genEncryption SECURITY-TRANSFORMATION
in such a manner as to preclude the security manager of the DMD from
specifying the precise details of key distribution. Furthermore, this
specification does not require qualities of the genEncryption
SECURITY-TRANSFORMATION such that these qualities preclude the use of
particular key distribution mechanisms.

Support for an attribute does not imply support for the equivalent encrypted
attribute.
Where a user attribute is defined in this set of specifications, the object
identifiers for the encrypted equivalent of that attribute are  allocated in
ITU-T X.520 | ISO/IEC 9594-6, Annex A.

18.2.3	Attribute for Confidentiality Key
If it is necessary to distribute information about the encryption that
provides confidentiality of stored data, the following attribute shall be
used:

confKeyInfo  ATTRIBUTE  ::=  {
	WITH SYNTAX			ConfKeyInfo,
	EQUALITY MATCHING-RULE	readerAndKeyIDMatch
	ID				id-at-confKeyInfo }
ConfKeyInfo  ::=  SEQUENCE  {
	keyIdentifier		KeyIdentifier,	
	protectedKey		ProtectedKey }

18.2.4  Reader and Key Identifier Matching Rule
A matching rule for a list of authorized readers and their associated keys
is as follows:
 
readerAndKeyIDMatch MATCHING-RULE  ::=  {
	SYNTAX	ReaderAndKeyIDAssertion
	ID		id-mr-readerAndKeyIDMatch  }
ReaderAndKeyIDAssertion  ::=  SEQUENCE {
	keyIdentifier	KeyIdentifier,
	authReaders	AuthReaders OPTIONAL  }
The matching rule returns a TRUE if all of the components that are present
in the presented value match the corresponding components of the attribute
value, as follows:
a)	keyIdentifier matches if it is equal to the keyIdentifier component
of the ProtectedKey in the stored attribute value;
b)	if present the authReaders matches if it is equal to one of the
names in the authReaders component of the ProtectedKey in the stored
attribute value.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, June 17, 1999 5:07 PM
To: [email-masked]
Subject: Re: X.509 ACs vs. SPKI?

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: Stephen Farrell <[email-masked]>
Date: Fri, 18 Jun 1999 14:59:56 +0100

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:

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.