Re: Inquiry on the usage of CAdES in S/MIME structures

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
> [email protected]
> https://www.ietf.org/mailman/listinfo/smime

_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime