[Top] [All Lists]

Re: Rethinking Receipt

1998-04-14 08:41:25
From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)


I strongly disagree with your proposal because it combines two very
different concepts into a single ASN.1 syntax.  This will be extremely
confusing to the implementors, users and everyone else involved.

The common concept is that one message (a receipt or a reply) is
cryptographically linked to another (the original message).  The
common function can and should be represented by a common syntax.

The differences you point out, human interaction vs. automated response,
reply content vs. no returned content, need to be distinguished
somehow.  I'm not really concerned about the syntax used to make
the distinction; I'm concerned about identifying and reusing
syntax applicable to the area of commonality.

Please re-formulate your proposal so that it does relate to the signed
receipt concept.

OK, how about using attribute IDs to distinguish purpose.  Come to
think of it, I like this better than the original proposal anyway.

  id-aa-receipt  OBJECT IDENTIFIER ::= { ... }
     -- with syntax SignedContentReference

  id-aa-reference OBJECT IDENTIFIER ::= { ... }
     -- with syntax SignedContentReference

  SignedContentReference ::= SEQUENCE {
     contentType ContentType,
     signedContentIdentifier ContentIdentifier,
     originatorSignatureValue OCTET STRING }

<Prev in Thread] Current Thread [Next in Thread>