[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Signed Receipt Requests

Sorry about this inconvenience.  I have removed the restrictions to the
GeneralName type in the SetReceiptRequest.  This should be easy for you to
implement in your logic; simply remove the lines of code that check the
GeneralName choice.  The next release will have this code removed.
<<<<< in ./SMIME/libsrc/lolevel/sm_Attr.cpp
            if (tmpGN->choiceId != GeneralName::rfc822NameCid &&
                tmpGN->choiceId != GeneralName::x400AddressCid)

As to the multiple GeneralNames (double dimensioned list), you are correct,
this is a bit more difficult; we will implement some interface in the future
(probably make the actual SNACC ReceiptRequest available to the user).  This
particular implementation does not generate the SNACC attribute until the
message is encoded.
If this does not fix your immediate problem, please e-mail back; I will work
on full-featured access to the GeneralNames list.
Bob Colestock

-----Original Message-----
From: Graeme Lunt [mailto:g.lunt@xxxxxxxxxxx]
Sent: Tuesday, October 16, 2001 3:33 AM
To: imc-sfl@xxxxxxx
Cc: 'b.doherty@xxxxxxxxxxx'
Subject: Signed Receipt Requests

These are a couple of observations from using the SignedReceipt support in
the SFL - 
they are not bugs, rather perhaps feature requests.
I am trying to add an X.500 distinguished name as a GeneralName into the
field, in addition to an X.400 address. This is to help receiving user
agents encrypt the
signed receipt if required - 

RFC 2634 section 2.4 (last para) states:
"All sending agents that support the generation of ESS signed receipts MUST
the ability to send encrypted signed receipts".
However the code (in sm_Attr.cpp) in CSM_Attrib::SetReceiptRequest
a) prevents me from adding an X.500 DN ("MUST BE rfc822 OR x400Address")
There is a comment in the code that says "According to CMS Spec, MUST be 1
on these 2 types" - 
but I'm not sure what this reference is (RFC 2634 2.2 step 4.?)
b) only allows me to specify a single general name to a "receiptTo". A
single GeneralName
would be OK if I could specify a DN, as I could look up in the email address
of where to send
the signed receipt - but see a)
The basic change required is to allow the setting of multiple GeneralName
components for
a receiptsTo, which is not a minor change. Are there any plans to do this?