Re: [mile] [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt

["Chandrashekhar B" <[e-mail]>]

Mike,

There was a comment about SCAP Repo in this thread, which was not initiated
by me. I am responding to that comment now as we addressed that.

Now, is this contribution to IETF? There's a good amount of discussion
happening in the SACM list around content repository. If this is useful,
whoever authors the draft, am happy to share it. The intention is not to
influence anybody but to share it if it make sense.

Chandra.

-----Original Message-----
From: Michael Hammer [mailto:[e-mail]] 
Sent: Friday, December 14, 2012 7:22 PM
To: [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: [mile] [sacm] New draft for review and comment:
draft-field-mile-rolie-00.txt

Is this intended to be a contribution to the IETF?

Mike


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Chandrashekhar B
Sent: Friday, December 14, 2012 3:10 AM
To: 'Field, John'; 'Luis Nunez'
Cc: [e-mail]; [e-mail]
Subject: Re: [mile] [sacm] New draft for review and comment:
draft-field-mile-rolie-00.txt

Reopening an old thread...

>The issues that would need to be resolved include making the 
>authentication
to the scaprepo seamless >(possible, at least in principal, using existing
Web Single Sign On protocols) and dealing with differences in >interaction
style...for example, I notice that scaprepo seems to prefer the use of POST
for all operations >(including a read operation).  As a general rule, it is
best to support GET for read operations, and reserve POST >for write
operations.  But, this is a relatively minor issue at this point.  The more
important point is that by >using a REST approach such an integration would
become possible, and that would be of benefit to users >dealing with
indicators, incident response, and assessment and compliance, etc....we
could tie it all together >quite nicely.

We have now addressed these concerns in SCAP Repo's web service interface.
The authentication and authorization rely on an HTTP Authorization header
containing an optional authorization assertion. I say optional because that
is to be used by subscribers. 

Also, all the interfaces are now HTTP GET based. 

The interface document is available here:
https://www.scaprepo.com/SCAPRepoWebService and the client SDK can be
downloaded from https://www.scaprepo.com

Appreciate your feedback!

Chandra.

-----Original Message-----
From: Luis Nunez [mailto:[e-mail]]
Sent: Thursday, September 06, 2012 11:36 AM
To: Field, John
Cc: [e-mail]; [e-mail]
Subject: Re: [sacm] New draft for review and comment:
draft-field-mile-rolie-00.txt

John,
this definitely is of interest and could be related to past discussions
around content repositories.  

I know of two publicly accessible (REST) repositories that could potential
host this type of content.

http://scaprepo.com/SCAPRepoWebService
http://scapsync.com/api/

NIST is also working on a repository with webservices.

It would be interesting to prototype a sample document and flesh out issues.


-ln

On Sep 6, 2012, at 11:10 AM, Field, John wrote:

> All,
> 
> Cross posting this announcement from MILE to SACM, as I think this may 
> be
of interest within the SCAP community as well.  
> 
> The new draft referenced below describes a RESTful HTTP binding for
sharing incident, indicator, and other cyber security-related information.
In particular, the draft includes a suggested approach to retrieving a
related benchmark resource.  
> 
> I hope you'll find this draft to be of interest.  
> 
> Please post any questions or comments to the MILE list.
> 
> Regards,
> John
> 
> // John P. Field
> // Security Architect
> // EMC Office of the CTO
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Field, John 
> Sent: Thursday, September 06, 2012 10:53 AM
> To: <[e-mail]>
> Subject: New draft for review and comment: draft-field-mile-rolie-00.txt
> 
> All,
> 
> Please note that I have just posted a new draft for review and comment.
As stated in the abstract, the draft describes a RESTful HTTP binding for
sharing incident, indicator, and other cyber security-related information.
I hope you'll find this document to be of interest, and I look forward to
discussing any questions and/or comments that the group may have.
> 
> Regards,
> John
> 
> // John P. Field 
> // Security Architect 
> // EMC Office of the CTO 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: Wednesday, September 05, 2012 9:59 PM
> To: Field, John
> Subject: New Version Notification for draft-field-mile-rolie-00.txt
> 
> 
> A new version of I-D, draft-field-mile-rolie-00.txt
> has been successfully submitted by John P. Field and posted to the
> IETF repository.
> 
> Filename:	 draft-field-mile-rolie
> Revision:	 00
> Title:		 Resource-Oriented Lightweight Indicator Exchange
> Creation date:	 2012-09-05
> WG ID:		 Individual Submission
> Number of pages: 41
> URL:
http://www.ietf.org/internet-drafts/draft-field-mile-rolie-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-field-mile-rolie
> Htmlized:        http://tools.ietf.org/html/draft-field-mile-rolie-00
> 
> 
> Abstract:
>   This document defines a resource-oriented approach to cyber security
>   information sharing.  Using this approach, a CSIRT or other
>   stakeholder may share and exchange representations of cyber security
>   incidents, indicators, and other related information as Web-
>   addressable resources.  The transport protocol binding is specified
>   as HTTP(S) with a MIME media type of Atom+XML.  An appropriate set of
>   link relation types specific to cyber security information sharing is
>   defined.  The resource representations leverage the existing IODEF
>   [RFC5070] and RID [RFC6545] specifications as appropriate.
>   Coexistence with deployments that conform to existing specifications
>   including RID [RFC6545] and Transport of Real-time Inter-network
>   Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via
>   appropriate use of HTTP status codes.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm


_______________________________________________
sacm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sacm

_______________________________________________
mile mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mile