OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: SSL Mutual Authentication and the Message Service Spec


I think you have made a very good point for not storing user
name and password in the CPA. However, the CPA should
at least indicate whether basic authentication is to be used
plus some reference to a generalized credential container
where applicable, if the CPP/A spec is to be aligned with the
MSG spec.


-----Original Message-----
From: Dale Moberg <dmoberg@cyclonecommerce.com>
To: Arvola Chan <arvola@tibco.com>; Dan Weinreb <dlw@exceloncorp.com>
Cc: ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>;
ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>
Date: Tuesday, August 28, 2001 8:31 AM
Subject: RE: SSL Mutual Authentication and the Message Service Spec

If the actual credentials are to be stored
in a CPA or CPA template (where those
credentials may be some userid/name and
password combination), then we would need
to wait until XML Encryption is done to
obtain the necessary data confidentiality.

We have considered these issues previously
on several occasions (for example, for ftp
user, password, and directories to be used...).
Each time we have had reservations about
storing these items within a CPA. One reason
beyond data confidentiality issues, is that
these credentials are subject to different
policies concerning expiration, unilateral
changeability, and so on. (We don't
want to invalidate a CPA signature because
of a change in passwords, necessarily.)

Possibly we could use an xlink/xpointer/URI to
within the CPA to reference a generalized credential
container if there is a need to establish links between
CPAs and credentials. (This credential
container would be something like
the pkcs12 container used for keypairs;
I haven't yet encountered an XML credential
store container format that has been proposed,

Dale Moberg

-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Tuesday, August 28, 2001 8:17 AM
To: Dan Weinreb
Cc: ebxml-cppa@lists.oasis-open.org; ebxml-msg@lists.oasis-open.org
Subject: Re: SSL Mutual Authentication and the Message Service Spec


Thanks for pointing out the relevant use case. I was just trying to
find out if there is a need to augment the CPA with user and
password information to allow basic authentication to be performed.

Do you think the 1.1 MSG and CPP/A specs need to be aligned
with respect to the issue of basic authentication?


-----Original Message-----
From: Dan Weinreb <dlw@exceloncorp.com>
To: arvola@tibco.com <arvola@tibco.com>
Cc: ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>;
ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>
Date: Monday, August 27, 2001 8:36 PM
Subject: Re: SSL Mutual Authentication and the Message Service Spec

>   Date: Thu, 23 Aug 2001 09:41:08 -0700
>   From: Arvola Chan <arvola@tibco.com>
>   More changes to the CPP/A spec will be necessary to support Basic
>   Authentication. However, I seriously doubt if basic authentication
>   sends user name and password in cleartext is suitable for conducting
>   business transactions. Perhaps we should lobby the MSG TC to remove
>   requirement to support basic authentication in the 1.1 spec.
>I agree that sending passwords in cleartext is right out, but perhaps
>what's being contemplated here is using Basic Authentication over an
>HTTPS (SSL/TLS) connection to do client authentication in cases where
>the client doesn't have a private key and associated digital
>certificate.  That scenario arises a lot in "B2C"; I don't know how
>likely it is to come up in ebXML interactions.

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