headers
Chuck Shih | 2 Mar 1997 08:26

Re: Revision of MDN Section of AS#1

It is Saturday night, and yes, here I am working away at "yet another"
revision of the AS#!!. This time I have incorporated the comments of
Carl Hage, see below. Attached is an AS#1 with some (most) of Carl's
comments incorporated. I think (hope) this stuff is getting close, and I
hope (will) to post it next week to the IETF web site. 

Carl Hage wrote:
> 
> ----

> There should be another section defining the MIC when there is no
> signature, e.g. add section 3.d) which specifies how the MIC is calculated
> for unsigned messages.

This has been added under a new subsection 5.2.1, with essentially your
wording.

> ----
>    - disposition-field - for EDI use:
>         "notprocessed" - The received content(s) was not processed.
> 
> This definition is too vague. 
> .... There should probably be a distinction
> between ignoring/rejecting a message and an error condition.
> ---

I kept the notprocessed and added an error value, and made the
distinction between ignored/rejected and processing errors. This is to
be found in Section 5.3.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Carl Hage | 3 Mar 1997 01:11

Revision of MDN Section of AS#1

Oops, I forgot to ask in the prior message:

What is the advantage of not signing an MDN? (Please explain you
rationale of why it should be unsigned in the case of format difficulties.)

I can only think of:

   - Software won't be confused by an unsupported format
   - The CPU time to generate a signature would be wasted
   - The receipt would be ugly-- cluttered with a weird looking sig
   - Don't ask, don't tell, don't do anything you weren't asked to

In the first case, it would be wrong to implement software that
would be confused. Since a sig was requested, presumably the sig
multipart can be unwrapped. The more complex issue is when a sig
is not requested but returned signed. I think the multipart form
addresses this as best possible, and is generally upwards compatible
with current non sig-aware email software.

The second case is the perogative of the signer.

The third case seems doesn't seem as important as the ability to
verify a sig once software is installed (e.g. Windows-01 scheduled to
come out in 4 years).

The fourth case is a philosophy in life.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<email:carl <at> chage.com> Voice/Fax: 1-408-244-8410       1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carl Hage | 3 Mar 1997 00:55

Re: Revision of MDN Section of AS#1

The latest version is looking good-- very close to complete.

>From chucks <at> actracorp.com (Chuck Shih):
>I have re-worded both 2.2.3 and added 5.2.1 to clarify how to handle the
>situation when a signature is not explicitly requested. I disagree with
>you on this point, and the list should comment. My opinion is that if a
>signature is not explicitly requested, or parameters are not recognized,
>that an unsigned MDN should be returned. Although the Fajman spec states
>that all bets are off, I think that within Internet EDI an unsigned MDN
>should always be returned in these situations.

Let me explain my rationale.

Consider the paper analogy. Suppose you get a form that requires the
signature of your parents. You might not be able to comply, e.g. you
might return the form signed by the director of an orphanage, but
you wouldn't return the form unsigned. Likewise, the "signature" might be
a rubber stamp, or whatever is actually appropriate. If the UPS
driver delivers a package and gives it to a neighbor, the neighbor's
signature is returned instead of an unsigned receipt.

In essence, a request for signed receipt means you want (for both
verification and non-repudiation) a receipt, certified that the
message was received by a unique signature. If the format requested
cannot be complied with, then a certified receipt can still be
returned with a unique signature. Non-repudiation still applies
as long as a unique signature is attached. The signature could still
be verified after the fact.

If a signature were always returned as a policy (whether requested or
(Continue reading)

Permalink | Reply | 0 comments |
headers
Karen Rosenthal | 3 Mar 1997 17:17

Re: Revision of MDN Section of AS#1

Chuck Shih wrote:
> 
> Carl Hage wrote:
> >
> > I don't like the idea of defining undefined headers. This is contrary to the
> > purpose of standards. Aren't there some obvious values that can be defined
> > now and implemented by the vendors?
> >
> > A list of values might be better. Not all conditions can be defined with
> > a single word. Allowing multiple words provides a means to convey semantics
> > for more than one function.
> 
> The only value that has been brought up in the discussion is Dale's, and
> that would be autoprocessed. The list feels that a qualifier field on
> the dispostion field is preferable to allowing a list of disposition
> fields, primarily because it is easier to process. The semantics of a
> list of disposition values can become fairly complex.

I think the concept of the X-Disposition-Qualifier-Field has mutated
since our phone edipilot phone discussion.  My understanding of the
implementation this field was to be used only as a 'text elaboration' of
the disposition field.  I understand Carl's reaction to using an
unstandardized field in this manner, but it during discussion it did
seem to adequately address the business issue brought up by Dale.  My
understanding of its usage was solely for human readable 'text' only -
not for a program's decision making.  An application could stuff this
field into a DB / storage field for human review.  In our phone
discussion, it was agreed that we'd add another disposition (i.e.
autoprocessed-with-warning), and allow the warning description to be put
in the X-Disposition-Qualifier-Field.  Then, an application could decide
(Continue reading)

Permalink | Reply | 2 comments |
headers
Carl Hage | 3 Mar 1997 20:16

MIC definition has problems

One more thing I noticed. The definition:

   - extension field = "X-"  "Received-content-MIC"  ":"  MIC

is ambiguous and incomplete.

The definition "a one-way hash function" doesn't specify which one-way
has function, nor how the value is encoded, e.g. hex or base64.

----------------
Background Info:
----------------

PGP uses MD5, PKCS7 and MOSS mention MD2 and MD5. Somewhere I've seen SHA.
IANA doesn't seem to have anything useful, and the micalgid assignments
don't seem like they are being updated.

MOSS (RFC1848) defines:
      <micinfo>       ::= "MIC-Info:" <micalgid> "," <ikalgid> ","
                          <asymsignmic> CRLF

where the misleading name "MIC-Info" really means "digital signature".

In the MIME multipart/signed (RFC1847), there is also a micalgid:

    Content-Type: multipart/signed; protocol="TYPE/STYPE";
            micalg="MICALG"; boundary="Signed Boundary"

    parameter := "micalg" "=" value
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rik Drummond | 3 Mar 1997 21:27

Re: Revision of MDN Section of AS#1

Karen Wrote:

>I think the concept of the X-Disposition-Qualifier-Field has mutated
>since our phone edipilot phone discussion.  My understanding of the
>implementation this field was to be used only as a 'text elaboration' of
>the disposition field.  I understand Carl's reaction to using an
>unstandardized field in this manner, but it during discussion it did
>seem to adequately address the business issue brought up by Dale.  My
>understanding of its usage was solely for human readable 'text' only -
>not for a program's decision making.  An application could stuff this
>field into a DB / storage field for human review.  

Karen has a good memory.... We agreed that it was only for text
elaboration, at least over the short term because error codes which have
real debug meaning only get defined in the second generation after we
find all the error conditions.. not in the first generation.  The field
is for trading partner debug conditions and is not for machine readable
stuff...

later...rik
Permalink | Reply | 0 comments |
headers
Chuck Shih | 3 Mar 1997 23:10

Re: Revision of MDN Section of AS#1

Karen and Carl,

Newest revision. I have:

a). Allowed the sending of signed receipts when the signed receipts are
not explicitly requested, or as a matter of policy, wherein signed
receipts are always returned as a business practice. This is in 2.2.3
and 5.2.1. There seems to be some general consensus on this point.
Hopefully others weigh in with their opinions. 

b). The "diposition-qualifier-field" has been refined to specify its
original intent, although I do define a "none" value.

c). The "X-Received-content-MIC" has been updated to allow the return of
the MIC algorithm used, and clarified with recommendations on what MIC
algorithm to use if the original message was not signed.

d). Miscellaneous updates: put content-type of message/rfc822 nad
text/plain in the example. 

Please review and send comments. I would like to freeze the draft
tomorrow and get it posted, so more people may be inclined to look it
over. Thanks for all the comments however.  

> 
> +----------------------------------------------------------------------+
> This message was addressed to:  edipilot <at> lists.commerce.net
> +----------------------------------------------------------------------+
> 
> Chuck Shih wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chuck Shih | 4 Mar 1997 02:12

MIC Calculation and Multipart Boundary

I am posting this in hopes that the implementers of multipart/signed all
either use the following to calculate and verify the MICs when using
multipart/signed, or tell the list how they are doing it, so we can
confirm that we are calculating the MIC over the same thing:

1). Take the EDI content and transfer encode it using base64, for
    EDI data, this does the required canonicalization.

2). Formulate the MIME headers and embody the EDI content within the
    MIME headers.

3). Calculate the MIC over the MIME headers and the EDI content.

4). Send the message to the recipient.

The recipient then does the following:

1). Canonicalize the base64 encoded content by converting all line
    delimiters to <CR><LF>.

2). Scan for the multipart boundary and back-up either one or two
    bytes (to account for the <CR><LF>, <CR>, or <LF> line
delimiter        that always precedes the boundary), to the end of the
content.

3). Calculate the MIC on the MIME headers and the content arrived at
by     backing up the 1 to 2 bytes from the beginning of the first
boundary     hypen.

An alternative to doing the above would be to canonicalize the line
(Continue reading)

Permalink | Reply | 2 comments |
headers
Rik Drummond | 4 Mar 1997 16:10

EDIINT - comments on AS#1

Please make the following changes to the as#1 draft as below. the
sections 4.2.2, 4.3.2 and 4.3.4 are confussing in the current version.

Later....rik
	

4.2.2 No encryption, signature

      -RFC822/1521
          -RFC1847 (multipart/signed)
              -RFC2015 (application/pgp-signature)
                  -RFC1767 (application/EDIxxxx)

	4.3.2 No encryption, signature

      -RFC822/1521
          -RFC1847 (multipart/signed)
                  -Draft (dusse) (application/x-pkcs7-signature)
                        -RFC1767 (application/EDIxxxx)

	4.3.4 Encryption, signature

      -RFC822/1521
          -Draft (dusse) (application/x-pkcs7-mime)
              -RFC1847 (multipart/signed)
                      -Draft (dusse) (application/x-pkcs7-signature)
                               -RFC1767 (application/EDIxxxx)
Permalink | Reply | 2 comments |
headers
Chuck Shih | 4 Mar 1997 18:15

Re: MIC Calculation and Multip

Bob,

The RFCs do address how to calculate the MIC on multipart/signed. The
canonicalization that must be done is spelled out, but folks need to be
able to find it. I was looking in RFC1847 but was directed to RFC1848
where the issue is discussed in some detail. However, sometimes it is
not all that simple to feret out what it is our specific implementation
requires to be done.

I just wanted the implementers to be on the same page with this. The MIC
is calculated over the canonicalized form of the EDI or multipart
content. 

       
milr <at> geis.geis.com wrote:
> 
> Reply to item 080bc84 from CHUCKS <at> ACTRA  sent on 97/03/04 03:54
> 
> Hi Chuck, and IETF-EDIINT participants,
> 
> As the X12 Liaison to IETF-EDIINT, I've monitored this list, though
> I've not had time to actively participate in these discussions, and
> I especially have not had time to read the many RFC's of relevance to
> this effort.  When I read of the <CR><LF> problem a few messages back,
> I made a mental 'worry' note, then filed the message.  Now, when I see
> it again in your 'how-to' list, I feel a need to call for a sanity check.
> 
> Surely, it is the data content that should be signed, as presented to be
> enveloped for transport, and not the 'filtered' data content, as may be
> required to satisfy transport standards.  And surely also, since there
(Continue reading)

Permalink | Reply | 1 comment |

Gmane