Smalltalk › Squeak › Other › Squeak - Cryptography

Common Criteria Documentation...

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

28 messages Options

Kyle Hamilton

Common Criteria Documentation...

I found the Google Code project that Krishna started, and uploaded the
Common Criteria documentation I found (in PDF form) to it as an issue.
Unfortunately, I don't have SVN write access, and I don't know how to
get it either.

After reading it, I realized that it /IS/ a good idea for anyone
starting on CC validation to read it before they start. It's
important to realize what it is, and what the goals must be. (As
well, it also helps customers -- that'd include you, Ron -- understand
what the various validation levels are, and compare them to regulatory
requirement.)

--

-Kyle H
I speak only for myself. I don't have the faintest clue about anyone else.
_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Krishna Sankar-2

RE: Common Criteria Documentation...

I am still figuring out things with the Google project. By tomorrow cob,
will see how we all can get SVN write access. BTW, for the records, the
Google project is squeak-cc-validation
http://code.google.com/p/squeak-cc-validation/.

On the CC side, I think the major tasks are :

1. Decide on the protection profile(s) we want to address

2. Define the claims and security target

Most probably we would need 3-4 configurations

3. Start a function List and Test Matrix (Where can we host a
Wiki?) (This will help us prove our case, so we should start this task ASAP)

4. Develop the ToE

5. Understand and document the cc process relevant to us. Read
and mark the cc documents, talk with Labs et al

6. Formal cc effort

Kyle, the cc documentation will help us in these tasks. I will add these
tasks and will start double-clicking task #1.

Cheers
<k/>

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On
> Behalf Of Kyle Hamilton
> Sent: Monday, October 16, 2006 8:33 PM
> To: Cryptography Team Development List
> Subject: [Cryptography Team] Common Criteria Documentation...
>
> I found the Google Code project that Krishna started, and
> uploaded the Common Criteria documentation I found (in PDF
> form) to it as an issue.
> Unfortunately, I don't have SVN write access, and I don't
> know how to get it either.
>
> After reading it, I realized that it /IS/ a good idea for
> anyone starting on CC validation to read it before they
> start. It's important to realize what it is, and what the
> goals must be. (As well, it also helps customers -- that'd
> include you, Ron -- understand what the various validation
> levels are, and compare them to regulatory
> requirement.)
>
> --
>
> -Kyle H
> I speak only for myself. I don't have the faintest clue
> about anyone else.
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry

ptography
>

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Krishna Sankar-2

RE: Common Criteria Documentation...

In reply to this post by Kyle Hamilton

Kyle,

Can you see if you have the SVN write access ?
All,
Just as FYI, we need gmail address to become part of the Google
project and it has no Wiki. Any thoughts on the Wiki for us to document the
functionalities and the results of development/testing ?

Cheers
<k/>

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Kyle Hamilton

Re: Common Criteria Documentation...

In reply to this post by Kyle Hamilton

For a wiki, we can try wikia.com... the subject matter may be too
specialized for them, though.

We could fairly easily make the wiki self-hosting, using the wiki
software in the Monticello repositories (I think SqueakSource, but not
entirely sure).

What kind of outlay can the Squeak Foundation afford for wiki hosting,
if necessary?

-Kyle H

On 10/16/06, Krishna Sankar <[hidden email]> wrote:

> I am still figuring out things with the Google project. By tomorrow cob,
> will see how we all can get SVN write access. BTW, for the records, the
> Google project is squeak-cc-validation
> http://code.google.com/p/squeak-cc-validation/.
>
> On the CC side, I think the major tasks are :
>
> 1. Decide on the protection profile(s) we want to address
>
> 2. Define the claims and security target
>
> Most probably we would need 3-4 configurations
>
> 3. Start a function List and Test Matrix (Where can we host a
> Wiki?) (This will help us prove our case, so we should start this task ASAP)
>
> 4. Develop the ToE
>
> 5. Understand and document the cc process relevant to us. Read
> and mark the cc documents, talk with Labs et al
>
> 6. Formal cc effort
>
> Kyle, the cc documentation will help us in these tasks. I will add these
> tasks and will start double-clicking task #1.
>
> Cheers
> <k/>
>
> > -----Original Message-----
> > From: [hidden email]
> > [mailto:[hidden email]] On
> > Behalf Of Kyle Hamilton
> > Sent: Monday, October 16, 2006 8:33 PM
> > To: Cryptography Team Development List
> > Subject: [Cryptography Team] Common Criteria Documentation...
> >
> > I found the Google Code project that Krishna started, and
> > uploaded the Common Criteria documentation I found (in PDF
> > form) to it as an issue.
> > Unfortunately, I don't have SVN write access, and I don't
> > know how to get it either.
> >
> > After reading it, I realized that it /IS/ a good idea for
> > anyone starting on CC validation to read it before they
> > start. It's important to realize what it is, and what the
> > goals must be. (As well, it also helps customers -- that'd
> > include you, Ron -- understand what the various validation
> > levels are, and compare them to regulatory
> > requirement.)
> >
> > --
> >
> > -Kyle H
> > I speak only for myself. I don't have the faintest clue
> > about anyone else.
> > _______________________________________________
> > Cryptography mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> ptography
> >
>
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>

--

-Kyle H
_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Kyle Hamilton

Re: Common Criteria Documentation...

In reply to this post by Kyle Hamilton

I do have SVN write access now, thank you. I've placed the Common
Criteria documents (as well as the Evaluation Methodology document,
and a couple of supplementary materials) in the repository as the
test.

What is our source control plan? "Only project members, as agreed by
Krishna and Ron through some 'hiring-type' process, shall have write
access to the repository"?

Also, EAL 3 and 4 require a "controlled development environment". I'm
not entirely certain what this means (likely that there is a low
possibility for viruses or other attack vectors that could create
unauthorized changes to the source)... I wonder if we can meet this
requirement using VMware player and a customized VM image, perhaps
Ubuntu 6.06LTS with all development tools installed and only security
updates. (We need to examine the Evaluation Methodology document to
understand this requirement and requirements of implementation.)

For Windows, I have MSDN Windows 2000 that I can install in a VM. I
don't like XP nor Vista, and am well-familiar with 2000. I can also
install VC++ 2005 Express Edition, as necessary, and (if we choose to
use OpenSSL on the Windows platform) the toolchain required to build
the FIPS-validated version of that as well.

(I also have a validly licensed copy of VMware 4.5 within which I can
build customized VM images.)

Remember, documentation of the process and any modifications to the
environments is key.

-Kyle H

On 10/17/06, Krishna Sankar <[hidden email]> wrote:

> Kyle,
>
> Can you see if you have the SVN write access ?
> All,
> Just as FYI, we need gmail address to become part of the Google
> project and it has no Wiki. Any thoughts on the Wiki for us to document the
> functionalities and the results of development/testing ?
>
> Cheers
> <k/>
>
> > -----Original Message-----
> > From: [hidden email]
> > [mailto:[hidden email]] On
> > Behalf Of Kyle Hamilton
> > Sent: Monday, October 16, 2006 8:33 PM
> > To: Cryptography Team Development List
> > Subject: [Cryptography Team] Common Criteria Documentation...
> >
> > I found the Google Code project that Krishna started, and
> > uploaded the Common Criteria documentation I found (in PDF
> > form) to it as an issue.
> > Unfortunately, I don't have SVN write access, and I don't
> > know how to get it either.
> >
> > After reading it, I realized that it /IS/ a good idea for
> > anyone starting on CC validation to read it before they
> > start. It's important to realize what it is, and what the
> > goals must be. (As well, it also helps customers -- that'd
> > include you, Ron -- understand what the various validation
> > levels are, and compare them to regulatory
> > requirement.)
> >
> > --
> >
> > -Kyle H
> > I speak only for myself. I don't have the faintest clue
> > about anyone else.
> > _______________________________________________
> > Cryptography mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> > ptography
> >
>
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>

--

-Kyle H
_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Ron Teitelbaum

RE: Common Criteria Documentation...

In reply to this post by Kyle Hamilton

I thought the idea was to us SVN for those documents? If more is needed
let's just use the wiki that is part of www.squeaksource.com/Cryptography

It's not a full wiki in that it doesn't appear to support file uploads but
that what I thought the google source was for.

Can we map out what our requirements are and what our current resources are
for meeting those requirements, then we can look at what more we need.

What I see is:

www.squeaksoruce.com/Cryptography = Code Repository and limited wiki

http://code.google.com/p/squeak-cc-validation/ = Validation documentation,
plan and test results, bug tracking. This should not hold code.

[hidden email] is our mailing list.

Ron

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Krishna Sankar
> Sent: Tuesday, October 17, 2006 11:11 AM
> To: 'Cryptography Team Development List'
> Subject: RE: [Cryptography Team] Common Criteria Documentation...
>
> Kyle,
>
> Can you see if you have the SVN write access ?
> All,
> Just as FYI, we need gmail address to become part of the Google
> project and it has no Wiki. Any thoughts on the Wiki for us to document
> the
> functionalities and the results of development/testing ?
>
> Cheers
> <k/>
>
> > -----Original Message-----
> > From: [hidden email]
> > [mailto:[hidden email]] On
> > Behalf Of Kyle Hamilton
> > Sent: Monday, October 16, 2006 8:33 PM
> > To: Cryptography Team Development List
> > Subject: [Cryptography Team] Common Criteria Documentation...
> >
> > I found the Google Code project that Krishna started, and
> > uploaded the Common Criteria documentation I found (in PDF
> > form) to it as an issue.
> > Unfortunately, I don't have SVN write access, and I don't
> > know how to get it either.
> >
> > After reading it, I realized that it /IS/ a good idea for
> > anyone starting on CC validation to read it before they
> > start. It's important to realize what it is, and what the
> > goals must be. (As well, it also helps customers -- that'd
> > include you, Ron -- understand what the various validation
> > levels are, and compare them to regulatory
> > requirement.)
> >
> > --
> >
> > -Kyle H
> > I speak only for myself. I don't have the faintest clue
> > about anyone else.
> > _______________________________________________
> > Cryptography mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> > ptography
> >
>
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Krishna Sankar-2

RE: Common Criteria Documentation...

> http://code.google.com/p/squeak-cc-validation/ = Validation
> documentation, plan and test results, bug tracking. This
> should not hold code.
<KS>

I would prefer to hold the validation documentation, plan and test
results in a Wiki. That way we have built-in revision control as well as
history tracking. In that sense the Google projects do not help us.

The bug tracking in Google projects is fine.

</KS>

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On
> Behalf Of Ron Teitelbaum
> Sent: Tuesday, October 17, 2006 9:34 AM
> To: 'Cryptography Team Development List'
> Subject: RE: [Cryptography Team] Common Criteria Documentation...
>
> I thought the idea was to us SVN for those documents? If
> more is needed let's just use the wiki that is part of
> www.squeaksource.com/Cryptography
>
> It's not a full wiki in that it doesn't appear to support
> file uploads but that what I thought the google source was for.
>
> Can we map out what our requirements are and what our current
> resources are for meeting those requirements, then we can
> look at what more we need.
>
> What I see is:
>
> www.squeaksoruce.com/Cryptography = Code Repository and limited wiki
>
> http://code.google.com/p/squeak-cc-validation/ = Validation
> documentation, plan and test results, bug tracking. This
> should not hold code.
>
> [hidden email] is our mailing list.
>
> Ron
>
> > -----Original Message-----
> > From: [hidden email]
> > [mailto:[hidden email]] On
> Behalf Of
> > Krishna Sankar
> > Sent: Tuesday, October 17, 2006 11:11 AM
> > To: 'Cryptography Team Development List'
> > Subject: RE: [Cryptography Team] Common Criteria Documentation...
> >
> > Kyle,
> >
> > Can you see if you have the SVN write access ?
> > All,
> > Just as FYI, we need gmail address to become part of the Google
> > project and it has no Wiki. Any thoughts on the Wiki for us to
> > document the functionalities and the results of
> development/testing ?
> >
> > Cheers
> > <k/>
> >
> > > -----Original Message-----
> > > From: [hidden email]
> > > [mailto:[hidden email]]
> On Behalf
> > > Of Kyle Hamilton
> > > Sent: Monday, October 16, 2006 8:33 PM
> > > To: Cryptography Team Development List
> > > Subject: [Cryptography Team] Common Criteria Documentation...
> > >
> > > I found the Google Code project that Krishna started, and
> uploaded
> > > the Common Criteria documentation I found (in PDF
> > > form) to it as an issue.
> > > Unfortunately, I don't have SVN write access, and I
> don't know how
> > > to get it either.
> > >
> > > After reading it, I realized that it /IS/ a good idea for anyone
> > > starting on CC validation to read it before they start. It's
> > > important to realize what it is, and what the goals must be. (As
> > > well, it also helps customers -- that'd include you, Ron --
> > > understand what the various validation levels are, and
> compare them
> > > to regulatory
> > > requirement.)
> > >
> > > --
> > >
> > > -Kyle H
> > > I speak only for myself. I don't have the faintest clue about
> > > anyone else.
> > > _______________________________________________
> > > Cryptography mailing list
> > > [hidden email]
> > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> > > ptography
> > >
> >
> > _______________________________________________
> > Cryptography mailing list
> > [hidden email]
> >
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptograph
> > y
>
>
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry

ptography
>

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Ron Teitelbaum

RE: Common Criteria Documentation...

In reply to this post by Kyle Hamilton

Are there other benefits besides bug tracking for having the google project?

Ron

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Krishna Sankar
> Sent: Tuesday, October 17, 2006 12:46 PM
> To: [hidden email]; 'Cryptography Team Development List'
> Subject: RE: [Cryptography Team] Common Criteria Documentation...
>
> > http://code.google.com/p/squeak-cc-validation/ = Validation
> > documentation, plan and test results, bug tracking. This
> > should not hold code.
> <KS>
>
> I would prefer to hold the validation documentation, plan and test
> results in a Wiki. That way we have built-in revision control as well as
> history tracking. In that sense the Google projects do not help us.
>
> The bug tracking in Google projects is fine.
>
> </KS>
>
> > -----Original Message-----
> > From: [hidden email]
> > [mailto:[hidden email]] On
> > Behalf Of Ron Teitelbaum
> > Sent: Tuesday, October 17, 2006 9:34 AM
> > To: 'Cryptography Team Development List'
> > Subject: RE: [Cryptography Team] Common Criteria Documentation...
> >
> > I thought the idea was to us SVN for those documents? If
> > more is needed let's just use the wiki that is part of
> > www.squeaksource.com/Cryptography
> >
> > It's not a full wiki in that it doesn't appear to support
> > file uploads but that what I thought the google source was for.
> >
> > Can we map out what our requirements are and what our current
> > resources are for meeting those requirements, then we can
> > look at what more we need.
> >
> > What I see is:
> >
> > www.squeaksoruce.com/Cryptography = Code Repository and limited wiki
> >
> > http://code.google.com/p/squeak-cc-validation/ = Validation
> > documentation, plan and test results, bug tracking. This
> > should not hold code.
> >
> > [hidden email] is our mailing list.
> >
> > Ron
> >
> > > -----Original Message-----
> > > From: [hidden email]
> > > [mailto:[hidden email]] On
> > Behalf Of
> > > Krishna Sankar
> > > Sent: Tuesday, October 17, 2006 11:11 AM
> > > To: 'Cryptography Team Development List'
> > > Subject: RE: [Cryptography Team] Common Criteria Documentation...
> > >
> > > Kyle,
> > >
> > > Can you see if you have the SVN write access ?
> > > All,
> > > Just as FYI, we need gmail address to become part of the Google
> > > project and it has no Wiki. Any thoughts on the Wiki for us to
> > > document the functionalities and the results of
> > development/testing ?
> > >
> > > Cheers
> > > <k/>
> > >
> > > > -----Original Message-----
> > > > From: [hidden email]
> > > > [mailto:[hidden email]]
> > On Behalf
> > > > Of Kyle Hamilton
> > > > Sent: Monday, October 16, 2006 8:33 PM
> > > > To: Cryptography Team Development List
> > > > Subject: [Cryptography Team] Common Criteria Documentation...
> > > >
> > > > I found the Google Code project that Krishna started, and
> > uploaded
> > > > the Common Criteria documentation I found (in PDF
> > > > form) to it as an issue.
> > > > Unfortunately, I don't have SVN write access, and I
> > don't know how
> > > > to get it either.
> > > >
> > > > After reading it, I realized that it /IS/ a good idea for anyone
> > > > starting on CC validation to read it before they start. It's
> > > > important to realize what it is, and what the goals must be. (As
> > > > well, it also helps customers -- that'd include you, Ron --
> > > > understand what the various validation levels are, and
> > compare them
> > > > to regulatory
> > > > requirement.)
> > > >
> > > > --
> > > >
> > > > -Kyle H
> > > > I speak only for myself. I don't have the faintest clue about
> > > > anyone else.
> > > > _______________________________________________
> > > > Cryptography mailing list
> > > > [hidden email]
> > > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> > > > ptography
> > > >
> > >
> > > _______________________________________________
> > > Cryptography mailing list
> > > [hidden email]
> > >
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptograph
> > > y
> >
> >
> > _______________________________________________
> > Cryptography mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> ptography
> >
>
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Ron Teitelbaum

RE: Common Criteria Documentation...

In reply to this post by Kyle Hamilton

Kyle,

I like the idea of letting Krishna flush out the details of step one. Keep
in mind our goal is to be very through and thoughtful about each step which
may require a slower pace. Also a major goal is to provide a road map which
others (including us) can learn from.

I understand the need for a controlled environment, which we spoke about
earlier, but I'm not sure that is the right place to start. I am also ok
with letting Krishna define access requirements to repositories based on his
interpretation of what is needed to move forward.

Ron

> From: Kyle Hamilton
> Sent: Tuesday, October 17, 2006 12:14 PM
>
> I do have SVN write access now, thank you. I've placed the Common
> Criteria documents (as well as the Evaluation Methodology document,
> and a couple of supplementary materials) in the repository as the
> test.
>
> What is our source control plan? "Only project members, as agreed by
> Krishna and Ron through some 'hiring-type' process, shall have write
> access to the repository"?
>
> Also, EAL 3 and 4 require a "controlled development environment". I'm
> not entirely certain what this means (likely that there is a low
> possibility for viruses or other attack vectors that could create
> unauthorized changes to the source)... I wonder if we can meet this
> requirement using VMware player and a customized VM image, perhaps
> Ubuntu 6.06LTS with all development tools installed and only security
> updates. (We need to examine the Evaluation Methodology document to
> understand this requirement and requirements of implementation.)
>
> For Windows, I have MSDN Windows 2000 that I can install in a VM. I
> don't like XP nor Vista, and am well-familiar with 2000. I can also
> install VC++ 2005 Express Edition, as necessary, and (if we choose to
> use OpenSSL on the Windows platform) the toolchain required to build
> the FIPS-validated version of that as well.
>
> (I also have a validly licensed copy of VMware 4.5 within which I can
> build customized VM images.)
>
> Remember, documentation of the process and any modifications to the
> environments is key.
>
> -Kyle H
>
>
>
> On 10/17/06, Krishna Sankar <[hidden email]> wrote:
> > Kyle,
> >
> > Can you see if you have the SVN write access ?
> > All,
> > Just as FYI, we need gmail address to become part of the Google
> > project and it has no Wiki. Any thoughts on the Wiki for us to document
> the
> > functionalities and the results of development/testing ?
> >
> > Cheers
> > <k/>
> >
> > > -----Original Message-----
> > > From: [hidden email]
> > > [mailto:[hidden email]] On
> > > Behalf Of Kyle Hamilton
> > > Sent: Monday, October 16, 2006 8:33 PM
> > > To: Cryptography Team Development List
> > > Subject: [Cryptography Team] Common Criteria Documentation...
> > >
> > > I found the Google Code project that Krishna started, and
> > > uploaded the Common Criteria documentation I found (in PDF
> > > form) to it as an issue.
> > > Unfortunately, I don't have SVN write access, and I don't
> > > know how to get it either.
> > >
> > > After reading it, I realized that it /IS/ a good idea for
> > > anyone starting on CC validation to read it before they
> > > start. It's important to realize what it is, and what the
> > > goals must be. (As well, it also helps customers -- that'd
> > > include you, Ron -- understand what the various validation
> > > levels are, and compare them to regulatory
> > > requirement.)
> > >
> > > --
> > >
> > > -Kyle H
> > > I speak only for myself. I don't have the faintest clue
> > > about anyone else.
> > > _______________________________________________
> > > Cryptography mailing list
> > > [hidden email]
> > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> > > ptography
> > >
> >
> > _______________________________________________
> > Cryptography mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
> >
>
>
> --
>
> -Kyle H
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Krishna Sankar-2

RE: Common Criteria Documentation...

In reply to this post by Kyle Hamilton

Have started to put the task list and notes in our cryptography Wiki page at
http://minnow.cc.gatech.edu/squeak/5776.

For now, the cc information is at the end of the cryptography page. As we
add more details and get a fix on the organization, we can start a set of
new pages.

Kyle, can you pl add your notes and observations ? Thanks.

Cheers
<k/>

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On
> Behalf Of Krishna Sankar
> Sent: Tuesday, October 17, 2006 9:46 AM
> To: [hidden email]; 'Cryptography Team Development List'
> Subject: RE: [Cryptography Team] Common Criteria Documentation...
>
> > http://code.google.com/p/squeak-cc-validation/ = Validation
> > documentation, plan and test results, bug tracking. This
> should not
> > hold code.
> <KS>
>
> I would prefer to hold the validation documentation,
> plan and test results in a Wiki. That way we have built-in
> revision control as well as history tracking. In that sense
> the Google projects do not help us.
>
> The bug tracking in Google projects is fine.
>
> </KS>
>
> > -----Original Message-----
> > From: [hidden email]
> > [mailto:[hidden email]] On
> Behalf Of
> > Ron Teitelbaum
> > Sent: Tuesday, October 17, 2006 9:34 AM
> > To: 'Cryptography Team Development List'
> > Subject: RE: [Cryptography Team] Common Criteria Documentation...
> >
> > I thought the idea was to us SVN for those documents? If more is
> > needed let's just use the wiki that is part of
> > www.squeaksource.com/Cryptography
> >
> > It's not a full wiki in that it doesn't appear to support
> file uploads
> > but that what I thought the google source was for.
> >
> > Can we map out what our requirements are and what our current
> > resources are for meeting those requirements, then we can
> look at what
> > more we need.
> >
> > What I see is:
> >
> > www.squeaksoruce.com/Cryptography = Code Repository and limited wiki
> >
> > http://code.google.com/p/squeak-cc-validation/ = Validation
> > documentation, plan and test results, bug tracking. This
> should not
> > hold code.
> >
> > [hidden email] is our mailing list.
> >
> > Ron
> >
> > > -----Original Message-----
> > > From: [hidden email]
> > > [mailto:[hidden email]] On
> > Behalf Of
> > > Krishna Sankar
> > > Sent: Tuesday, October 17, 2006 11:11 AM
> > > To: 'Cryptography Team Development List'
> > > Subject: RE: [Cryptography Team] Common Criteria Documentation...
> > >
> > > Kyle,
> > >
> > > Can you see if you have the SVN write access ?
> > > All,
> > > Just as FYI, we need gmail address to become part of the Google
> > > project and it has no Wiki. Any thoughts on the Wiki for us to
> > > document the functionalities and the results of
> > development/testing ?
> > >
> > > Cheers
> > > <k/>
> > >
> > > > -----Original Message-----
> > > > From: [hidden email]
> > > > [mailto:[hidden email]]
> > On Behalf
> > > > Of Kyle Hamilton
> > > > Sent: Monday, October 16, 2006 8:33 PM
> > > > To: Cryptography Team Development List
> > > > Subject: [Cryptography Team] Common Criteria Documentation...
> > > >
> > > > I found the Google Code project that Krishna started, and
> > uploaded
> > > > the Common Criteria documentation I found (in PDF
> > > > form) to it as an issue.
> > > > Unfortunately, I don't have SVN write access, and I
> > don't know how
> > > > to get it either.
> > > >
> > > > After reading it, I realized that it /IS/ a good idea
> for anyone
> > > > starting on CC validation to read it before they start. It's
> > > > important to realize what it is, and what the goals
> must be. (As
> > > > well, it also helps customers -- that'd include you, Ron --
> > > > understand what the various validation levels are, and
> > compare them
> > > > to regulatory
> > > > requirement.)
> > > >
> > > > --
> > > >
> > > > -Kyle H
> > > > I speak only for myself. I don't have the faintest clue about
> > > > anyone else.
> > > > _______________________________________________
> > > > Cryptography mailing list
> > > > [hidden email]
> > > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> > > > ptography
> > > >
> > >
> > > _______________________________________________
> > > Cryptography mailing list
> > > [hidden email]
> > >
> >
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptograph
> > > y
> >
> >
> > _______________________________________________
> > Cryptography mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> ptography
> >
>
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry

ptography
>

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Kyle Hamilton

Re: Common Criteria Documentation...

In reply to this post by Kyle Hamilton

You know, I'd love to, but I keep getting authentication requests and
have no username or password... so, 401 Unauthorized.

Unauthorized for: /squeak/*

Who am I supposed to contact for editing permission?

-Kyle H

On 10/17/06, Krishna Sankar <[hidden email]> wrote:
>
> Kyle, can you pl add your notes and observations ? Thanks.
>
> Cheers
> <k/>
_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Ron Teitelbaum

RE: Common Criteria Documentation...

Hi Kyle,

The user name is: squeak pw: viewpoints

It's a public wiki but it has a name and password because of automated
spammers.

Ron

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Kyle
> Hamilton
> Sent: Tuesday, October 17, 2006 6:18 PM
> To: Cryptography Team Development List
> Subject: Re: [Cryptography Team] Common Criteria Documentation...
>
> You know, I'd love to, but I keep getting authentication requests and
> have no username or password... so, 401 Unauthorized.
>
> Unauthorized for: /squeak/*
>
> Who am I supposed to contact for editing permission?
>
> -Kyle H
>
> On 10/17/06, Krishna Sankar <[hidden email]> wrote:
> >
> > Kyle, can you pl add your notes and observations ? Thanks.
> >
> > Cheers
> > <k/>
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Kyle Hamilton

Re: Common Criteria Documentation...

In reply to this post by Kyle Hamilton

I've updated it with my comments.

Since the system is written in itself (and runs inside itself), there
are several things in the PP that require redesigning very large parts
of the system. We need at least one VM hacker on this list to
evaluate the feasability of some of the needed changes.

Note: The current wiki system is probably not going to be sufficient
for long-term usage. Part of the EAL that we need to meet includes
positive authorized user identification for all changes to the
configuration... and since documentation (and an audit trail and
history) will be a major part of proving our case to the assurance
labs, I'm thinking that we should treat it as part of the
configuration. We'll need individual usernames and passwords for the
modifications until we get X.509/PKI up and running, then we'll
possibly be able to use PK crypto certificates for authentication.

I'll leave it up to Krishna to determine the actual policy and
implementation, since he's got formal validation experience. I just
know what I've read in the CC PDFs and the single-layer OS/moderate
environment document, and I'm interpreting it in the most secure (and
most trust-pessimistic) manner that I can.

Here's hoping that we get at least one validation out of this in the end. :)

-Kyle H

On 10/17/06, Krishna Sankar <[hidden email]> wrote:

> Have started to put the task list and notes in our cryptography Wiki page at
> http://minnow.cc.gatech.edu/squeak/5776.
>
> For now, the cc information is at the end of the cryptography page. As we
> add more details and get a fix on the organization, we can start a set of
> new pages.
>
> Kyle, can you pl add your notes and observations ? Thanks.
>
> Cheers
> <k/>
>
> > -----Original Message-----
> > From: [hidden email]
> > [mailto:[hidden email]] On
> > Behalf Of Krishna Sankar
> > Sent: Tuesday, October 17, 2006 9:46 AM
> > To: [hidden email]; 'Cryptography Team Development List'
> > Subject: RE: [Cryptography Team] Common Criteria Documentation...
> >
> > > http://code.google.com/p/squeak-cc-validation/ = Validation
> > > documentation, plan and test results, bug tracking. This
> > should not
> > > hold code.
> > <KS>
> >
> > I would prefer to hold the validation documentation,
> > plan and test results in a Wiki. That way we have built-in
> > revision control as well as history tracking. In that sense
> > the Google projects do not help us.
> >
> > The bug tracking in Google projects is fine.
> >
> > </KS>
> >
> > > -----Original Message-----
> > > From: [hidden email]
> > > [mailto:[hidden email]] On
> > Behalf Of
> > > Ron Teitelbaum
> > > Sent: Tuesday, October 17, 2006 9:34 AM
> > > To: 'Cryptography Team Development List'
> > > Subject: RE: [Cryptography Team] Common Criteria Documentation...
> > >
> > > I thought the idea was to us SVN for those documents? If more is
> > > needed let's just use the wiki that is part of
> > > www.squeaksource.com/Cryptography
> > >
> > > It's not a full wiki in that it doesn't appear to support
> > file uploads
> > > but that what I thought the google source was for.
> > >
> > > Can we map out what our requirements are and what our current
> > > resources are for meeting those requirements, then we can
> > look at what
> > > more we need.
> > >
> > > What I see is:
> > >
> > > www.squeaksoruce.com/Cryptography = Code Repository and limited wiki
> > >
> > > http://code.google.com/p/squeak-cc-validation/ = Validation
> > > documentation, plan and test results, bug tracking. This
> > should not
> > > hold code.
> > >
> > > [hidden email] is our mailing list.
> > >
> > > Ron
> > >
> > > > -----Original Message-----
> > > > From: [hidden email]
> > > > [mailto:[hidden email]] On
> > > Behalf Of
> > > > Krishna Sankar
> > > > Sent: Tuesday, October 17, 2006 11:11 AM
> > > > To: 'Cryptography Team Development List'
> > > > Subject: RE: [Cryptography Team] Common Criteria Documentation...
> > > >
> > > > Kyle,
> > > >
> > > > Can you see if you have the SVN write access ?
> > > > All,
> > > > Just as FYI, we need gmail address to become part of the Google
> > > > project and it has no Wiki. Any thoughts on the Wiki for us to
> > > > document the functionalities and the results of
> > > development/testing ?
> > > >
> > > > Cheers
> > > > <k/>
> > > >
> > > > > -----Original Message-----
> > > > > From: [hidden email]
> > > > > [mailto:[hidden email]]
> > > On Behalf
> > > > > Of Kyle Hamilton
> > > > > Sent: Monday, October 16, 2006 8:33 PM
> > > > > To: Cryptography Team Development List
> > > > > Subject: [Cryptography Team] Common Criteria Documentation...
> > > > >
> > > > > I found the Google Code project that Krishna started, and
> > > uploaded
> > > > > the Common Criteria documentation I found (in PDF
> > > > > form) to it as an issue.
> > > > > Unfortunately, I don't have SVN write access, and I
> > > don't know how
> > > > > to get it either.
> > > > >
> > > > > After reading it, I realized that it /IS/ a good idea
> > for anyone
> > > > > starting on CC validation to read it before they start. It's
> > > > > important to realize what it is, and what the goals
> > must be. (As
> > > > > well, it also helps customers -- that'd include you, Ron --
> > > > > understand what the various validation levels are, and
> > > compare them
> > > > > to regulatory
> > > > > requirement.)
> > > > >
> > > > > --
> > > > >
> > > > > -Kyle H
> > > > > I speak only for myself. I don't have the faintest clue about
> > > > > anyone else.
> > > > > _______________________________________________
> > > > > Cryptography mailing list
> > > > > [hidden email]
> > > > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> > > > > ptography
> > > > >
> > > >
> > > > _______________________________________________
> > > > Cryptography mailing list
> > > > [hidden email]
> > > >
> > >
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptograph
> > > > y
> > >
> > >
> > > _______________________________________________
> > > Cryptography mailing list
> > > [hidden email]
> > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> > ptography
> > >
> >
> > _______________________________________________
> > Cryptography mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> ptography
> >
>
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>

--

-Kyle H
_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

ccrraaiigg

re: Common Criteria Documentation...

Hi Kyle--

> Since the system is written in itself (and runs inside itself), there
> are several things in the PP that require redesigning very large parts
> of the system. We need at least one VM hacker on this list to
> evaluate the feasability of some of the needed changes.

I can do that.

thanks!

-C

--
Craig Latta
http://netjam.org/resume

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Ron Teitelbaum

RE: re: Common Criteria Documentation...

Very cool thanks Craig!

Ron

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Craig Latta
> Sent: Tuesday, October 17, 2006 8:33 PM
> To: Cryptography Team Development List
> Subject: [Cryptography Team] re: Common Criteria Documentation...
>
>
> Hi Kyle--
>
> > Since the system is written in itself (and runs inside itself), there
> > are several things in the PP that require redesigning very large parts
> > of the system. We need at least one VM hacker on this list to
> > evaluate the feasability of some of the needed changes.
>
> I can do that.
>
>
> thanks!
>
> -C
>
> --
> Craig Latta
> http://netjam.org/resume
>
>
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Kyle Hamilton

Re: re: Common Criteria Documentation...

In reply to this post by ccrraaiigg

Thank you, Craig.

If you look at the bottom of the Cryptography page on the
minnow/squeak wiki, you'll see what I mean by "serious redesign".
I'll go through the EAL documentation and the PP, and see what else
isn't currently implemented but needs to be. (I hope that someone
else can and will, too, since this is going to require something close
to actuarial skills. I'm good with details, but I sometimes get so
tangled in them that I forget something important.)

But, that brings this up: this list is about cryptography, but our
direction is (eventually, as stated by Krishna) CC EAL 4+ validation.
This requires FIPS-validated cryptographic software, but there's a lot
more to it than that. Are we going to split efforts between
cryptography/FIPS and the remainder of the CC validation, and maybe do
it more quickly? Are we going to focus on FIPS first, and only after
we get something that we can submit for validation then worry about
the remainder for CC?

-Kyle H

On 10/17/06, Craig Latta <[hidden email]> wrote:

>
> Hi Kyle--
>
> > Since the system is written in itself (and runs inside itself), there
> > are several things in the PP that require redesigning very large parts
> > of the system. We need at least one VM hacker on this list to
> > evaluate the feasability of some of the needed changes.
>
> I can do that.
>
>
> thanks!
>
> -C
>
> --
> Craig Latta
> http://netjam.org/resume
>
>
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>

--

-Kyle H
_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Ron Teitelbaum

RE: Common Criteria Documentation...

In reply to this post by Kyle Hamilton

Kyle,

Just to be clear, incase I'm missing something. My understanding is that
there is a large amount of work that needs to be done to show that we meet
the criteria. My interest right now is the tasks that need to be performed
prior to an actual validation. If we decide on a platform and then run
through the validation tasks we can identify the holes in our system that
still need developing. We don't need an actual secure platform to do the
validation until we are sure that we can pass the validation. At that point
we can start working on setting up an actual implementation for a lab to
scrutinize.

In my opinion we should be considering this pre-validation research, which
means we can loosen the actual requirements as long as we believe that we
can meet those requirements when the time comes to move to the next phase.

Does that make sense or am I missing something?

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Kyle
> Hamilton
> Sent: Tuesday, October 17, 2006 8:08 PM
> To: Cryptography Team Development List
> Subject: Re: [Cryptography Team] Common Criteria Documentation...
>
> I've updated it with my comments.
>
> Since the system is written in itself (and runs inside itself), there
> are several things in the PP that require redesigning very large parts
> of the system. We need at least one VM hacker on this list to
> evaluate the feasability of some of the needed changes.
>
> Note: The current wiki system is probably not going to be sufficient
> for long-term usage. Part of the EAL that we need to meet includes
> positive authorized user identification for all changes to the
> configuration... and since documentation (and an audit trail and
> history) will be a major part of proving our case to the assurance
> labs, I'm thinking that we should treat it as part of the
> configuration. We'll need individual usernames and passwords for the
> modifications until we get X.509/PKI up and running, then we'll
> possibly be able to use PK crypto certificates for authentication.
>
> I'll leave it up to Krishna to determine the actual policy and
> implementation, since he's got formal validation experience. I just
> know what I've read in the CC PDFs and the single-layer OS/moderate
> environment document, and I'm interpreting it in the most secure (and
> most trust-pessimistic) manner that I can.
>
> Here's hoping that we get at least one validation out of this in the end.
> :)
>
> -Kyle H
>
> On 10/17/06, Krishna Sankar <[hidden email]> wrote:
> > Have started to put the task list and notes in our cryptography Wiki
> page at
> > http://minnow.cc.gatech.edu/squeak/5776.
> >
> > For now, the cc information is at the end of the cryptography page. As
> we
> > add more details and get a fix on the organization, we can start a set
> of
> > new pages.
> >
> > Kyle, can you pl add your notes and observations ? Thanks.
> >
> > Cheers
> > <k/>
> >
> > > -----Original Message-----
> > > From: [hidden email]
> > > [mailto:[hidden email]] On
> > > Behalf Of Krishna Sankar
> > > Sent: Tuesday, October 17, 2006 9:46 AM
> > > To: [hidden email]; 'Cryptography Team Development List'
> > > Subject: RE: [Cryptography Team] Common Criteria Documentation...
> > >
> > > > http://code.google.com/p/squeak-cc-validation/ = Validation
> > > > documentation, plan and test results, bug tracking. This
> > > should not
> > > > hold code.
> > > <KS>
> > >
> > > I would prefer to hold the validation documentation,
> > > plan and test results in a Wiki. That way we have built-in
> > > revision control as well as history tracking. In that sense
> > > the Google projects do not help us.
> > >
> > > The bug tracking in Google projects is fine.
> > >
> > > </KS>
> > >
> > > > -----Original Message-----
> > > > From: [hidden email]
> > > > [mailto:[hidden email]] On
> > > Behalf Of
> > > > Ron Teitelbaum
> > > > Sent: Tuesday, October 17, 2006 9:34 AM
> > > > To: 'Cryptography Team Development List'
> > > > Subject: RE: [Cryptography Team] Common Criteria Documentation...
> > > >
> > > > I thought the idea was to us SVN for those documents? If more is
> > > > needed let's just use the wiki that is part of
> > > > www.squeaksource.com/Cryptography
> > > >
> > > > It's not a full wiki in that it doesn't appear to support
> > > file uploads
> > > > but that what I thought the google source was for.
> > > >
> > > > Can we map out what our requirements are and what our current
> > > > resources are for meeting those requirements, then we can
> > > look at what
> > > > more we need.
> > > >
> > > > What I see is:
> > > >
> > > > www.squeaksoruce.com/Cryptography = Code Repository and limited wiki
> > > >
> > > > http://code.google.com/p/squeak-cc-validation/ = Validation
> > > > documentation, plan and test results, bug tracking. This
> > > should not
> > > > hold code.
> > > >
> > > > [hidden email] is our mailing list.
> > > >
> > > > Ron
> > > >
> > > > > -----Original Message-----
> > > > > From: [hidden email]
> > > > > [mailto:[hidden email]] On
> > > > Behalf Of
> > > > > Krishna Sankar
> > > > > Sent: Tuesday, October 17, 2006 11:11 AM
> > > > > To: 'Cryptography Team Development List'
> > > > > Subject: RE: [Cryptography Team] Common Criteria Documentation...
> > > > >
> > > > > Kyle,
> > > > >
> > > > > Can you see if you have the SVN write access ?
> > > > > All,
> > > > > Just as FYI, we need gmail address to become part of the Google
> > > > > project and it has no Wiki. Any thoughts on the Wiki for us to
> > > > > document the functionalities and the results of
> > > > development/testing ?
> > > > >
> > > > > Cheers
> > > > > <k/>
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [hidden email]
> > > > > > [mailto:[hidden email]]
> > > > On Behalf
> > > > > > Of Kyle Hamilton
> > > > > > Sent: Monday, October 16, 2006 8:33 PM
> > > > > > To: Cryptography Team Development List
> > > > > > Subject: [Cryptography Team] Common Criteria Documentation...
> > > > > >
> > > > > > I found the Google Code project that Krishna started, and
> > > > uploaded
> > > > > > the Common Criteria documentation I found (in PDF
> > > > > > form) to it as an issue.
> > > > > > Unfortunately, I don't have SVN write access, and I
> > > > don't know how
> > > > > > to get it either.
> > > > > >
> > > > > > After reading it, I realized that it /IS/ a good idea
> > > for anyone
> > > > > > starting on CC validation to read it before they start. It's
> > > > > > important to realize what it is, and what the goals
> > > must be. (As
> > > > > > well, it also helps customers -- that'd include you, Ron --
> > > > > > understand what the various validation levels are, and
> > > > compare them
> > > > > > to regulatory
> > > > > > requirement.)
> > > > > >
> > > > > > --
> > > > > >
> > > > > > -Kyle H
> > > > > > I speak only for myself. I don't have the faintest clue about
> > > > > > anyone else.
> > > > > > _______________________________________________
> > > > > > Cryptography mailing list
> > > > > > [hidden email]
> > > > > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> > > > > > ptography
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Cryptography mailing list
> > > > > [hidden email]
> > > > >
> > > >
> > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptograph
> > > > > y
> > > >
> > > >
> > > > _______________________________________________
> > > > Cryptography mailing list
> > > > [hidden email]
> > > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> > > ptography
> > > >
> > >
> > > _______________________________________________
> > > Cryptography mailing list
> > > [hidden email]
> > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> > ptography
> > >
> >
> > _______________________________________________
> > Cryptography mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
> >
>
>
> --
>
> -Kyle H
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Kyle Hamilton

Re: Common Criteria Documentation...

Ron,

'large number of tasks' is an understatement. :) The question is
this: which validation are you looking for, first? Two (well, three,
really, but only two classes of) validations have been mentioned, and
my question relates to which of them resources will be allocated to --
which, in turn, defines what should go on the task list and with what
priority.

FIPS 140-2 is the Trusted Cryptographic Module, which in and of itself
is a huge undertaking -- a high-level overview of the things required
for it are "make sure that the binary representation of the code
cannot be altered", "make sure that calls into the binary
representation of the code cannot be diverted", "make sure that, once
in FIPS mode, only FIPS-approved algorithms can be used", "ensure that
the random number generator has a good enough source of entropy AND is
then stirred by a FIPS-approved pseudo-random function", and various
and sundry other things. This is the validation that OpenSSL
received, this is the validation that Windows CryptoAPI received, this
is the validation that those two specific binary versions of Crypto++
received, this is the mandatory validation for cryptographic software
that is to be used by the US government. (VM changes will be required
for a validatable pure-Squeak FIPS implementation.)

Common Criteria assurance validation is mandatory for entire systems
that are to be used by the US government, and for information
processing systems used by financial institutions. It also provides
(to my understanding) assurance that is good enough for HIPAA's
requirements. One of its requirements is that it use FIPS-validated
cryptographic software, but it doesn't stop there -- this validation
applies to entire systems and not merely the cryptographic component.
In any case, the project eventually will need a FIPS-validated
cryptographic component in its architecture, be it through using a
platform-native library, a smart-card interface, or a pure-Squeak
component. (VM changes will also be needed for this validation.)

You can loosen the requirements now, as long as an eye is kept on the
long view. If the system is mis-architected, it will require
substantial rebuilding of the VM to bring it into validatable
conformance with either the Common Criteria or FIPS. This is the
reason why I felt that we should bring in a VM hacker now -- as it
stands there is no way that, even plugging in an external FIPS
library, the system could meet anything but the most basic assurance.
This is going to be a long-term, many-component project, and I don't
envy Krishna the management of it nor you the executive role. The
least that I and anyone else can do is help you manage it. This
includes making sure that every team knows at the outset what the
eventual parameters will be, so no one codes themselves into a corner.

A problem exists with loosening the documentation requirements for too
long -- which is that if it is left for too long, the criteria simply
cannot be met. Krishna suggested a Protection Profile as a target
("Single-Level Operating Systems in Medium Robustness Environments
PP") which requires that the system must meet EAL 4 with some
augmentations. In order to do that, there are some requirements,
including partially-automated configuration management (I'm thinking
that Monticello may be good enough for this, though I have not looked
at it or the CC in sufficient detail to be able to state
definitively), that require that only authorized changes can be made
to any configuration item.

I quote paragraph 217 from the Common Criteria v2.3 Part 3 document:

217 EAL4 also provides assurance through the use of development
environment controls and additional TOE configuration management
including automation, and evidence of secure delivery procedures.

All of the relevant information is contained in the CC v2.3
documentation (the administrative requirements are contained in part
3). Suffice it to say, though, that one of the requirements is that
no developer should be able to insert unauthorized or malicious code
or information undetected -- and since the profile includes that
Administrator and User documentation will be created and delivered,
those documents must be kept under Configuration Management as well.

If a wiki is used to write and edit those documents, that wiki must be
able to ensure that only authorized people can modify them. It must
also be able to backtrack the various changes to find when any given
piece was added, removed, or altered, and who did the alteration of
the documentation at that time.

I apologize for the length of this, but I do want to ensure that
everyone is on the same page and understands the rationale behind some
of my statements. You and/or Krishna are going to make decisions as
to the exact procedures that the team and project are going to use --
however, I'm an agoraphobic bachelor, and I thus have more time to
research the requirements much more in-depth than you two can. This
suggests that I should do so, and make recommendations based on what I
have found.

I liken this to the role of a research librarian -- sift through
mountains of data, to provide a concise report. As I said, I defer to
you and Krishna -- but if you want to know the rationale behind
something I suggest, I will quote you book, chapter and paragraph of
everything relevant that I have found so that you can make up your own
minds without having to sift through the mountains yourselves.

So, to sum it all up: One of the tasks that needs to be completed is
to set up an authenticated configuration management system before the
user and administrator documentation is written. As I said, the
current wiki system will not be sufficient for the long term, but
there's a huge mountain of other tasks as well. Since no
administrator or user documentation is being created at this point,
the wiki does not need to move to a positive identification system
yet. Not in the short term, and probably not in the medium term.
This doesn't mean that the eventual need shouldn't be planned for.

(Arguably, design documents and implementation plans should also be
entered into CM. Again, though, this is a long-term project, and
rough ideas probably don't.)

-Kyle H

On 10/17/06, Ron Teitelbaum <[hidden email]> wrote:

> Kyle,
>
> Just to be clear, incase I'm missing something. My understanding is that
> there is a large amount of work that needs to be done to show that we meet
> the criteria. My interest right now is the tasks that need to be performed
> prior to an actual validation. If we decide on a platform and then run
> through the validation tasks we can identify the holes in our system that
> still need developing. We don't need an actual secure platform to do the
> validation until we are sure that we can pass the validation. At that point
> we can start working on setting up an actual implementation for a lab to
> scrutinize.
>
> In my opinion we should be considering this pre-validation research, which
> means we can loosen the actual requirements as long as we believe that we
> can meet those requirements when the time comes to move to the next phase.
>
> Does that make sense or am I missing something?
>
> > -----Original Message-----
> > From: [hidden email]
> > [mailto:[hidden email]] On Behalf Of Kyle
> > Hamilton
> > Sent: Tuesday, October 17, 2006 8:08 PM
> > To: Cryptography Team Development List
> > Subject: Re: [Cryptography Team] Common Criteria Documentation...
> >
> > I've updated it with my comments.
> >
> > Since the system is written in itself (and runs inside itself), there
> > are several things in the PP that require redesigning very large parts
> > of the system. We need at least one VM hacker on this list to
> > evaluate the feasability of some of the needed changes.
> >
> > Note: The current wiki system is probably not going to be sufficient
> > for long-term usage. Part of the EAL that we need to meet includes
> > positive authorized user identification for all changes to the
> > configuration... and since documentation (and an audit trail and
> > history) will be a major part of proving our case to the assurance
> > labs, I'm thinking that we should treat it as part of the
> > configuration. We'll need individual usernames and passwords for the
> > modifications until we get X.509/PKI up and running, then we'll
> > possibly be able to use PK crypto certificates for authentication.
> >
> > I'll leave it up to Krishna to determine the actual policy and
> > implementation, since he's got formal validation experience. I just
> > know what I've read in the CC PDFs and the single-layer OS/moderate
> > environment document, and I'm interpreting it in the most secure (and
> > most trust-pessimistic) manner that I can.
> >
> > Here's hoping that we get at least one validation out of this in the end.
> > :)
> >
> > -Kyle H
> >
> > On 10/17/06, Krishna Sankar <[hidden email]> wrote:
> > > Have started to put the task list and notes in our cryptography Wiki
> > page at
> > > http://minnow.cc.gatech.edu/squeak/5776.
> > >
> > > For now, the cc information is at the end of the cryptography page. As
> > we
> > > add more details and get a fix on the organization, we can start a set
> > of
> > > new pages.
> > >
> > > Kyle, can you pl add your notes and observations ? Thanks.
> > >
> > > Cheers
> > > <k/>
> > >
> > > > -----Original Message-----
> > > > From: [hidden email]
> > > > [mailto:[hidden email]] On
> > > > Behalf Of Krishna Sankar
> > > > Sent: Tuesday, October 17, 2006 9:46 AM
> > > > To: [hidden email]; 'Cryptography Team Development List'
> > > > Subject: RE: [Cryptography Team] Common Criteria Documentation...
> > > >
> > > > > http://code.google.com/p/squeak-cc-validation/ = Validation
> > > > > documentation, plan and test results, bug tracking. This
> > > > should not
> > > > > hold code.
> > > > <KS>
> > > >
> > > > I would prefer to hold the validation documentation,
> > > > plan and test results in a Wiki. That way we have built-in
> > > > revision control as well as history tracking. In that sense
> > > > the Google projects do not help us.
> > > >
> > > > The bug tracking in Google projects is fine.
> > > >
> > > > </KS>
> > > >
> > > > > -----Original Message-----
> > > > > From: [hidden email]
> > > > > [mailto:[hidden email]] On
> > > > Behalf Of
> > > > > Ron Teitelbaum
> > > > > Sent: Tuesday, October 17, 2006 9:34 AM
> > > > > To: 'Cryptography Team Development List'
> > > > > Subject: RE: [Cryptography Team] Common Criteria Documentation...
> > > > >
> > > > > I thought the idea was to us SVN for those documents? If more is
> > > > > needed let's just use the wiki that is part of
> > > > > www.squeaksource.com/Cryptography
> > > > >
> > > > > It's not a full wiki in that it doesn't appear to support
> > > > file uploads
> > > > > but that what I thought the google source was for.
> > > > >
> > > > > Can we map out what our requirements are and what our current
> > > > > resources are for meeting those requirements, then we can
> > > > look at what
> > > > > more we need.
> > > > >
> > > > > What I see is:
> > > > >
> > > > > www.squeaksoruce.com/Cryptography = Code Repository and limited wiki
> > > > >
> > > > > http://code.google.com/p/squeak-cc-validation/ = Validation
> > > > > documentation, plan and test results, bug tracking. This
> > > > should not
> > > > > hold code.
> > > > >
> > > > > [hidden email] is our mailing list.
> > > > >
> > > > > Ron
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [hidden email]
> > > > > > [mailto:[hidden email]] On
> > > > > Behalf Of
> > > > > > Krishna Sankar
> > > > > > Sent: Tuesday, October 17, 2006 11:11 AM
> > > > > > To: 'Cryptography Team Development List'
> > > > > > Subject: RE: [Cryptography Team] Common Criteria Documentation...
> > > > > >
> > > > > > Kyle,
> > > > > >
> > > > > > Can you see if you have the SVN write access ?
> > > > > > All,
> > > > > > Just as FYI, we need gmail address to become part of the Google
> > > > > > project and it has no Wiki. Any thoughts on the Wiki for us to
> > > > > > document the functionalities and the results of
> > > > > development/testing ?
> > > > > >
> > > > > > Cheers
> > > > > > <k/>
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [hidden email]
> > > > > > > [mailto:[hidden email]]
> > > > > On Behalf
> > > > > > > Of Kyle Hamilton
> > > > > > > Sent: Monday, October 16, 2006 8:33 PM
> > > > > > > To: Cryptography Team Development List
> > > > > > > Subject: [Cryptography Team] Common Criteria Documentation...
> > > > > > >
> > > > > > > I found the Google Code project that Krishna started, and
> > > > > uploaded
> > > > > > > the Common Criteria documentation I found (in PDF
> > > > > > > form) to it as an issue.
> > > > > > > Unfortunately, I don't have SVN write access, and I
> > > > > don't know how
> > > > > > > to get it either.
> > > > > > >
> > > > > > > After reading it, I realized that it /IS/ a good idea
> > > > for anyone
> > > > > > > starting on CC validation to read it before they start. It's
> > > > > > > important to realize what it is, and what the goals
> > > > must be. (As
> > > > > > > well, it also helps customers -- that'd include you, Ron --
> > > > > > > understand what the various validation levels are, and
> > > > > compare them
> > > > > > > to regulatory
> > > > > > > requirement.)
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > -Kyle H
> > > > > > > I speak only for myself. I don't have the faintest clue about
> > > > > > > anyone else.
> > > > > > > _______________________________________________
> > > > > > > Cryptography mailing list
> > > > > > > [hidden email]
> > > > > > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> > > > > > > ptography
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Cryptography mailing list
> > > > > > [hidden email]
> > > > > >
> > > > >
> > > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptograph
> > > > > > y
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Cryptography mailing list
> > > > > [hidden email]
> > > > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> > > > ptography
> > > > >
> > > >
> > > > _______________________________________________
> > > > Cryptography mailing list
> > > > [hidden email]
> > > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry
> > > ptography
> > > >
> > >
> > > _______________________________________________
> > > Cryptography mailing list
> > > [hidden email]
> > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
> > >
> >
> >
> > --
> >
> > -Kyle H
> > _______________________________________________
> > Cryptography mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>
>
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>

--

-Kyle H
_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Krishna Sankar-2

RE: re: Common Criteria Documentation...

In reply to this post by Kyle Hamilton

> there's a lot more to it than that. Are we going to split
> efforts between cryptography/FIPS and the remainder of the CC
> validation, and maybe do it more quickly? Are we going to
> focus on FIPS first, and only after we get something that we
> can submit for validation then worry about the remainder for CC?
<KS>
Yep, good thoughts. As you correctly point out, first we should aim
for the smallest subset possible; after a successful validation, we can
extend it. That way we get our infrastructure in place, the processes ironed
out and get overall experience. We still will have to address some of the
fundamental issues, but hopefully they are manageable.

In the commercial world, with a product like a firewall or a router,
there is no such luxury - the whole product need to be validated and in a
short period of time.

And as Ron points out, the authenticated site et al can come after
we go thru a dry run. We should still keep a track of the activities,
results et al, but not in a strict authenticated way until we have all the
ducks in a row.

One important aspect we need to think about now is this minimal
subset - and what it should consist of and what it should achieve.

I will also read thru, understand the current environment and think
thru the paces. If we can get the cryptography engine certified, it will be
a win. Am not sure it can be done separately, though.

</KS>

Cheers
<k/>

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On
> Behalf Of Kyle Hamilton
> Sent: Tuesday, October 17, 2006 6:09 PM
> To: Cryptography Team Development List
> Subject: Re: [Cryptography Team] re: Common Criteria Documentation...
>
> Thank you, Craig.
>
> If you look at the bottom of the Cryptography page on the
> minnow/squeak wiki, you'll see what I mean by "serious redesign".
> I'll go through the EAL documentation and the PP, and see
> what else isn't currently implemented but needs to be. (I
> hope that someone else can and will, too, since this is going
> to require something close to actuarial skills. I'm good
> with details, but I sometimes get so tangled in them that I
> forget something important.)
>
> But, that brings this up: this list is about cryptography,
> but our direction is (eventually, as stated by Krishna) CC
> EAL 4+ validation.
> This requires FIPS-validated cryptographic software, but
> there's a lot more to it than that. Are we going to split
> efforts between cryptography/FIPS and the remainder of the CC
> validation, and maybe do it more quickly? Are we going to
> focus on FIPS first, and only after we get something that we
> can submit for validation then worry about the remainder for CC?
>
> -Kyle H
>
> On 10/17/06, Craig Latta <[hidden email]> wrote:
> >
> > Hi Kyle--
> >
> > > Since the system is written in itself (and runs inside itself),
> > > there are several things in the PP that require redesigning very
> > > large parts of the system. We need at least one VM
> hacker on this
> > > list to evaluate the feasability of some of the needed changes.
> >
> > I can do that.
> >
> >
> > thanks!
> >
> > -C
> >
> > --
> > Craig Latta
> > http://netjam.org/resume
> >
> >
> > _______________________________________________
> > Cryptography mailing list
> > [hidden email]
> >
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptograph
> > y
> >
>
>
> --
>
> -Kyle H
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cry

ptography
>

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography

Kyle Hamilton

Re: re: Common Criteria Documentation...

In reply to this post by Kyle Hamilton

On 10/17/06, Krishna Sankar <[hidden email]> wrote:

> > there's a lot more to it than that. Are we going to split
> > efforts between cryptography/FIPS and the remainder of the CC
> > validation, and maybe do it more quickly? Are we going to
> > focus on FIPS first, and only after we get something that we
> > can submit for validation then worry about the remainder for CC?
> <KS>
> Yep, good thoughts. As you correctly point out, first we should aim
> for the smallest subset possible; after a successful validation, we can
> extend it. That way we get our infrastructure in place, the processes ironed
> out and get overall experience. We still will have to address some of the
> fundamental issues, but hopefully they are manageable.

The fundamental design (that the VM is self-hosted) is a fundamental
issue -- but, as you say, it should be manageable. It will take a lot
of work, though.

FIPS 140-2:
- make the timequeue not a singleton, or make a usertimequeue subclass
of the timequeue and call its dispatch whenever the system itself
isn't doing anything (this is just an idea, I don't know how well it
would work... I haven't delved into the scheduling)
- Ensure that the cryptographic objects cannot be changed, cannot be
reflected, and cannot be later diverted (this will be difficult)
- Ensure that cryptographic objects have a critical section capability
(so that the VM can't be written out while unencrypted key data is in
memory)
- Ensure that once a "secure mode" is set, the VM does everything it
can to avoid being debugged by either a native debugger or any
debugger within the VM (to avoid reflection and modification of any
system object and prevent the cryptographic objects from being
reflected)
- Ensure there's a way to verify that the crypto code hasn't been tampered with
- Ensure there's a way to verify that the system code hasn't been tampered with
[etc...]

CC:
- Create the notion of a "security principal", and ensure that private
data of one cannot be accessed by any other (including private keys,
but also including processes)
- Create quotas, by which VM space (and disk space, and processing
time, and so on) cannot be hogged by any individual security principal
[etc...]

> And as Ron points out, the authenticated site et al can come after
> we go thru a dry run. We should still keep a track of the activities,
> results et al, but not in a strict authenticated way until we have all the
> ducks in a row.

Alright. I just offer ideas, as I usually do. If we don't keep track
of it in a strictly-authenticated fashion, we should still be able to
do it via Monticello (especially the unit tests, which should be
written just to verify output from the real routines -- the CSRC at
NIST has a large set of test vectors for various algorithms for
informal verification of correctness, before the full validation is
performed).

> One important aspect we need to think about now is this minimal
> subset - and what it should consist of and what it should achieve.

I would think, at a minimum, that it should include implementations of:
- at least one FIPS-approved symmetric-key cipher
-- at least two FIPS-approved modes of operation
- at least one FIPS-approved asymmetric-key cipher
- at least one FIPS-approved HMAC function
- at least one FIPS-approved hash function
- at least one FIPS-approved pseudo-random number generation function

- design interfaces to each type if they don't already exist, improve
interfaces if necessary

- Implementation of SSL3/TLS1/TLS1.1/TLS1.2 using defined interfaces
- Implementation of ASN.1 parser and BER/DER/XER encodings of ASN.1
- Implementation of X.509v3/PKIX (aka, PKI)
- Implementation of Certificate Signing Request generation
- Implementation of certificate generation (self-signed, at the least,
and perhaps operate as a CA)
- Implementation of OpenPGP

- Implementation of Image Signing/Verification

> I will also read thru, understand the current environment and think
> thru the paces. If we can get the cryptography engine certified, it will be
> a win. Am not sure it can be done separately, though.

"A CC evaluation does not supersede or replace a validation to either
FIPS 140-1 or FIPS 140-2. The four security levels in FIPS 140-1 and
FIPS 140-2 do not map directly to specific CC EALs or to CC functional
requirements. A CC certificate cannot be a substitute for a FIPS 140-1
or FIPS 140-2 certificate." --
http://csrc.nist.gov/cryptval/140-2CC.htm

I think it has to be done separately. Honestly, I'm not sure it can
be done together.

I'm about to upload a whole blob of FIPS, NIST special publications,
and test vectors that I just downloaded from the NIST website to the
Google project. (Again, just getting everything in one place, since
it's been a bear to find it all in the first place.)

-Kyle H
_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography