Subject: [pkix] FW: (long story) TAC Attribute certificate issue in RFC 3161, Tha les server (or Acrobat)

From: "Pope, Nick" <[email-masked]>
Date: Fri, 4 Sep 2009 05:15:44 +0100

Forwarding email on further issue with RFC 3161 update.

I support the proposal that RFC 3161 should be updated to reference to
CMS-RFC 2459 should be updated to RFC 5280:

a) So that new certificates may be used,
b) To bring up to date recommendations regarding use of stronger hash
functions in time-stamp signature (which may be considered more important
that the ESSCertIDv2 update).

Nick

PS: Apologies for forwarding a number of issues in one go but had problems
with using PKIX list.

-----Original Message-----
From: esi : etsi tc esi (electronic signatures and infrastructures)
[mailto:[email-masked]] On Behalf Of Kenji Urushima
Sent: 27 August 2009 11:50
To: [email-masked]
Subject: (long story) TAC Attribute certificate issue in RFC 3161, Thales
server (or Acrobat)

Dear Stefan, Nick and ESI members,

I slightly regret that there is no update of RFC 3161 itself.

I want to share with you an issue of
current RFC 3161, Thales time stamp server (or Adobe Acrobat)
which was found at CAdES/XAdES interoperability test 2007 in Japan.

*********************************
** 1. THE BASE OF ISSUE (SUMMARY)
*********************************

- The version of referring standards such like CMS and X.509 in RFC 3161
are outdated.
- As for attribute certificate, RFC 3161 time stamp token can
  conclude only version *1* of attribute certificate which is
  obsolete by RFC 3369 or later of CMS SignedData.
- Thus, referring standards in RFC 3161 shall be updated.

*********************************************
** 2. WHAT VERSION OF ATTRIBUTE CERTIFICATE
**    CAN BE ATTACHED INTO RFC 3161 TIMESTAMPTOKEN?
*********************************************

RFC 3161 TimeStampToken is a CMS SignedData of the former RFC 2630.
It can store attribute certificates in its certificates field.

 CertificateChoices ::= CHOICE {
   certificate Certificate, -- See X.509
   extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
   attrCert [1] IMPLICIT AttributeCertificate } -- See X.509 and X9.57

As for attribute certificate, RFC 3161 refers the former X.509(08/97).
X.509(08/97) defines old AttributeCertificateV1 which is 
currently obsolete in the newer RFC 3369 CMS or later.

Thus RFC 3161 TimeStampToken can include *ONLY* version *1* of
attribute certificates which has been obsolete now.

*********************************************
** 3. IS THERE ANY TIMESTAMPING IMPLEMENTATION
**    WHICH ATTACHES ATTRIBUTE CERTIFICATES INTO THE TOKENS?
*********************************************

Thales (nCipher) time stamp server which is the best selling 
time stamp server appliance in the world can attaches 
attribute certificates into its issuing time stamp tokens.
It is called 'time auditing certificate (TAC)' and
certifies the time difference between TA and TSA(TSU) to
provide audit trails of time souce.
Data format of TAC is version *2* of attribute certificates
which is not allowed to include in RFC 3161 time stamp token.

*********************************************
** 4. WHERE THE TAC V2 ATTRIBUTE CERTIFICATE
**    WILL BE STORED IN TIME STAMP TOKEN IN 
**    ACCREDITED JAPANESE TIME STAMP SERVICES?
*********************************************

Thales (nCipher) time stamp server can be configured
to choose three locations where TAC V2 attribute certificate
will be stored.

All of Japanese accredited time stamp services take
'attrCert[1]' field of certificates filed of CMS SignedData
to store TAC V2 attribute certificates.
This location violates RFC 2630 since it can't store
version *2* of attribute certificates.

Another choice is to store into 'attrCertV2 [2]' field
which is defined in newer RFC 3369 CMS or later and
not yet defined in RFC 2630 CMS referred by RFC 3161 TSP.

However this location makes version 4 of CMS SignedData of
TimeStampToken.

Adobe Acrobat Reader does *NOT* supports version 4 of
CMS signed data of time stamp token. 
It gets error if it read such time stamp token.

So all of Japanese TSA services takes the location described first.

*********************************************
** 5. CONCLUSION
*********************************************

I don't know who is wrong and how this can be
solved. However in such complicated situation, 
I hope the standard shall provide initiative
and RFC 3161 shall be updated.

Thank you indeed for reading this.

Any comments are appreciated.

Kind regards,

Kenji

-------------------------------------------------------------------
Mail archive for ESI can be browsed at the following url:
         http://list.etsi.org/ESI.html
-------------------------------------------------------------------
Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email [email-masked].
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited".