[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-jc] Security JC Charter - with Joe's edits
Hi,
I agree that "ISO/IEC JTC 1/SC 6/WG 7 and ITU-T SG 17" may be the formal name, but almost nobody knows them as such. Informally and colloquially, they are almost universally referred to "the X.509 group", which is why I suggested "X.509". (Note that this is different from the "Directory group", which is X.500. True, X.509 is a subset, but most people rightly see these as quite separate activities.)
As I said, I have no problem with adding X9 to the list. I just don't think it should be a replacement for X.509.
Carlisle.
----------
From: Phil Griffin[SMTP:phil.griffin@asn-1.com]
Sent: Friday, September 20, 2002 10:07 AM
To: Security Joint Committee
Subject: Re: [security-jc] Security JC Charter - with Joe's edits
Carlisle,
Look at the context. X.509 is not a group. If you want
to identify the group responsible, we could list ISO/IEC
JTC 1/SC 6/WG 7 and ITU-T SG 17, or simply The Directory
group.
We've already listed IETF, but not specifically the PKIX
or SMIME WGs, which as you know rely on many X9 standards.
But X9 is the critical group for XCBF.
Phil
Carlisle Adams wrote:
> Hi Phil,
>
> I don't agree. It's fine to add "X9", but not to replace "X.509" with
> "X9". There is value in defining how the OASIS specs relate to the
> X.509 work, along with all these other bodies.
>
> Carlisle.
>
>
> ----------
> From: Phil Griffin[SMTP:phil.griffin@asn-1.com]
> Sent: Thursday, September 19, 2002 7:44 PM
> To: PATO,JOE (HP-PaloAlto,ex1)
> Cc: 'security-jc@lists.oasis-open.org'
> Subject: Re: [security-jc] Security JC Charter - with Joe's
> edits
>
> Just one nit. "X.509" below should be "X9".
> (The XCBF TC relies on several X9 finsvcs
> security standards.)
>
> Phil
>
>
> PATO,JOE (HP-PaloAlto,ex1) wrote:
>
> > Security Joint Committee Charter
> >
> > The purpose of the Security JC is to coordinate the technical
> activities
> > of multiple security related TCs, is advisory only, and has no
> > deliverables. A TC shall have no obligation to abide by any
> decision
> > arrived at in the Security JC. The business of the Security JC
> shall be
> > imparted to a member TC through reports from the chair of its
> liaison
> > subcommittee. Such reports shall have the same force and shall
> be made,
> > received, and acted upon in the same manner as reports from any
> other
> > subcommittee of the TC.[1]
> >
> > The business of the Security JC will be:
> >
> > To promote the use of consistent terms
> >
> > · Through consultation with, and the participation
> of member
> > TC's, to encourage new and developing TC's to use consistent
> > security terms and definitions in specification documentation.
> >
> > To promote re-use
> >
> > · To provide the definition and identification of
> re-usable
> > security related specification elements. Security related
> > specification elements are defined as (but are not limited to)
> > object models, use cases, extensible XML elements,
> cryptographic
> > processes and deployment profiles.
> >
> > To champion an OASIS security standards model
> >
> > · To champion the creation of a reference model
> that shows
> > how OASIS security TC specifications are inter-related. This
> > reference model shall define how OASIS security related
> > specifications "fit together" and relate to other security
> relevant
> > works at W3C, IETF, WS-I, X.509 etc.
> >
> > To provide consistent PR
> >
> > · To provide a single point of contact for addressing
> > security related enquiries at OASIS and in doing so to help
> organize
> > and coordinate security related comment and PR from OASIS.
> >
> > To promote mutuality, operational independence & ethics
> >
> > · The SJC will foster and maintain respect among OASIS
> > security TCs and for them in the security community at
> large. The
> > SJC will maintain a vendor neutral and vendor agnostic view
> in its
> > support for diverse security technologies.
> >
> > · The SJC will promote public safeguards and
> believes that
> > security technologies should be used solely for legal,
> ethical, and
> > nondiscriminatory purposes. The joint committee is
> committed to the
> > highest standards of systems integrity and data security in
> order to
> > deter identity theft, protect personal privacy, and ensure
> equal
> > rights in all security applications.
> >
> > [1] This language is derived from the OASIS TECHNICAL COMMITTEE
> PROCESS
> > Section 1, Clause (o). The text is reproduced here to set
> context for
> > this charter. Where there may be substantive differences, the
> OASIS
> > TECHNICAL COMMITTEE PROCESS document is definitive and will
> govern.
> >
> >
> >
> > Joe Pato
> > Principal Scientist
> > Trust, Security & Privacy
> > Trusted Systems Lab - HP Labs
> > <mailto:joe.pato@hp.com>
> > <http://www.hpl.hp.com/personal/Joe_Pato>
> > <http://www.hp.com/security>
> >
> > Hewlett Packard Labs
> > 1 Cambridge Center, 11th Floor
> > Cambridge, MA 02142
> > Phone: (617) 551-7648
> > HP Telnet: (650) 857-2774
> > Fax 1: (617) 551-7650
> > Fax 2: (781) 674-0142
> >
> >
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC