Hi Ayhan,
Please see my responses below. Hope it is useful for you.
Regards,
Bilal.
On 7/20/2013 3:33 PM, Ayhan Sehrin wrote:
Dear list Members,
As Verion Technology Group, a technology provider working on
Registered E-Mail (REM) solutions since 2009, we are currently in the
process of formulating a set of basic implementation principles and
tools for REM Management Domain (MD)'s operative in Turkey. We need to
resort to your experience and know-how on the subject of the S/MIME
specification, and I was kindly prompted by Mr. Blake Ramsdell to
address your list for further comments and insight.
The Registered E-Mail Regulatory Authority in Turkey has very recently
mandated the use of the CAdES-A profile within the S/MIME structure
and as we are a bit perplexed on the issue, we would like to inquire
your comments on:
- whether it would be logical/feasible/meaningful to use the CAdES-A
profile within an S/MIME structure (for some instances within the REM
workflow CAdES-BES is also required)
Yes, It is possible according to the standard (RFC 3851 and ETSI TS 101
733 V1.8.1).
- whether the above usage would present difficulties/problems in terms
of interoperability of systems (i.e. e-mail clients or BPM/ERP
systems, where the messages are expected to be utilised - e.g. a REM
message received is downloaded and then used as the input of a
business process within a core banking component) especially as
regards the subsequent verification process within these systems and
among different REM Service Providers in Turkey and in Europe (as
Turkey has opted in to the ETSI TS 102640).
If existing clients/applications has to generate or verify CAdES-A
signatures then they need to update their implementations. Also existing
clients/applications don't break if they have CAdES-A signature and
don't want to process CAdES-A specific attributes. I don't think of any
email client supporting CAdES-A signatures.
- whether, from a technical viewpoint, the implementation of an S/MIME
structure with the usage of a CAdES signature presents a problem with
the S/MIME RFC
I don't think so.
- whether the S/MIME RFC should be expected to natively accomodate
CAdES profiles in the near future
There is a section in ETSI TS 101 733 V1.8.1 about how to use MIME in CAdES.
We would gladly provide more details on the ETSI 102640 implementation
in Turkey, if it is of essense to the above inquiries.
We will be much obliged, should you be able to provide insight.
Thank you in advance and warm regards,
Ayhan S,EHRI.N
Man. Director
Verion Technology Group
Birlik Mah. 435. Cad. 403. Sok. No:3/3
Çankaya, Ankara - Turkey
+90 312 496 3316 <tel:%2B90%20312%20496%2033%2016> (office)
+90 533 556 3333 <tel:%2B90%20533%20556%203333> (mobile)
NB-REM implementation in Turkey in a tiny nutshell: In the typical REM
implementation in Turkey, an original message is required to be signed
with the sender's Qualified Electronic Signature, two out of the
currently three REMSPs provide tools for constructing and signing the
sender's S/MIME structure on the client, receive it over https (or
over a web service for enterprise integration instances) to the REMSP
servers. The third REMSP constructs the MIME message on its own
server, hashes it an sends it for a CAdES signature to the sender's
client. Evidence is produced by REMSPs during the mail acceptance,
delivery and retrieval milestones and is expected to be stored in WORM
storage or to be archived, XadES-A for evidence, CAdES-A for all
system logs.
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime