headers
johnsonhammond1 | 27 Apr 2013 19:28
Favicon

[plasma] Biggest Fake Conference in Computer Science

Biggest Fake Conference in Computer Science

We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.

We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware

Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 

We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Borland | 15 Apr 2013 11:20
Favicon

[plasma] <Recipient> in the GetCmsToken

[Boldon James classification: UNMARKED EXTERNAL]


Now we have our plasma client in demonstration form I performed some testing using an X.400 environment (STANAG 4406 to be precise).  The P772 encoded Plasma message was sent / received but I was denied access trying to read the message.  I tracked this down to the recipient I supplied in the GetCmsToken, rather than an SMTP address I have an X.400 O/R address, as below.

 

<Recipient>

    <Subject>s=ab51;o=borland5;p=boldonjames;a= ;c=gb</Subject>

</Recipient>

 

I think we need another attribute to specify the type of 'Subject' we have supplied, something similar to below?

 

<Recipient>

    <Subject type="x400">s=ab51;o=borland5;p=boldonjames;a= ;c=gb</Subject>

</Recipient>

 

Alan.

 

Alan Borland


Boldon James Limited, a QinetiQ company

Mobile:        +44 (0)7810 556709
Direct:         +44 (0)1270 507841
Switch:        +44 (0)1270 507800
Email:          alan.borland <at> boldonjames.com
Email (R):    abborland <at> qinetiq.r.mil.uk
Web:           www.boldonjames.com

 

 

 

 

 

<div>

<div>
<p>
<span>[Boldon James classification:
<span>
<span>UNMARKED</span></span></span><span><span><span>
</span><span>EXTERNAL</span></span></span><span><span></span></span><span>]</span></p>
<br>
</div>
<div>
<div class="WordSection1">
<p class="MsoNormal">Now we have our plasma client in demonstration form I performed some testing using an X.400 environment (STANAG 4406 to be precise).&nbsp; The P772 encoded Plasma message was sent / received but I was denied access trying to read the message.&nbsp;
 I tracked this down to the recipient I supplied in the GetCmsToken, rather than an SMTP address I have an X.400 O/R address, as below.</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">&lt;Recipient&gt;</p>
<p class="MsoNormal">&nbsp;&nbsp;&nbsp; &lt;Subject&gt;s=ab51;o=borland5;p=boldonjames;a= ;c=gb&lt;/Subject&gt;</p>
<p class="MsoNormal">&lt;/Recipient&gt;</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">I think we need another attribute to specify the type of 'Subject' we have supplied, something similar to below?
</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">&lt;Recipient&gt;</p>
<p class="MsoNormal">&nbsp;&nbsp;&nbsp; &lt;Subject type="x400"&gt;s=ab51;o=borland5;p=boldonjames;a= ;c=gb&lt;/Subject&gt;</p>
<p class="MsoNormal">&lt;/Recipient&gt;</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">Alan.</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal"><span>Alan Borland</span></p>
<p class="MsoNormal"><span><br></span><span lang="EN-US">Boldon James Limited,
</span><span lang="EN-US">a QinetiQ company</span><span lang="EN-US">
</span></p>
<p class="MsoNormal"><span>Mobile:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +44 (0)7810 556709<br>
Direct:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +44 (0)1270 507841<br>
Switch: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +44 (0)1270 507800<br>
Email:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="mailto:alan.borland <at> boldonjames.com" target="_blank"><span>alan.borland <at> boldonjames.com</span></a><br>
Email (R):&nbsp;&nbsp;&nbsp;&nbsp;<a href="mailto:abborland <at> qinetiq.r.mil.uk" target="_blank"><span>abborland <at> qinetiq.r.mil.uk</span></a><br>
Web:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="" target="_blank" title="http://www.boldonjames.com/"><span>www.boldonjames.com</span></a></span></p>
<p class="MsoNormal"><span>&nbsp;</span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;</span></p>
<p class="MsoNormal"><span>&nbsp;</span></p>
<p class="MsoNormal"><span>&nbsp;</span></p>
<p class="MsoNormal">&nbsp;</p>
</div>
</div>
</div>
Permalink | Reply | 0 comments |
headers
Jim Schaad | 19 Mar 2013 00:17

[plasma] FW: New Version Notification for draft-schaad-plasma-cms-04.txt

Update draft with a new way to handle encoding recipient infos.

Please look at and make sure that it makes sense.  Recommendations on other approaches should be discussed
if you feel they are better than the one offered here.  I am not emotionally attached to this encoding and we
discussed a couple of alternatives before choosing this one.

Jim

> -----Original Message-----
> From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org]
> Sent: Monday, March 18, 2013 4:07 PM
> To: ietf <at> augustcellars.com
> Subject: New Version Notification for draft-schaad-plasma-cms-04.txt
> 
> 
> A new version of I-D, draft-schaad-plasma-cms-04.txt
> has been successfully submitted by Jim Schaad and posted to the
> IETF repository.
> 
> Filename:	 draft-schaad-plasma-cms
> Revision:	 04
> Title:		 Plasma Service Cryptographic Message Syntax (CMS)
> Processing
> Creation date:	 2013-03-18
> Group:		 Individual Submission
> Number of pages: 31
> URL:             http://www.ietf.org/internet-drafts/draft-schaad-plasma-cms-
> 04.txt
> Status:          http://datatracker.ietf.org/doc/draft-schaad-plasma-cms
> Htmlized:        http://tools.ietf.org/html/draft-schaad-plasma-cms-04
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-schaad-plasma-cms-04
> 
> Abstract:
>    Secure MIME (S/MIME) defined a method of placing security labels on a
>    Cryptographic Message Syntax (CMS) object.  These labels are placed
>    as part of the data signed and validated by the parties.  This means
>    that the message content is visible to the recipient prior to the
>    label enforcement.  A new model for enforcement of policy using a
>    third party is described in RFC TBD
>    [I.D-draft-freeman-plasma-requirements].  This is the Policy
>    Augmented S/MIME (PLASMA) system.  This document provides the details
>    needed to implement the new Plasma model in the CMS infrastructure.
> 
>    An additional benefit of using the Plasma module is that the server,
>    based on policy, manages who has access to the message and how the
>    keys are protected.
> 
>    The document details how the client encryption and decryption
>    processes are performed, defines how to construct the CMS recipient
>    info structure, a new content to hold the data required for the
>    Plasma server to store the keys and policy information.  The document
>    does not cover the protocol between the client and the Plasma policy
>    enforcement server.  One example of the client/server protocol can be
>    found in RFC TBD [plasma-token].
> 
> 
> 
> 
> The IETF Secretariat
Permalink | Reply | 0 comments |
headers
Alan Borland | 13 Mar 2013 11:21
Favicon

[plasma] Verifying the signature of the LockBox.

[Boldon James classification: UNMARKED EXTERNAL]


When we open a message we have to determine if the message is a traditional S/MIME message or a Plasma message.  This is done by inspecting the CMS envelopedData layer looking for a Plasma LockBox. If the lockbox is found we verify the SignedData signature, but this got me thinking.  Should we verify just the integrity of the signature itself or should we also perform a full certificate path validation as well?   This would mean every user needs to trust a certificate from the Plasma Server (additional overhead - is this an issue?), but then if the Plasma Server is somehow compromised this would be a way of returning the error to the client.

 

I couldn't decide either way, at the moment we're doing a full certificate path validation.

 

Alan.

 

Alan Borland


Boldon James Limited, a QinetiQ company

Mobile:        +44 (0)7810 556709
Direct:         +44 (0)1270 507841
Switch:        +44 (0)1270 507800
Email:          alan.borland <at> boldonjames.com
Email (R):    abborland <at> qinetiq.r.mil.uk
Web:           www.boldonjames.com

 

 

 

 

 

<div>

<div>
<p>
<span>[Boldon James classification:
<span>
<span>UNMARKED</span></span></span><span><span><span>
</span><span>EXTERNAL</span></span></span><span><span></span></span><span>]</span></p>
<br>
</div>
<div>
<div class="WordSection1">
<p class="MsoNormal">When we open a message we have to determine if the message is a traditional S/MIME message or a Plasma message.&nbsp; This is done by inspecting the CMS envelopedData layer looking for a Plasma LockBox. If the lockbox is found we verify the
 SignedData signature, but this got me thinking.&nbsp; Should we verify just the integrity of the signature itself or should we also perform a full certificate path validation as well? &nbsp;&nbsp;This would mean every user needs to trust a certificate from the Plasma Server
 (additional overhead - is this an issue?), but then if the Plasma Server is somehow compromised this would be a way of returning the error to the client.</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">I couldn't decide either way, at the moment we're doing a full certificate path validation.</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">Alan.</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal"><span>Alan Borland</span></p>
<p class="MsoNormal"><span><br></span><span lang="EN-US">Boldon James Limited,
</span><span lang="EN-US">a QinetiQ company</span><span lang="EN-US">
</span></p>
<p class="MsoNormal"><span>Mobile:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +44 (0)7810 556709<br>
Direct:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +44 (0)1270 507841<br>
Switch: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +44 (0)1270 507800<br>
Email:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="mailto:alan.borland <at> boldonjames.com" target="_blank"><span>alan.borland <at> boldonjames.com</span></a><br>
Email (R):&nbsp;&nbsp;&nbsp;&nbsp;<a href="mailto:abborland <at> qinetiq.r.mil.uk" target="_blank"><span>abborland <at> qinetiq.r.mil.uk</span></a><br>
Web:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="" target="_blank" title="http://www.boldonjames.com/"><span>www.boldonjames.com</span></a></span></p>
<p class="MsoNormal"><span>&nbsp;</span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;</span></p>
<p class="MsoNormal"><span>&nbsp;</span></p>
<p class="MsoNormal"><span>&nbsp;</span></p>
<p class="MsoNormal">&nbsp;</p>
</div>
</div>
</div>
Permalink | Reply | 1 comment |
headers
Trevor Freeman | 28 Jan 2013 19:45
Picon

[plasma] SignedData vs. ContentInfo for keyatt-eps-kek

Hi Jim

 

An observation on the CMS draft is that you currently have the keyatt-eps-kek defined as a SignedData structure.

 

The standard CMS signature creation and verification APIs expect to have the ContentInfo structure as the output\input data stream as defined by S/MIME defines.

 

Net result when using these standard APIs is we end up manually removing the ContentInfo structure on creation and adding it on verification when processing the keyatt-eps-kek attribute. While not strictly necessary, it would streamline the code path if we were to use ContentInfo as we can skip the manual adding\removal of the ContentInfo structure.

 

Trevor 

<div>
<div class="WordSection1">
<p class="MsoNormal">Hi Jim<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">An observation on the CMS draft is that you currently have the keyatt-eps-kek defined as a SignedData structure.<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">The standard CMS signature creation and verification APIs expect to have the ContentInfo structure as the output\input data stream as defined by S/MIME defines.<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Net result when using these standard APIs is we end up manually removing the ContentInfo structure on creation and adding it on verification when processing the keyatt-eps-kek attribute. While not strictly necessary, it would streamline
 the code path if we were to use ContentInfo as we can skip the manual adding\removal of the ContentInfo structure.
<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Trevor <p></p></p>
</div>
</div>
Permalink | Reply | 0 comments |
headers
Jim Schaad | 17 Jan 2013 09:04

[plasma] FW: New Version Notification for draft-schaad-plasma-redact-00.txt

I have just submitted this draft. 

It has to do with how redacted documents would interact with Plasma servers.  This document is partially
there and partially a place holder.  It does reflect my currently thinking, but that is subject to wild
swings at the moment.

If you really want to go ahead and read and comment.

Jim

> -----Original Message-----
> From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org]
> Sent: Wednesday, January 16, 2013 11:40 PM
> To: ietf <at> augustcellars.com
> Subject: New Version Notification for draft-schaad-plasma-redact-00.txt
> 
> 
> A new version of I-D, draft-schaad-plasma-redact-00.txt has been
> successfully submitted by Jim Schaad and posted to the IETF repository.
> 
> Filename:	 draft-schaad-plasma-redact
> Revision:	 00
> Title:		 PLASMA and Redacted Documents
> Creation date:	 2013-01-16
> WG ID:		 Individual Submission
> Number of pages: 16
> URL:             http://www.ietf.org/internet-drafts/draft-schaad-plasma-redact-
> 00.txt
> Status:          http://datatracker.ietf.org/doc/draft-schaad-plasma-redact
> Htmlized:        http://tools.ietf.org/html/draft-schaad-plasma-redact-00
> 
> 
> Abstract:
>    Redacted documents are designed to have a single document which
>    allows different individuals to view different portions of the
>    document basd on the attributes of the individual.  In this document,
>    a protocol extension to the basic PLASMA protocol is described that
>    allows for multiple keys, each with a different policy, to be used in
>    a single electronic document for enforcement of redaction levels.
>    This document is agnostic relative to the actual format of the
>    redacted document, the only requirement being that the redacted
>    document be able to carry the PLASMA defined lock box.
> 
> 
> 
> 
> The IETF Secretariat
Permalink | Reply | 0 comments |
headers
Jim Schaad | 12 Jan 2013 02:17

[plasma] FW: New Version Notification for draft-schaad-plasma-cms-03.txt

New document released.

Moderate amounts of changes I think.

Jim

> -----Original Message-----
> From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org]
> Sent: Friday, January 11, 2013 5:13 PM
> To: ietf <at> augustcellars.com
> Subject: New Version Notification for draft-schaad-plasma-cms-03.txt
> 
> 
> A new version of I-D, draft-schaad-plasma-cms-03.txt has been successfully
> submitted by Jim Schaad and posted to the IETF repository.
> 
> Filename:	 draft-schaad-plasma-cms
> Revision:	 03
> Title:		 Plasma Service Cryptographic Message Syntax (CMS)
> Processing
> Creation date:	 2013-01-11
> WG ID:		 Individual Submission
> Number of pages: 39
> URL:             http://www.ietf.org/internet-drafts/draft-schaad-plasma-cms-
> 03.txt
> Status:          http://datatracker.ietf.org/doc/draft-schaad-plasma-cms
> Htmlized:        http://tools.ietf.org/html/draft-schaad-plasma-cms-03
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-schaad-plasma-cms-03
> 
> Abstract:
>    Secure MIME (S/MIME) defined a method of placing security labels on a
>    Cryptographic Message Syntax (CMS) object.  These labels are placed
>    as part of the data signed and validated by the parties.  This means
>    that the message content is visible to the recipient prior to the
>    label enforcement.  A new model for enforcement of policy using a
>    third party is described in RFC TBD
>    [I.D-draft-freeman-plasma-requirements].  This is the Policy
>    Augmented S/MIME (PLASMA) system.  This document provides the details
>    needed to implement the new Plasma model in the CMS infrastructure.
> 
>    An additional benefit of using the Plasma module is that the server,
>    based on policy, manages who has access to the message and how the
>    keys are protected.
> 
>    The document details how the client encryption and decryption
>    processes are performed, defines how to construct the CMS recipient
>    info structure, a new content to hold the data required for the
>    Plasma server to store the keys and policy information.  The document
>    does not cover the protocol between the client and the Plasma policy
>    enforcement server.  One example of the client/server protocol can be
>    found in RFC TBD [plasma-token].
> 
> 
> 
> 
> The IETF Secretariat
Permalink | Reply | 0 comments |
headers
Jim Schaad | 12 Jan 2013 02:16

[plasma] FW: New Version Notification for draft-schaad-plasma-service-04.txt

New draft has finally be posted.

Note - this draft has changed a great number of things, but has not yet addressed the options for policy
questions..  I am still trying to get my mind around what needs to be done in all of the different locations
and what it means for schema to try and get it all correct.  Sorry I haven't gotten that far.

I think that most of the issues people have raised other than that are included.  The examples at the end are
generated from my current code base and I believe reflect both the schema and the text of the draft.  I have
not however done a recent read through of all of the text to make sure that this is a correct statement.  The
schema should be correct as I did use a schema verify tool and came up with only one schema violation in the
examples.  That is the inclusion of an id attribute in the xacml:Request element.  This is not legal
according to the xacml schema.

Jim

> -----Original Message-----
> From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org]
> Sent: Friday, January 11, 2013 5:13 PM
> To: ietf <at> augustcellars.com
> Subject: New Version Notification for draft-schaad-plasma-service-04.txt
> 
> 
> A new version of I-D, draft-schaad-plasma-service-04.txt
> has been successfully submitted by Jim Schaad and posted to the IETF
> repository.
> 
> Filename:	 draft-schaad-plasma-service
> Revision:	 04
> Title:		 Plasma Service Trust Processing
> Creation date:	 2013-01-11
> WG ID:		 Individual Submission
> Number of pages: 68
> URL:             http://www.ietf.org/internet-drafts/draft-schaad-plasma-
> service-04.txt
> Status:          http://datatracker.ietf.org/doc/draft-schaad-plasma-service
> Htmlized:        http://tools.ietf.org/html/draft-schaad-plasma-service-04
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-schaad-plasma-service-04
> 
> Abstract:
>    RFC TBD describes a new model and set of requirements to implement a
>    labeling system on Cryptographic Message Syntax (CMS) objects where
>    the entity in charge of doing the label enforcement is under the
>    control of a central authority rather than the recipient of the
>    object.
> 
>    This document describes a protocol to be used by senders and
>    recipients of CMS objects to communicate with a centralized label
>    enforcement server.  The document outlines how a client will get the
>    set of labels or policies that it can use for sending messages,
>    composes a secure CMS object with a label on it and gets the
>    necessary keys to decrypt a CMS object from the server.  This
>    document is designed to be used with RFC TBD2 which describes the
>    extensions used in CMS objects to hold the label information.
> 
> 
> 
> 
> The IETF Secretariat
Permalink | Reply | 0 comments |
headers
Alan Borland | 4 Jan 2013 10:55
Favicon

[plasma] "Recipient List" thread and Distribution Lists

Ignoring the syntax of the "Recipient List" for the moment, but how will the recipient list mechanism work with distribution lists, especially those DLs expanded by the mail server?  If on send I supply the plasma server "dl <at> xyz.com" as a <Recipient> and "fred <at> xyz.com" receives a copy of the message as a result of the DL expansion then will fred be able to read the message?

 

Alan.

 

Alan Borland


Boldon James Limited, a QinetiQ company

Mobile:        +44 (0)7810 556709
Direct:         +44 (0)1270 507841
Switch:        +44 (0)1270 507800
Email:          alan.borland <at> boldonjames.com
Email (R):    abborland <at> qinetiq.r.mil.uk
Web:           www.boldonjames.com

 

 

 

 

 


Email classified by Boldon James Classifier - www.boldonjames.com

<div>
<div class="WordSection1">
<p class="MsoPlainText">Ignoring the syntax of the "Recipient List" for the moment, but how will the recipient list mechanism work with distribution lists, especially those DLs expanded by the mail server?&nbsp; If on send I supply the plasma server "<a href="mailto:dl <at> xyz.com">dl <at> xyz.com</a>"
 as a &lt;Recipient&gt; and "fred <at> xyz.com" receives a copy of the message as a result of the DL expansion then will fred be able to read the message?<p></p></p>
<p class="MsoPlainText"><p>&nbsp;</p></p>
<p class="MsoPlainText">Alan.<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal"><span>Alan Borland<p></p></span></p>
<p class="MsoNormal"><span><br></span><span lang="EN-US">Boldon James Limited,
</span><span lang="EN-US">a QinetiQ company</span><span lang="EN-US">
<p></p></span></p>
<p class="MsoNormal"><span>Mobile:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +44 (0)7810 556709<br>
Direct:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +44 (0)1270 507841<br>
Switch: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +44 (0)1270 507800<br>
Email:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="mailto:alan.borland <at> boldonjames.com" target="_blank"><span>alan.borland <at> boldonjames.com</span></a><br>
Email (R):&nbsp;&nbsp;&nbsp;&nbsp;<a href="mailto:abborland <at> qinetiq.r.mil.uk" target="_blank"><span>abborland <at> qinetiq.r.mil.uk</span></a><br>
Web:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="x-excid://7DBF0000/pas:x-excid:/7DC00001/jmp:http:/www.boldonjames.com/" target="_blank" title="http://www.boldonjames.com/">
<span>www.boldonjames.com</span></a><p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
</div>
<br><div>
<p><span>Email classified by
</span><span>Boldon James Classifier
</span><span>-</span><span>
<a href="http://www.boldonjames.com" target="_blank" title="http://www.boldonjames.com">
<span>www.boldonjames.com</span></a></span></p>
</div>
</div>
Permalink | Reply | 1 comment |
headers
Trevor Freeman | 14 Dec 2012 22:46
Picon

[plasma] PLASMA URL Authenticated Attribute

Hi Jim,

 

I was just looking at the CMS document in section 3.3 and noticed that the Plasma URL is defined as a single UTF8Sting.

 

aa-plasma-url ATTRIBUTE ::= {TYPE UTF8String IDENTIFIED BY id-aa-plasma-url}

 

This should be a Set of UTF8Stings as we can have more than one Plasma server on a message.

 

Trevor

<div>
<div class="WordSection1">
<p class="MsoNormal">Hi Jim,<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">I was just looking at the CMS document in section 3.3 and noticed that the Plasma URL is defined as a single UTF8Sting.
<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal"><span>aa-plasma-url ATTRIBUTE ::= {TYPE UTF8String IDENTIFIED BY id-aa-plasma-url}</span>
<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">This should be a Set of UTF8Stings as we can have more than one Plasma server on a message.<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Trevor<p></p></p>
</div>
</div>
Permalink | Reply | 1 comment |
headers
Jim Schaad | 6 Dec 2012 21:53

[plasma] Plasma Document Updates

I am currently in the middle of doing a large revision of the two documents
that I am the primary author on.  In the process of doing this update, I
have a few issues that I would like people to comment on.

1.   I am considering changing the element "WS-Token" in
"AuthenticationType".  Since the only place where this is currently being
used is for dealing with role tokens, I believe it would be useful to change
the name of the element to "RoleToken" as this would make it clearer what
goes here. 

2.  In the CMS document I have change the label from being an ASN.1 encoded
string to being the XML encoded string.  However, I am wondering if we
should make this an OCTET STRING which holds the XML encoded string so that
we can allow for compression to occur as an optional method of encoding it.
Does anyone see any problems with this?

 I have been thinking about the suggested on renaming from Ed and looking at
XAML.  I have decided to use Policy and PolicySet as the replacements for
Label/Leaf in this update.  However there are still some things that I have
not really made any conclusions for.

3.  Should we switch from using a simple string, or augment the simple
string, by allowing the XACML PolicyCombiningAlgId URIs this means that
"urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-overrides" and
"and" are the same thing.  There is no equivalent to "except", but it is
also possible this one is a figment of my imagination and there is no real
need for it.   One can do this in XACML by combining default-permit and
default-deny policies but I don't know if it is needed in real life or not.
The benefit of allowing the additional URIs is that there are a set of
policy combining algorithms already defined by XACML that should correspond
to things that are real and it makes it easier to augment the set of
combining strings.  The downside is that URIs are longer than the set of
short strings - does anyone have opinions on this?  The other downside of
using URIs is that the server may need to give the list of supported
combining algorithms to the client or we need to have an error for saying
that a combining algorithm is not supported.

4.  I am still working my way through the ways of specifying policy options
and have not made any decisions for myself let along ones that I would be
willing to impose on the document.  Any other options and opinions that
anyone wants to put in as input, I would be more than willing to get that
input at this time.

Jim
Permalink | Reply | 1 comment |

Gmane