Re: [mile] [sacm] Fwd: New Version Notification for draft-mandm-sacm-rolie-configuration-checklist-00.txt

[Adam Montville <[e-mail]>]

Stephen,

I have comments/responses/questions inline. Let's try to carve some time
out in Prague (I'm assuming your'e going to be there) to really go over
this. We can probably help with that template you mentioned in another
thread as well.

Thanks again for your feedback.

Kind regards,

Adam

On Wed, Jun 28, 2017 at 2:43 PM Adam Montville <[e-mail]>
wrote:

> Thanks, Stephen.
>
> With respect to producing a standard template for ROLIE extensions, I
> think that could be useful, either as a separate draft or, perhaps, as an
> appendix in ROLIE proper.
>
> We'll get to your other comments as soon as possible.
>
> Kind regards,
>
> Adam
>
> On Wed, Jun 28, 2017 at 11:00 AM Banghart, Stephen A. (Fed) <
> [e-mail]> wrote:
>
>> All,
>>
>>
>>
>> I finished my review of this document and had some personal
>> feedback/would like to start some discussion. I’d also like to pose a
>> question to the group/authors: would it be valuable to produce a standard
>> template for ROLIE Extensions? We could create a template that would
>> enumerate the required and optional sections, and discuss the intended
>> content of each section. If this would provide value to anyone I’d be
>> willing to put it together.
>>
>>
>>
>> *Introduction:*
>>
>>
>>
>> How would ROLIE fit into the checklist ecosystem you describe here? I
>> understood your explanation of how these checklists may be used in general,
>> but not how they may be used/published/downloaded from a ROLIE repository.
>>
>
[AWM] I'm not following this question. This is a ROLIE extension, so it is
defining a checklist information type that can be shared. I wouldn't think
the extension should be where the ROLIE functions are explained (i.e.
published, downloaded, etc.). ROLIE provides collections of resources that
are interacted with using AtomPub and linked resources. So, I guess I'm not
really understanding what you're after here.


>
>>
>> *New information-types*
>>
>>
>>
>> I had a hard time trying to pin down what exactly would fall under the
>> “configuration-checklist” information type given the description here. I
>> think the list of configuration checklist components threw me off. For
>> example: ‘ A “Value” ’. What is the definition of value here? Is a
>> standalone “Value” a valid configuration-checklist information type? Some
>> of these things seem like valid checklist content, like rules and profiles,
>> but I didn’t see where the rest fit the definition given at the head of the
>> section.
>>
>
>>
>> In ROLIE SWD and ROLIE CSIRT, we provide a list of example information
>> that could be, if placed into <content> by themselves, classified as the
>> information type in question, rather than the components that make up that
>> information type. That approach may make it easier for me to understand the
>> configuration checklist information type at a higher level.
>>
>

[AWM] Would it help if we were to first describe what a configuration
checklist is? I think I see your point here. We launch straight into the
mechanics of it all, presuming that the reader is already steeped in our
lingo. So, we could start with something that literally defines
configuration checklists. I'll look at the SWID and CSIRT examples, thanks
for mentioning them.


>
>>
>> *Usage of Configuration Checklist Information in the Atom Publishing*
>>
>> *    Protocol*
>>
>>
>>
>> The first paragraph talks about “these requirements” but no requirements
>> are listed in this section. I may have misunderstood the XML snippet at the
>> bottom of this section, however.
>>
>
[AWM] I think this may be a numbering issue. It may make more sense if 4
were the parent to 5, which really starts all the requirements. We'll take
a look at the numbering again.


>
>>
>> *The 'atom:content' Element*
>>
>>
>>
>> The serialization type is provided as a MIME type in the content element,
>> so it doesn’t need to be declared in the specification. If a serialization
>> has some bearing on other requirements, the MIME type should probably be
>> referenced so that your requirement is machine enforceable.
>>
>
[AWM] Ok. I recall that we had a question about this, and were not sure how
to handle it. Bill, do you remember what it was?


>
>>
>> *The 'rolie:format' Element’*
>>
>>
>>
>> The format element describes the data model in use, not the
>> serialization. If I understand correctly (I may not), at it stands today
>> the relevant data model for this information-type is XCCDF and maybe OVAL,
>> which could be serialized in XML, JSON, and if you’re really creative, even
>> Excel, Word, and PDF. Discussing these data models would probably help me
>> pin down what the configuration checklist information type entails as well.
>>
>
[AWM] I think I see what you're saying. For the sake of discussion, let's
say we've got an Ubuntu Benchmark. Further, let's say that it exists in PDF
and XCCDF forms. Then, for each form, what would the 'atom:content' and
'rolie:format' elements be? I think for the XCCDF form it would be
'atom:content' is the XML mime type, then the 'rolie:format' would be
XCCDF. But for PDF?


>
>>
>> *Configuration checklist metadata included in the 'rolie:property'*
>>
>> *      Element*
>>
>>
>>
>> So after looking through these we’ve realized that some of them would be
>> valuable to include in the ROLIE core specification. I’ve sent an email to
>> the MILE list to request the addition of “content-version”, “content-id”,
>> and “content-published-date”. These would replace your “checklist version”,
>> ”title”, and “publication date” properties, respectively. We also already
>> have a “content-author” property, so you needn’t register “author”.
>>
>
[AWM] Will look to the MILE list and make some changes.


>
>>
>> For the rest of the properties, I would note that property names can’t
>> have spaces in them, as they form a URN (e.g.
>> urn:ietf:params:rolie:property:content-author-name).
>>
>
[AWM] Thanks for the hint. I think we were just enumerating.


>
>>
>> Is the product category property intended for human or machine
>> consumption? A non-standardized open world plain text description seems
>> dangerously vague for machine consumption. If this is something that is
>> important to this extension, a new IANA table where each of these
>> categories are enumerated and described would be a good solution.
>>
>
[AWM] We lifted these straight out of what the National Checklist Program
requests us (CIS) to enter when we share a new benchmark (configuration
checklist) with them. :-) I'm betting human consumption, but NIST would be
the authoritative answer. But, it could be something that helps automated
categorization?


>
>>
>> Depending on how these product categories are used, also consider
>> registering them as categories instead of properties. I’m not sure if these
>> values are more commonly used as organizing buckets or just as additional
>> identifying information.
>>
>
[AWM] That's a possibility.


>
>>
>> *Atom:link Registrations*
>>
>>
>>
>> You can have 0..n of any given link element.
>>
>
[AWM] Ok, that's good, thanks.


>
>>
>> These registrations would take place at
>> https://www.iana.org/assignments/link-relations/link-relations.xhtml,
>> which is designed to hold general purpose link relations. As described in
>> the ROLIE core link extension point section, domain specific link relations
>> shouldn’t be registered to this table.
>>
>>
>>
>> It would be helpful for me if you explicitly defined what you mean by
>> “conformance”. Is this implementation or usage conformance?
>>
>
[AWM] I believe implementation. The idea here is to put some guidelines
around how checklists can be related to each other and other properties.
But whether implementation or use depends on perspective. Maybe we need to
learn more about this.


>
>>
>> *IANA Considerations*
>>
>>
>>
>> I’m unclear on what the “New IANA table for "ROLIE Entry Format"” block
>> of text is meant to be. Is this a new table registration? ROLIE core
>> doesn’t establish a table for registering formats. CVRF and CVE are
>> probably not relevant formats for configuration checklists regardless
>> right? I would imagine those are formats used to describe some future
>> “vulnerability” information type.
>>
>
[AWM] We had another enum ref type of draft, and I wonder if htat's not
needed here. Bill, do you remember?


>
>>
>> The reference field of the information type registration should contain a
>> reference to “this document”, to satisfy the registration requirement. The
>> registrations for links, properties, and categories will have to be listed
>> here at some point as well.
>>
>
[AWM] Ok, thanks.


>
>>
>> Thanks,
>>
>> Stephen Banghart
>>
>>
>>
>> *From:* sacm [mailto:[e-mail]] *On Behalf Of *Adam Montville
>> *Sent:* Friday, June 16, 2017 11:20 AM
>> *To:* [e-mail]
>> *Subject:* [sacm] Fwd: New Version Notification for
>> draft-mandm-sacm-rolie-configuration-checklist-00.txt
>>
>>
>>
>> Not necessarily for immediate review, but we've submitted a ROLIE
>> extension for configuration checklists. This is intended to get the
>> conversation started at some point.
>>
>> ---------- Forwarded message ---------
>> From: <[e-mail]>
>> Date: Fri, Jun 16, 2017 at 10:07 AM
>> Subject: New Version Notification for
>> draft-mandm-sacm-rolie-configuration-checklist-00.txt
>> To: Bill Munyan <[e-mail]>, Adam Montville <
>> [e-mail]>
>>
>>
>>
>>
>> A new version of I-D,
>> draft-mandm-sacm-rolie-configuration-checklist-00.txt
>> has been successfully submitted by Adam Montville and posted to the
>> IETF repository.
>>
>> Name:           draft-mandm-sacm-rolie-configuration-checklist
>> Revision:       00
>> Title:          Definition of the ROLIE configuration checklist Extension
>> Document date:  2017-06-16
>> Group:          Individual Submission
>> Pages:          10
>> URL:
>> https://www.ietf.org/internet-drafts/draft-mandm-sacm-rolie-configuration-checklist-00.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-mandm-sacm-rolie-configuration-checklist/
>> Htmlized:
>> https://tools.ietf.org/html/draft-mandm-sacm-rolie-configuration-checklist-00
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-mandm-sacm-rolie-configuration-checklist-00
>>
>>
>> Abstract:
>>    This document extends the Resource-Oriented Lightweight Information
>>    Exchange (ROLIE) core by defining a new information-type to ROLIE's
>>    atom:category pertaining to security configuration checklists.
>>    Additional supporting requirements are also defined which describe
>>    the use of specific formats and link relations pertaining to the new
>>    information-type.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>