Subject: [smime] Inquiry on the usage of CAdES in S/MIME structures

From: "Ayhan Sehrin" <[email-masked]>
Date: Sat, 20 Jul 2013 13:33:02 +0300

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)
- 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).
- 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

- whether the S/MIME RFC should be expected to natively accomodate CAdES profiles in the near future 

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 ŞEHRİN
Man. Director
Verion Technology Group
Birlik Mah. 435. Cad. 403. Sok. No:3/3
Çankaya, Ankara - Turkey

 <tel:%2B90%20312%20496%2033%2016> +90 312 496 3316 (office)
 <tel:%2B90%20533%20556%203333> +90 533 556 3333 (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.

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 21 Jul 2013 09:17:46 +0200

On 2013-07-20 12:33, Ayhan Sehrin wrote:

Hi Ayhan,

Using CAdES in S/MIME structures should be possible with or without an RFC.

Using CAdES together with desktop clients is less feasible and it would probably require a minor miracle fixing it.

OTOH, it seems that your REM solution rather builds on web technology so then there are no hurdles at all!

Thanx
Anders Rundgren

> +90 312 496 3316 <tel:%2B90%20312%20496%2033%2016> (office)
> +90 533 556 3333 <tel:%2B90%20533%20556%203333> (mobile)
>
> _______________________________________________
> smime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/smime

---

From: "Ayhan Sehrin" <[email-masked]>
Date: Sun, 21 Jul 2013 23:05:58 +0300

Thanks Anders for the quick info. Could you possibly elaborate just a little bit?
Do you mean that a CAdES-BES (for some purposes -A) signed S/MIME message should not have any verification and processing problems with the various e-mail clients and other REM implementations?
Kind regards,

Ayhan Şehrin

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]] 
Sent: Sunday, July 21, 2013 10:18 AM
To: Ayhan Sehrin
Cc: [email-masked]
Subject: Re: [smime] Inquiry on the usage of CAdES in S/MIME structures

Hi Ayhan,

Thanx
Anders Rundgren

> - 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)
> - 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
>
> Birlik Mah. 435. Cad. 403. Sok. No:3/3 Çankaya, Ankara - Turkey
>

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 22 Jul 2013 07:21:06 +0200

On 2013-07-21 22:05, Ayhan Sehrin wrote:
> Do you mean that a CAdES-BES (for some purposes -A) signed S/MIME message should
> not have any verification and processing problems with the various e-mail clients
> and other REM implementations?

Hi Ayhan,

No, I meant that if REM builds on web-technology you can use whatever
signature technology you want but if you need to use standard e-mail
clients you will be stuck with S/MIME as it is today.

Regards,
Anders

---

From: Bilal Ashraf <[email-masked]>
Date: Mon, 22 Jul 2013 10:28:53 +0500

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:
>
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.
> structure with the usage of a CAdES signature presents a problem with 
I don't think so.
> 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.
>
> Ayhan S,EHRI.N
> 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.
>
>
>
>
>

---

From: "Peter Rybar" <[email-masked]>
Date: Tue, 23 Jul 2013 12:38:49 +0200

Dear Ayhan,

Archive format of CMS CAdES-A can be implemented with many versions of archive time-stamps.

Only archive time-stamp version 3 (ATSv3) is fixed for S/MIME usage.

The ATSv3 must include the ats-hash-index attribute which shall be carried as an unsigned attribute of the signature of the archive-time-stamp-v3 Attribute (see clause 6.4.3 ETSI TS 101 733 V2.2.1 (2013-04)). 

The ats-hash-index unsigned attribute provides an unambiguous imprint of the essential components of a CAdES signature for use in the archive time-stamp (see 6.4.3). These essential components are elements of the following ASN.1 SET OF structures: unsignedAttrs, SignedData.certificates, and SignedData.crls. 

The redundant CAdES attributes are not required to be included in CMS when ATSv3 is used e.g. now are used CMS fields like the SignedData.crls component as defined in RFC 3852 [4] which can include OCSP and/or CRL revocation information. 

Use of the ats-hash-index attribute makes it possible to add additional certificate / revocation information / unsigned attribute within SignedData.certificates/ SignedData.crls/ unsigned attributes of the CAdES signature (for instance counter signatures), after an archive time-stamp has been applied to a signature. Its use also allows the inclusion of components required by parallel signatures at a later time.

Previous archive time-stamp versions before version 3 have some problems e.g. with adding S/MIME unsigned attribute after archive time-stamp or problems with parallel CMS signatures when one of parallel signatures contains archive timestamp.

Archive timestamp version 3 is defined in ETSI TS 101 733 V2.2.1 (2013-04)

http://www.etsi.org/deliver/etsi_ts/101700_101799/101733/02.02.01_60/ts_101733v020201p.pdf 

Previous versions of CAdES specification have defined many redundant attributes.

The usage of redundant attributes was deprecated in the last profile.

CAdES Baseline Profile ETSI TS 103 173 V2.2.1 (2013-04)

http://www.etsi.org/deliver/etsi_ts/103100_103199/103173/02.02.01_60/ts_103173v020201p.pdf  

It means the use of the CAdES-A profile within the S/MIME structure is possible without know problems only when ATSv3 is included.

More information is from the page 15. It is about: ETSI ESI deprecates long-term formats

http://files.lockitin.webnode.sk/200000078-00104010a3/12th%20Edition%20of%20the%20Conference%20June%2004-06th%202012%20Poland.ppt 

Best regards,

Peter Rybar

National Security Authority

Information Security and Electronic Signature Department

Budatinska 30, 850 07 Bratislava 57, Slovak Republic

tel.: +421 2 6869 2163

mob.: +421 902 891 155

fax: +421 2 6869 1701

e-mail: [email-masked]

e-mail: [email-masked]

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ayhan Sehrin
Sent: Saturday, July 20, 2013 12:33 PM
To: [email-masked]
Subject: [smime] Inquiry on the usage of CAdES in S/MIME structures
Importance: High

Dear list Members, 

Ayhan ŞEHRİN
Man. Director
Verion Technology Group

---

From: "Ayhan Sehrin" <[email-masked]>
Date: Tue, 23 Jul 2013 16:21:53 +0300

Dear Peter,

Thank you very much for the elaborate reply. Our team will be carefully reviewing your input and comments.

Kind regards,

Ayhan Şehrin

From: Peter Rybar [mailto:[email-masked]] 
Sent: Tuesday, July 23, 2013 1:39 PM
To: 'Ayhan Sehrin'
Cc: [email-masked]
Subject: RE: [smime] Inquiry on the usage of CAdES in S/MIME structures

Dear Ayhan,

Best regards,

Peter Rybar

tel.: +421 2 6869 2163

mob.: +421 902 891 155

fax: +421 2 6869 1701

 

  _____  

Dear list Members, 

Ayhan ŞEHRİN
Man. Director
Verion Technology Group