headers
Terry Dosdale | 3 Feb 1997 10:30
Picon
Picon

UN/EDIFACT SJWG comments on EDIINT documents

Dear Rik

Further to my previous email, I wanted to explain that most SJWG 
members (including myself) have not subscribed to the EDIINT list.  It 
would therefore be most helpful if, after discussing the document with 
your group, you could make a formal reply to me.  I will then distribute 
it to the SJWG members.  I apologise if this seems rather formal, but we 
already belong to several EDIFACT lists, and I am sure you will 
understand the amount of mail which this can generate!

Kind regards

Terry Dosdale

Dr Terence Dosdale CEng FBCS Chartered Information Systems Practitioner
-----------------------------------------------------------------------
Axiom Services Limited     -    for    -   Electronic Commerce/Security
3 Holt Park Rise                           http://www.email.demon.co.uk
LEEDS                                           Tel +44 (0)113 230 1910
LS16 7QZ                                        Fax +44 (0)113 230 1910
UK                                        Email axiom <at> email.demon.co.uk
-----------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Terry Dosdale | 3 Feb 1997 12:55
Picon
Picon

UN/EDIFACT SJWG

I have had several enquiries (from Joe, Wayne and James) as to whether
the SJWG has any newsgroup or list server.  We try to be as open as
possible, but we're not an Internet group, so the group has a closed
list for its day to day business, like correcting documents, which would
be boring to other people.  However, the idea of having an open list in
parallel has been mooted in the past, and I am quite keen on this, so I
will contact the appropriate organisation to see if this is possible.

You can also participate actively through your regional UN/EDIFACT body
(PAEB) - I assume you're all based in the US?  I suggest you contact Jim
Sykes (uslevp8s <at> ibmmail.com).

You may get the formal documents from Axiom Services' Web page (below).
Either look at the EC/EDI/Security link to get the last version
published by the UN, or the Security Joint Working Group link to find
the most recent versions (to be published by the UN in March, with
different cover pages).

Kind regards

Terry Dosdale

Dr Terence Dosdale CEng FBCS Chartered Information Systems Practitioner
-----------------------------------------------------------------------
Axiom Services Limited    -   for   -  Electronic Commerce/EDI/Security
3 Holt Park Rise                           http://www.email.demon.co.uk
LEEDS                                           Tel +44 (0)113 230 1910
LS16 7QZ                                        Fax +44 (0)113 230 1910
UK                                        Email axiom <at> email.demon.co.uk
-----------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chuck Shih | 4 Feb 1997 01:00

Re: Requesting Signed Receipts

Carl,

I will update the MDN portion of AS#1 with some of your and Karen's
suggestions on requesting and processing MDNs. More specifically I will:

1). Incorporate a signature-protocol parameter with values equal to the
MIME defined types of application/x-pkcs7-signature and
application/pgp-signature. This parameter will specify which format the
requestor would like the returned signed MDN to be in. This parameter
will be used for completeness, and an explicit signature-algorithm
parameter will still be specified, because within each security format,
the choices for algorithms is not or will not be fixed. I don't think it
is a good idea to make assumptions on what the supported algorithms are
from the security format. 

2). Incorporate a signature-algorithm parameter that is a list of 
signature algorithms that the requestor would like the recipient to use
in signing the MIC. The list of signature algorithms are processed from
left to right by the recipient.

3). Incorporate a signature-micalg parameter that is a list of MIC
algorithms that the requestor would like the recipient to use in
calculating the MIC on the MDN. The list of signature-micalgs are
processed from left to right by the recipient.  

All the parameters specified above will have the O designation so that
an MDN can always be returned to the requestor. Unrecognized parameters
or parameter values will have a new disposition, "unrecognized parameter
or parameter value" that will be defined in the MDN specification.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Karen Rosenthal | 3 Feb 1997 23:08

Re: Requesting Signed Receipts

Chuck Shih wrote:
> 
> All the parameters specified above will have the O designation so that
> an MDN can always be returned to the requestor. Unrecognized parameters
> or parameter values will have a new disposition, "unrecognized parameter
> or parameter value" that will be defined in the MDN specification.
> 
> The dispositions that are specific to the signed receipt will be
> specified in the AS#1 and registerd with IANA. At this point in time,
> this is the list of dispostion extended values defined by the AS#1:
> 
> 1). Unsupported signature algorithm - occurs when none of the list of
> signature algorithms requested are supported by the recipient.
> 
> 2). Unsupported signature MIC algorithm - occurs when none of the list
> of MIC algorithms requested are supported by the recipient.
> 
> 3). decryption failed
> 
> 2). authentication failed
> 
> 3). integrity check failed
> 

I liked Carl's comment in his previous email that perhaps the MDN
request errors should be separated from the actual receipt disposition. 
I think the originator will want to know if decryption, authentication
or integrity failed, regardless of whether their request was
syntactically correct or the signature or micalg preferences are
supported by the recipient.  Non-repudiation shouldn't hold unless the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carl Hage | 4 Feb 1997 04:53

Re: Requesting Signed Receipts

>From chucks <at> actracorp.com  Mon Feb  3 17:56:10 1997
>
>suggestions on requesting and processing MDNs. More specifically I will:
>
>1). Incorporate a signature-protocol parameter with values equal to the
>MIME defined types of application/x-pkcs7-signature and
>application/pgp-signature. This parameter will specify which format the
>requestor would like the returned signed MDN to be in. This parameter
>will be used for completeness, and an explicit signature-algorithm
>parameter will still be specified, because within each security format,
>the choices for algorithms is not or will not be fixed. I don't think it
>is a good idea to make assumptions on what the supported algorithms are
>from the security format.

OK. Probably, 'x-pkcs7-signature' and 'pgp-signature' are appropriate
since 'application' is assumed. New types can be added implicitly with
new MIME definitions.

Typically, the algorithms are defined by software packages that
support the protocols. For example, the sigalg and micalg used by
PGP does not vary for any existing PGP implementation. Likewise,
I think all S/MIME software supports identical sets of sigalgs and
micalgs.

Not all versions of PGP and S/MIME are compatible. This is not just
an algorithm issue, it's a protocol issue. There might be different
MIME types for different versions, but lack of version presents a
problem. This could be inferred from sigalgs, but not necesarily.

I agree that there could be a need to identify algorithms, but not
(Continue reading)

Permalink | Reply | 0 comments |
headers
Karen Rosenthal | 7 Feb 1997 15:13

Use of multipart/encrypted with S/MIME

I am looking for some clarification on the (intended?) use of the
multipart/encrypted Content-Type with S/MIME.

It is my understanding from the edipilot conference call this past
Wednesday, that rather than supporting directed adherence to the S/MIME
v2 specification (using application/x-pkcs7-mime body parts), the ediint
working group is suggesting adherence to RFC1847 (Security Multiparts
for MIME - Multipart/Signed and Multipart/Encrypted).  (If I am mistaken
here, please let me know!)

The usage of multipart/signed is well detailed in the S/MIME v2
specification, but use of multipart/encrypted is not mentioned, nor is
it accounted for in design.  So for a vendor that supports S/MIME, but
not PGP or MOSS, what should be used for the multipart/encrypted
protocol, and what will the MIME message look like?

Regards,
--

-- 
Name:	Karen Rosenthal
E-mail:	karenr <at> premenos.com
Phone:	(510)688-2928
Fax:	(510)602-2133
Permalink | Reply | 2 comments |
headers
Chuck Shih | 7 Feb 1997 19:17

Re: Use of multipart/encrypted with S/MIME

Karen,

The AS#1 is not recommending use of multipart/encrypted when using
S/MIME. The S/MIME enveloped data format will still be used. The
multipart/signed however will be recommended (per the wg meeting in SJ),
instead of the PKCS signed data format. Both are supported by S/MIME,
but multipart/signed is also specified as an Internet RFC.

Does this clarify the confusion?

Karen Rosenthal wrote:
> 
> +----------------------------------------------------------------------+
> This message was addressed to:  edipilot <at> lists.commerce.net
> +----------------------------------------------------------------------+
> 
> I am looking for some clarification on the (intended?) use of the
> multipart/encrypted Content-Type with S/MIME.
> 
> It is my understanding from the edipilot conference call this past
> Wednesday, that rather than supporting directed adherence to the S/MIME
> v2 specification (using application/x-pkcs7-mime body parts), the ediint
> working group is suggesting adherence to RFC1847 (Security Multiparts
> for MIME - Multipart/Signed and Multipart/Encrypted).  (If I am mistaken
> here, please let me know!)
> 
> The usage of multipart/signed is well detailed in the S/MIME v2
> specification, but use of multipart/encrypted is not mentioned, nor is
> it accounted for in design.  So for a vendor that supports S/MIME, but
> not PGP or MOSS, what should be used for the multipart/encrypted
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rik Drummond | 7 Feb 1997 19:43

Re: Use of multipart/encrypted with S/MIME

We will be using the standard pkcs-7/encrypted form from
smime.....whoever we will be using as the smime spec say the multipart
signed as our many structure for signature....by  doing this the
receipent can read a signed message if they do not have smime.....hope
that helps....

Karen Rosenthal wrote:
> 
> +----------------------------------------------------------------------+
> This message was addressed to:  edipilot <at> lists.commerce.net
> +----------------------------------------------------------------------+
> 
> I am looking for some clarification on the (intended?) use of the
> multipart/encrypted Content-Type with S/MIME.
> 
> It is my understanding from the edipilot conference call this past
> Wednesday, that rather than supporting directed adherence to the S/MIME
> v2 specification (using application/x-pkcs7-mime body parts), the ediint
> working group is suggesting adherence to RFC1847 (Security Multiparts
> for MIME - Multipart/Signed and Multipart/Encrypted).  (If I am mistaken
> here, please let me know!)
> 
> The usage of multipart/signed is well detailed in the S/MIME v2
> specification, but use of multipart/encrypted is not mentioned, nor is
> it accounted for in design.  So for a vendor that supports S/MIME, but
> not PGP or MOSS, what should be used for the multipart/encrypted
> protocol, and what will the MIME message look like?
> 
> Regards,
> --
(Continue reading)

Permalink | Reply | 0 comments |
headers
Karen Rosenthal | 7 Feb 1997 17:37

Re: Use of multipart/encrypted with S/MIME

Chuck & Rik,

Thanks for your quick responses.  For clarification:

.  Signed only goes out as multipart/signed,
protocol=application/x-pkcs7-signature.
.  Encrypted only goes out as application/x-pkcs7-mime, EnvelopedData.

Question: Does Signed & Encrypted go out as multipart/signed within
application/x-pkcs7-mime, EnvelopedData, or as application/x-pkcs7-mime,
SignedData within application/x-pkcs7-mime, EnvelopedData?  The former
doesn't make sense.  If the latter, then I don't understand the issue
discussed Wednesday on edipilot test 8 (during which I obviously
misunderstood that only multipart/signed within multipart/encrypted
would be accepted)?

Thanks,
Karen

Chuck wrote:
> Karen,
>
> The AS#1 is not recommending use of multipart/encrypted when using
> S/MIME. The S/MIME enveloped data format will still be used. The
> multipart/signed however will be recommended (per the wg meeting in > SJ),
> instead of the PKCS signed data format. Both are supported by S/MIME,
> but multipart/signed is also specified as an Internet RFC.
>
> Does this clarify the confusion?
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chuck Shih | 7 Feb 1997 21:19

Re: Use of multipart/encrypted with S/MIME

Karen,

Since I wasn't on the conference call, why doesn't the multipart/signed 
within EnvelopedData make sense?

Karen Rosenthal wrote:
> 
> Chuck & Rik,
> 
> Thanks for your quick responses.  For clarification:
> 
> .  Signed only goes out as multipart/signed,
> protocol=application/x-pkcs7-signature.
> .  Encrypted only goes out as application/x-pkcs7-mime, EnvelopedData.
> 
> Question: Does Signed & Encrypted go out as multipart/signed within
> application/x-pkcs7-mime, EnvelopedData, or as application/x-pkcs7-mime,
> SignedData within application/x-pkcs7-mime, EnvelopedData?  The former
> doesn't make sense.  If the latter, then I don't understand the issue
> discussed Wednesday on edipilot test 8 (during which I obviously
> misunderstood that only multipart/signed within multipart/encrypted
> would be accepted)?
> 
> Thanks,
> Karen
> 
> Chuck wrote:
> > Karen,
> >
> > The AS#1 is not recommending use of multipart/encrypted when using
(Continue reading)

Permalink | Reply | 0 comments |

Gmane