[x500standard] SV: Re: SV: Re: Can anyone explain ... (signing of bind)?
- From: "Erik Andersen" <era@xxxxxxx>
- To: <x500standard@xxxxxxxxxxxxx>
- Date: Mon, 18 Jul 2011 18:39:37 +0200
My guesswork is as follows:
The text on attribute certificate, etc. is leftover from the material
introduced by those including the Operational Security amendment. We pulled
most of out again, but we might not have gotten it all. It is difficult to
guess what happened in the mind of those people that including the stuff, as
they got most thing wrong.
My suggestion is to pull out what we do not understand, but only guessing
about.
Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: era@xxxxxxx
Skype: andersen-erik
http://www.x500.eu/
http://www.x500standard.com/
http://dk.linkedin.com/in/andersenerik
-----Oprindelig meddelelse-----
Fra: x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] På vegne af Kemp, David P.
Sendt: 18. juli 2011 18:09
Til: x500standard@xxxxxxxxxxxxx
Emne: [x500standard] Re: SV: Re: Can anyone explain ... (signing of bind)?
Also guesswork on my part, but the original text makes more sense to me.
Assumptions:
1) an attribute in the Directory is subject to an access policy
2) the requestor must hold a security clearance or other attribute in order
to satisfy the access policy
3) the directory response is encrypted (directly) for the requestor, but
only after the ACDF has determined that the access policy is satisfied.
I believe that "containing the attribute certificate" should be removed from
the first sentence, and "or other attribute" should be shifted left in the
last sentence. Clause 8.2 "Key and policy information extensions" is
clearly incorrect. But a reference to Clause 12.1, "Attribute Certificate
structure", would be appropriate, resulting in:
>> If the operation is to be signed and encrypted, an attribute certificate
>> (See Clause 12.1 of ITU-T Rec. X.509
>> | ISO/IEC 9594-8) may be used to convey the clearances required to
>> access the attribute. The***attributeCertificationPath* is used to
>> convey a security clearance or other attribute for rule based
>> access control, conveyed in an Attribute Certificate, optionally with the
>> certificates needed to validate the Attribute Certificate.
I won't speculate on whether "If the operation is to be signed and
encrypted" is appropriate; the access control scenario should be equally
valid if the operation were unencrypted but conveyed over a physically- or
cryptographically- (TLS, IPSec) secure channel.
Dave
-----Original Message-----
From: x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] On Behalf Of David Chadwick
Sent: Sunday, July 17, 2011 11:38 AM
To: x500standard@xxxxxxxxxxxxx
Subject: [x500standard] Re: SV: Re: Can anyone explain ... (signing of
bind)?
Hi Erik
this is pure guesswork on my part, but if you are using MAC/MLS and the
directory response is encrypted, then it has to be encrypted to some
public key. In MAC/MLS that key could be the key of the security
level/clearance of the associated directory data, as opposed to the
public key of the requestor (DUA). Thus the user needs to know which
private key to use to decrypt the information, and the AC holds the
clearances that are needed. If the user has the clearances, then he will
indirectly have the private key needed to decrypt the data.
regards
David
On 17/07/2011 15:54, Erik Andersen wrote:
> Hi David,
>
> Probably due to my ignorance, I do not understand what an attribute
> certificate has to do with signing and encryption of the operation, and it
> not clear what attribute the paragraph talks about.
>
> If I do not understand it, others may be in the same siruation.
>
> In addition, the AttributeCertificationPath data type in 12.2 of X.509 is
> not that easy to understand.
>
> Erik Andersen
> Andersen's L-Service
> Elsevej 48,
> DK-3500 Vaerloese
> Denmark
> Mobile: +45 2097 1490
> e-amail: era@xxxxxxx
> Skype: andersen-erik
> http://www.x500.eu/
> http://www.x500standard.com/
> http://dk.linkedin.com/in/andersenerik
>
> -----Oprindelig meddelelse-----
> Fra: x500standard-bounce@xxxxxxxxxxxxx
> [mailto:x500standard-bounce@xxxxxxxxxxxxx] På vegne af David Chadwick
> Sendt: 17. juli 2011 15:01
> Til: x500standard@xxxxxxxxxxxxx
> Emne: [x500standard] Re: Can anyone explain ... (signing of bind)?
>
> Hi Erik
>
> I think it is a cut and paste error. If you remove "or other attribute,
> conveyed in an Attribute Certificate," from the last sentence and insert
> it into the first sentence, it starts to make sense, viz:
>
> If the operation is to be signed and encrypted, an attribute certificate
> containing the attribute certificate or other attribute, conveyed in an
> Attribute Certificate, may be used to convey the clearances required to
> access the attribute. The attributeCertificationPath is used to convey
> a security clearance for rule based access control, optionally with the
> certificates needed to validate the Attribute Certificate.
>
> the reference to X.509 appears to be wrong so I removed it
>
> regards
>
> David
>
> On 17/07/2011 09:55, Erik Andersen wrote:
>> A lot of garbage was introduced in the third edition of the Directory
>> Specifications and we are still struggling with some of the stuff.
>>
>> The following paragraph was introduces at the start of clause 8 or X.511
>> - Bind operation.
>>
>> ?The arguments of the operation may be signed, encrypted, or signed and
>> encrypted (see clause 15.3 of ITU-T Rec. X.501 | ISO/IEC 9594-2) by the
>> requestor. If so requested, the Directory may sign, encrypt, or sign and
>> encrypt the results. (The bit on encryption was later removed).?
>>
>> However, neither the bind argument nor the bind result specifies the
>> possibility for signing.
>>
>> The third edition also introduce signing of bind errors. Does that make
>> sense? The requestor cannot ask for signing of bind error, as the
>> securityParameters are not included in the bind argument.
>>
>> Now the very big question. Can anyone explain the following paragraph
>> introduced in the third edition of 8.1.2 Directory Bind arguments?
>>
>> If the operation is to be signed and encrypted, an attribute certificate
>> containing the attribute certificate (See Clause 8.2 of ITU-T Rec. X.509
>> | ISO/IEC 9594-8) may be used to convey the clearances required to
>> access the attribute. The***attributeCertificationPath* is used to
>> convey a security clearance for rule based access control, or other
>> attribute, conveyed in an Attribute Certificate, optionally with the
>> certificates needed to validate the Attribute Certificate.
>>
>> Erik Andersen
>>
>> Andersen's L-Service
>>
>> Elsevej 48,
>>
>> DK-3500 Vaerloese
>>
>> Denmark
>>
>> Mobile: +45 2097 1490
>>
>> e-amail: era@xxxxxxx
>>
>> Skype: andersen-erik
>>
>> http://www.x500.eu/
>>
>> http://www.x500standard.com/
>>
>> http://dk.linkedin.com/in/andersenerik
>>
>
--
*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
School of Computing, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@xxxxxxxxxx
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5
*****************************************************************
-----
www.x500standard.com: The central source for information on the X.500
Directory Standard.
-----
www.x500standard.com: The central source for information on the X.500 Directory
Standard.
Other related posts:
- » [x500standard] SV: Re: SV: Re: Can anyone explain ... (signing of bind)? - Erik Andersen
