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:peter(_dot_)rybar(_at_)nbusr(_dot_)sk]
Sent: Tuesday, July 23, 2013 1:39 PM
To: 'Ayhan Sehrin'
Cc: smime(_at_)ietf(_dot_)org
Subject: RE: [smime] Inquiry on the usage of CAdES in S/MIME structures
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: peter(_dot_)rybar(_at_)nbusr(_dot_)sk
e-mail: peterryb(_at_)gmail(_dot_)com
_____
From: smime-bounces(_at_)ietf(_dot_)org
[mailto:smime-bounces(_at_)ietf(_dot_)org] On Behalf Of Ayhan Sehrin
Sent: Saturday, July 20, 2013 12:33 PM
To: smime(_at_)ietf(_dot_)org
Subject: [smime] Inquiry on the usage of CAdES in S/MIME structures
Importance: High
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.
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime