RE: attribute encryption (was: Re: X.509 ACs vs. SPKI?)

["Linn, John" <jlinn@xxxxxxxxxxxxxxxxxxxx>]

I agree with Stephen's earlier comments supporting the inclusion of an
encrypted attribute facility, which is explicitly excluded from ac509prof's
basic conformance level.  While attribute encryption (like PKIs generally)
introduces infrastructure requirements, it also allows valuable functions
unavailable otherwise. Can we navigate this argument by retaining the
definition of encrypted attributes, but separating any conformance
requirements therefor from conformance to other aspects of the
"proxy-enabled tier"?  I can envision non-proxy cases where encrypted
attributes would be useful, and proxy cases where they wouldn't be
necessary. 

--jl

> -----Original Message-----
> From: Bob Blakley [mailto:blakley@dascom.com]
> Sent: Tuesday, June 08, 1999 2:53 PM
> To: Denis Pinkas; Stephen Farrell
> Cc: ietf-pkix@imc.org
> Subject: Re: attribute encryption (was: Re: X.509 ACs vs. SPKI?)
> 
> 
> Denis Pinkas writes:
> 
> >The complexity lies in the fact that to encrypt a field the 
> public key of the
> target is
> >needed. This places an additional constraint in terms of key 
> management: this
> mandates
> >targets to possess public encryption keys while ACs may work 
> without the
> target to have
> >such keys and certificates. This "doubles" the complexity. I 
> would like AC to
> be
> >deployable without the need for targets to possess any 
> private key, which is
> possible as
> >long as attributes are in clear text.
> 
> I fear the added complexity much more than doubles....
> 
> >To be very precise, I would like a basic document NOT 
> supporting encrypted
> attributes.
> >If you think it is very important, then make a *separate* 
> document so that I
> can refer
> >to one (simple) RFC and so that I comply with it without any 
> need/requirement
> for
> >supporting encrypted attributes and the related infrastructure.
> 
> I agree with Denis here.
> 
> --bob
> 
> Bob Blakley (blakley@dascom.com)
> Chief Scientist, Dascom
> 
> 
>