Re: Way forward - updating RFC 3161

[Stefan Santesson <stefan@xxxxxxxxxxx>]

Title: Re: Way forward - updating RFC 3161

Denis,

I have seen your response and waited to see if someone is stepping up to support you, but it seems that you are quite alone in your urge to update the terminology and role separation of the time stamping protocol.

My primary issue is not whether the role separation is accurate and well motivated. The central issue for me is why it need to be included in the protocol specification.
Note that we have a very similar situation with PKI. The CA issues certificates, but in practice the CA will delegate the signing to a “unit” and may delegate authorization of attributes to  “Registration Authority”. Still, the CA is ultimately the responsible party and not any “unit” or other subordinate entity or process. The same is true for a TSA. The TSA is the responsible entity and as such the entity that is represented by the certificate of the service, even if that certificate indicates which unit under the TSA control that actually signed the Time-stamp.

As long as this does not reflect any bits on the wire, it would just be confusing to define the role separation structure behind the service as part of the protocol.

This is where I think you have failed to convince us.

Unless I hear new convincing arguments, I will treat the answers on this list as a rough consensus decision to NOT make a full replacement of RFC 3161, but merely provide an update document with ESSCertIDv2 and possibly similar minor updates, but to drop alignment with RFC 3628 terminology.

/Stefan



On 09-07-10 3:55 PM, "Denis Pinkas" <denis.pinkas@xxxxxxxx> wrote:

>  
> No doubt that everybody agrees that RFC 3161 should be updated to allow the use of RFC 5035 [ESSV2]. 
> The question is whether other changes should also be made.
>
> The major differences from RFC 3161 [RFC3161] are summarized on page 3 of the draft and are listed below:
>
>      1 - the document has been aligned with RFC 3628 to make the 
>          difference between a time-stamping unit (TSU) and a TSA.
>
>      2 - the document makes the difference between a time-stamping 
>          service and a time-stamping unit and allows a time-stamping 
>          service to support more than one time-stamping unit.
>
>      3 - the format of the subject field of a TSU certificate is now 
>          defined.
>
> and also some minor updates :
>
>      4 - informative references to ISO 18014-1 [ISO18014-1], 
>          ISO 18014-2 [ISO18014-2] and ISO 18014-3 [ISO18014-3] have been 
>          added.
>
>      5 - a new normative ASN1 module to refer to the ASN.1 modules 
>          from the latest RFCs. 
>
> At the moment, RFC 3161 makes confusion between three different concepts: 
> a TSA, a TSS and a TSU, respectively a Time-Stamping Authority, 
> a Time-Stamping Service and a Time-Stamping Unit. 
>  
> IMO, the document should be cleaned to call a spade a spade.
>
> Historically, the notions applicable to TSAs have been copied and pasted 
> from the documents related to CAs. Since a CA had one private key, a TSA 
> had one private key as well, but this was short looking.
>
> The CA advertises one public key, or more exactly one trust anchor, usually 
> by issuing a self-signed certificate. This private key, when in use, 
> is supported by one HSH (Hardware Security Module). This private key needs 
> to be saved in order to be restored in case of a problem. The time for restoration 
> is usually not critical (this may take a few minutes or even a few hours). 
> The life time of a CA certificate (or CA public key) is usually between one and 
> 15 years and should not be changed earlier, unless strictly needed.
>
> In order to provide time-stamp tokens (TSTs) with high availability, more than 
> one TSU is usually needed. These units altogether provide a TSS (Time-Stamping Service) 
> that is managed by an Authority called a TSA (Time-Stamping Authority).
>
> The key used to sign TSTs is not the key from a TSA, but the key from a TSU.
>
> In order to a high level of security, the key used to sign to TSTs should NOT be saved 
> and restored. It should be generated by the TSU itself and should NOT be exported 
> outside the TSU. If the key of the TSU is erased purposely or by accident, a new key pair 
> and certificate should be generated. Since TSU certificates are provided by a CA, 
> TST verification systems do not need to change any trust anchor. Some TSUs may even 
> use short-lived TSU certificates, e.g. a TSU certificate valid for one week or even one day. 
> However, it is necessary to be able to know the name of the TSA when looking at the 
> subject DN from the TSU certificate.
>
> Along these lines, several changes should be made to RFC 3161. To mention a few of them:
>
> RFC 3161:
>    If the TSA does not recognize the hash 
>    algorithm or knows that the hash algorithm is weak (a decision left 
>    to the discretion of each individual TSA), then the TSA SHOULD refuse 
>    to provide the time-stamp token by returning a pkiStatusInfo of 
>    'bad_alg'.
>
> Proposed change :
>    If the TSS does not recognize the hash 
>    algorithm or knows that the hash algorithm is weak (a decision left 
>     to the discretion of each individual TSA), then the TSS SHOULD refuse 
>     to provide the time-stamp token by returning a pkiStatusInfo of 
>     'bad_alg'.
>
> RFC3161:
>    The certificate identifier (ESSCertID) of the 
>    TSA certificate MUST be included as a signerInfo attribute inside a 
>   SigningCertificate attribute.
>
> Proposed change:
>    The certificate identifier (either ESSCertID  or ESSCertIDv2) of the TSU certificate 
>   MUST be included as a signerInfo attribute inside a SigningCertificate attribute.
>
> RFC 3161:
>    The serialNumber field is an integer assigned by the TSA to each 
>   TimeStampToken.
>
> Proposed change: 
>    The serialNumber field is an integer assigned by the TSU to each 
>    TimeStampToken.
>
> RFC 3161:
>    genTime is the time at which the time-stamp token has been created by 
>  
>    the TSA.
>
> Proposed change:
>    genTime is the time at which the time-stamp token has been created by 
>    the TSU.
>
> RF3161:
>    The purpose of the tsa field is to give a hint in identifying the 
>    name of the TSA.
>
> Proposed change:
>    The purpose of the tsu field is to give a hint in identifying the 
>    name of the TSU.
>
> Note that the difference between a TSU and a TSA that is already present 
> in RFC 3628 (Informational) is also present in ISO 18014 and in ETSI TS 102 023.
> All these documents have been issued after RFC 3161.
>
> Even, if the bits on the wire are the same, the meaning of these bits 
> would not necessarily be the same. For example, the ESSCertID refers to 
> a  certificate from a TSU, not from a TSA.
>
> Since the changes to be done are scattered around the document, a new draft 
> would seem more appropriate, hence why a new draft has been proposed.
>
> >From another angle, should we have an update to RFC 3161 or a new draft? 
> An update would have to advantage to keep the magic number 3161 that everybody 
> identifies with TSP.
>
> In any case, I believe that both the ESSCertIDv2 and the terminology aspects 
> should be addressed to align RFC 3161 with the documents issued after it. 
>
> Denis
> >  
> > -----  Message reçu ----- 
> >  
> > De  : Stefan Santesson <mailto :stefan@xxxxxxxxxxx>  
> >  
> > À  : Pope,Nick,ietf-pkix <mailto :Nick.Pope@xxxxxxxxxxxxxxxxxxxx,ietf-pkix@xxxxxxx>   
> >  
> > Date  : 2009-07-09, 13:13:15
> >  
> > Sujet  : Re: Way forward - updating RFC 3161
> >  
> >
> >  
> >  
> >  
> > I conclude that the list so far is unanimous in its  view of not accepting the approach of draft-ietf-pkix-rfc3161bis-01.
> > Even  though we have not heard the opinion of the draft author, It feels that we  will have a strong consensus for just making a short update  document.
> >
> > /Stefan
> >
> >
> > On 09-07-01 12:47 PM, "Pope, Nick" <Nick.Pope@xxxxxxxxxxxxxxxxxxxx>  wrote:
> >
> >  
> > > Stefan,
> > >  
> > > I also agree with the approach  of updating RFC 3161.  Changing the model of RFC 3161 is only going to  cause confusion.
> > >  
> > > The implementation architecture concepts used  in the earlier proposal are already described in RFC 3628  and so I see  no need for further steps on that  aspect.
> > >  
> > > Nick
> > >  
> > >
> > > -----Original Message-----
> > > From: Stefan  Santesson [mailto:stefan@xxxxxxxxxxx]  
> > > Sent: 01 July 2009 02:00
> > > To: ietf-pkix@xxxxxxx
> > > Cc: Denis Pinkas;  Pope, Nick
> > > Subject: Way forward - updating RFC  3161
> > >
> > > We  need to resolve how to update RFC 3161 with respect to allowing support of  RFC 5035 (ESSV2)
> > > One particular reason is because ETSI ESI is dependent  on progression of this issue in PKIX.
> > >
> > > I would like to open this issue  up for debate and then hopefully conclude this issue, possibly after a straw  poll.
> > >
> > > My personal opinion, and what I interpret as the general  opinion of this working group is that we should reject  draft-ietf-pkix-rfc3161bis-01 as basis for updating rfc 3161. This draft  intends to obsolete RFC 3161 and introduces major changes to terminology and  role description to align RFC 3161 with the informational document RFC  3628.
> > >
> > > It is problematic to introduce such major changes to a standard  that is widely deployed. It is neither required from a protocol  implementation perspective as these changes are not intended to change any  bits on the wire. The optional usage of ESSV2 does not motivate a total  rewrite of the current standard, but is better handled in an update  RFC.
> > >
> > > If description of roles and responsibilities that so not change  any bits on the wire need to be clarified in relation to RFC 3628 and RFC  3161, then this should be handled either as an update to RFC 3628 or as a  separate informational document.
> > >
> > > /Stefan