Subject: Re: [pkix] FW: An errata of RFC 3161 (RE: [ESI] Update of RFC 316 1 - Time St amping)

From: "Pope, Nick" <[email-masked]>
Date: Sun, 6 Sep 2009 11:19:20 +0100

Peter, 

What are the rules regarding what is an update which requires a new RFC
number and what is a new issue of an existing standard?  Is there a document
which describes the IETF practices in this respect?

Correcting errors where there are obvious contradictions in what is
specified in different places within the RFC seems to me much less of a
change that introducing ESSCertv2.

There was another issue which I forwarded which was sent to the ETSI list
(see attached) that raises the question regarding to reference to CMS-RFC
2459 should be updated to RFC 5280:

a) So that newer certificate formats may be used,
b) To bring up to date recommendations regarding use of stronger hash
functions in time-stamp signature.

Again this seems to be a less significant change that introducing ESSCerv2
as it just brings RFC 3161 in line with current practices.

I do agree that we should not open up RFC 3161 to changes which impact the
conceptual framework on which RFC 3161 is based nor should we make changes
which alters the functionality.  But correcting obvious errors (by whatever
means), and ensuring that one can conform with RFC 3161 and be in line
current security practices on algorithms and certificate formats, is
something that we should address.

Nick

PS: Hopefully this will get through to the PKIX list.  If this post fails
again could I ask Peter or Stefan to forward while I sort out my problems
with [email-masked].

> -----Original Message-----
> From: Peter Sylvester [mailto:[email-masked]]
> Sent: 04 September 2009 08:11
> To: Pope, Nick
> Cc: [email-masked]'; [email-masked]'
> Subject: Re: [pkix] FW: An errata of RFC 3161 (RE: [ESI] Update of RFC
> 3161 - Time St amping)
> 
> Pope, Nick wrote:
> >
> > Forwarding mail on RFC 3161 errata that needs to be taken into account
> > in RFC 3161 update.
> >
> If errata are taken into account, the update might get difficult.
> There are several others (like the bad wording for encodings).
> 
> One would nedd two big chapters: One for the ESS "update" and
> one for "corrections" ==>
> 
> Somewhere there should be a reminder that application/tsp-response
> is still used. and may be tolerated.
> 
> In fact, and this goes beyond an update: What is missing is
> a complete small http profile telling the minimal requirements
> of a client, What errors can be received, redirections, text, etc.
> I don't remember in which similar http-based protocol there
> is similar text.
> 
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". 

Subject: FW: (long story) TAC Attribute certificate issue in RFC 3161, Tha les server (or Acrobat)
From: "Pope, Nick" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[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
-------------------------------------------------------------------

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 06 Sep 2009 20:46:27 +0200

Nick,

The procedures for correcting errors is through an errata.
That makes it visible on IETF website. Look at:
http://tools.ietf.org/html/rfc3161

We don't make update documents to update references.
If RFC 3161 reference RFC 2459 and RFC 2459 is oboleted, then that means
that it refers to the RFC that oboletes RFC 2459, which currently is RFC
5280 (via RFC 3280).

So what you ask for is already in force.

When and if we choose to make a new RFC that obsoletes RFC 3161, then we
will include the errata and update references.

/Stefan

On 09-09-06 12:19 PM, "Pope, Nick" <[email-masked]> wrote:

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 06 Sep 2009 21:46:19 +0200

Stefan, Nick,

I realize that my my message could have been misinterpreted,
and also that I had mentioned some errors which are not related
to this particular update.

It may be worth to create a new version more or less soon
to consolidate all errors problems etc that but this is IMO
unrelated to the essv2 update.

Thus I am in phase with Stefan's last comment:

"When and if we choose to make a new RFC that obsoletes RFC 3161, then we
will include the errata and update references."

/P

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 07 Sep 2009 10:13:01 +0200

Nick,

> which describes the IETF practices in this respect?

For error handling there is the following document:
http://www.rfc-editor.org/draft-rfc-editor-errata-process-02.txt

I don't know explicitly where it is stated that IETF does not make new RFC
documents to update references in existing RFCs. It is just something I have
noticed over the years, and something that would create a complete mess if
we did.

Maybe Tim or Pasi could help out with a ref to the precise rules.

/Stefan