Re: [pkix] Last Call: <draft-ietf-pkix-rfc2560bis-15.txt> (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

[Stefan Santesson <stefan@xxxxxxxxxxx>]

Denis,

First let me wish you nice rest away from work and good luck in pursuing your future.

Thanks for you effort to make this document better. However your comments are late in the process (with IETF last call being closed).

I have again reviewed your comments and actually found some issues where I misread you and where updates are motivated.

However, please understand that even if we can agree on that the structure of this document is not ideal, we do have a WG consensus to retain as much of the original document structure as possible in order to allow an easier review of the changes from 2560 and this update. This is a tradoff that I as editor must stay true to. Therefore I have made the least necessary changes to accommodate some issues as follows:

1) Protocol overview:

You have a point that the overview would better reflect the protocol if talks about status of certificates rather than a certificate.

I have made a minimalistic update to reflect this fact:

   In lieu of or as a supplement to checking against a periodic CRL, it

   may be necessary to obtain timely information regarding the

   revocation status of certificates (cf. [RFC5280], Section 3.3).

   Examples include high-value funds transfer or large stock trades.

   The Online Certificate Status Protocol (OCSP) enables applications to

   determine the (revocation) state of identified certificates. OCSP may

   be used to satisfy some of the operational requirements of providing

   more timely revocation information than is possible with CRLs and may

   also be used to obtain additional status information. An OCSP client

   issues a status request to an OCSP responder and suspends acceptance

   of the certificates in question until the responder provides a

   response.

   This protocol specifies the data that needs to be exchanged between

   an application checking the status of one or more certificates and

   the server providing the corresponding status.

The rest of your suggestions are to extensive for this type of introduction.

2)  Information about time information (2.4 and 4.2.2.1)

Here I actually completely misread your original post. Looking into this I give you right on the issue. The text in 2.4 and 4.2.2.1 regarding absent nextUpdate are contradictory. A double check in RFC 5280 gives at hand that nextUpdate in CRL MUST be present even if it is optional in the ASN.1 and that the meaning of an absent nextUpdate in CRL is undefined.

However, at the same time, the structure of the document is to define basic parameters in section 2 (such as response indicators and errors). At the same time section 4.2.2.1 deals with the use of these parameters in the protocol. To retain the current structure of the document, I have made the following updates:

Section 2.4:

I kept the definition of the fields but moved the text regarding the meaning of an absent nextUpdate to 4.2.2.1. Section 2.4 now reads:

2.4  Semantics of thisUpdate, nextUpdate and producedAt

   Responses can contain three times in them - thisUpdate, nextUpdate

   and producedAt. The semantics of these fields are:

   -  thisUpdate: The time at which the status being indicated is known

                  to be correct

   -  nextUpdate: The time at or before which newer information will be

                  available about the status of the certificate

   -  producedAt: The time at which the OCSP responder signed this

                  response.

Section 4.2.2.1

This section defines, in addition to the defines semantics of the time fields, how they should be used in the protocol.

• I added a first paragraph referring to the definitions of 2.4, 
• added the text on nextUpdate from 2.4 and removed the conflicting sentence claiming that this is equivalent to a CRL with no nextUpdate, and;
• removed the duplicated explanation of the semantics of produced at.

Section 4.2.2.1 now reads:

4.2.2.1  Time

   Responses can contain three times in them - thisUpdate, nextUpdate

   and producedAt. The semantics of these fields are defined in section

   2.4.

   The thisUpdate and nextUpdate fields define a recommended validity

   interval. This interval corresponds to the {thisUpdate, nextUpdate}

   interval in CRLs. Responses whose nextUpdate value is earlier than

   the local system time value SHOULD be considered unreliable.

   Responses whose thisUpdate time is later than the local system time

   SHOULD be considered unreliable.

   If nextUpdate is not set, the responder is indicating that newer

   revocation information is available all the time.

3) Signed Response Acceptance Requirements

I think you are right that this text should take into consideration that a response could include status of more than one certificate.

However, in line with section 2, this can be quite easily fixed by adding a few words to the first paragraph of sec ion 3.2:

   Prior to accepting a signed response for a particular certificate as

   valid, OCSP clients SHALL confirm that:

This makes it clear that the rules stated in the section applies to each certificate being checked.

There is a point in not being more specific (such as going into discussions of singleResponse) since these rules are generic and may apply also to other than basic responses.

4) Other 

For the other suggestions you make, I don't see that any change is motivated considering the late state of the document, the minimalistic approach consensus and the balance between retaining the document structure and the degree of problem actually being highlighted.

/Stefan

/Stefan

From: Denis <denis.ietf@xxxxxxx>
Date: Wednesday, March 27, 2013 10:35 PM
To: <ietf@xxxxxxxx>
Cc: Stephen Kent <kent@xxxxxxx>, Stefan Santesson <stefan@xxxxxxxxxxx>
Subject: [pkix] Last Call: <draft-ietf-pkix-rfc2560bis-15.txt> (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

First of all, this is an announcement: I am retiring from Bull at the end of this week, this why I am now using a new email address.
The second announcement is that I am taking one full month off (vacations) and will be traveling in Asia.
So, I will not be able to respond quickly on the list.

 

I am getting bored of 2560bis which was started more than 3 years ago and everybody in the WG is getting bored too.
However, it is the last chance to correct what is still incorrect in the draft.

 

During the PKIX WG last call, Stefan Santesson replied to many of my comments with "Not broken", meaning that it considered
that the current wording did not have such problems that it merits a change.

 

I said that it would have been a waste of time for both of us to argue again at the WG level and thus that I will resend
these comments during the IETF LC. We are now at that stage.

 

The 11 comments were originally numbered 2, 3, 7, 10, 12, 14, 15, 16, 17, 25 and 27. I have kept the same numbering.

 

Comment 2

The current text from section 2 states:

2.  Protocol Overview

   In lieu of or as a supplement to checking against a periodic CRL, it

   may be necessary to obtain timely information regarding the

   revocation status of a certificate (cf. RFC5280], Section 3.3).

   Examples include high-value funds transfer or large stock trades.

   The Online Certificate Status Protocol (OCSP) enables applications to

   determine the (revocation) state of an identified certificate. OCSP

   may be used to satisfy some of the operational requirements of

   providing more timely revocation information than is possible with

   CRLs and may also be used to obtain additional status information. 

This text is misleading because readers may think that OCPS necessarily provides “timely information”.

Proposed text replacement:

   The Online Certificate Status Protocol (OCSP) is a client-server

   protocol which enables applications to obtain the revocation status

   of one or more certificates either "good", "revoked", or "unknown".

   The revocation status may be provided by the server either using a

   real time access to a database of issued certificates, or using a

   batch access to a database of issued certificates, or using a

   real time access to a database of revocation statuses of issued

   certificates, or using a batch access to a database of revocation

   statuses of issued certificates, or using CRLs, or using a

   combination of base CRLs and delta CRLs.

   In the first case, it is possible to obtain timely revocation status

   information, whereas in the other cases, the freshness of the

   revocation status is not better than the mechanisms it is based on.

Stefan answered “Not broken” and added “"may" does not mean "necessarily".

This does not solve the issue since the text is misleading an OCSP server may only use CRLs
and then it does not provides timely information since the information it provides is not better that CRLs.
How can a normal reader guess this ?

 

Comment 3

The current text from section 2 states:

   An OCSP client issues a status request to an OCSP responder and 

   Suspends acceptance of the certificate in question until the 

   responder provides a response.

   This protocol specifies the data that needs to be exchanged between

   an application checking the status of a certificate and the server

   providing that status.

Thus is insufficient for an overview. More details are needed to know what the document provides,
in particular that the request may contain several requests for several certificates issued by different CAs.
The possibility of using extensions should also be advertised.

Proposed text replacement:

   When using OCSP, an OCSP client issues a certificate revocation

   status request to an OCSP responder for one or more certificates

   issued by the same CA or for one or more certificates issued by

   different CAs and then suspends acceptance of the certificate(s)

   in question until the responder provides a response.

 

   This document specifies the data that needs to be exchanged between

   an application checking the status of a certificate and the server

   providing that status. 

   OCSP may also provide additional status information using

   extensions.

When using the wording “acceptance of the certificate” the singular is being used
and the reader may not realize that the protocol allows to ask the status of several certificates.

 

Comment 7

The text states on page 7:

   The response for each of the certificates in a request consists of

   -  target certificate identifier

   -  certificate status value

   -  response validity interval

   -  optional extensions

However, there are no explanations for the purpose of these parameters and how they should be processed.

There are also no explanations on how to process a single response and how to verify that it is its presence
within the signed structure is valid or not valid. This is a major deficiency of the current description of RC 2560
where there is no explanation on how to validate a single response. This is the most important comment.

Text proposal to be added after:

   The purpose of the identifier of the OCSP server is to allow OCSP

   clients to find whether the definitive response was signed by a CA

   or by an OCSP Responder.

   The identifier of the OCSP server SHOULD either be the name or the

   key from a CA, or the name or the key from a OCSP Responder.

   Unless there exist local rules (which are outside the scope of this

   document) for verifying that a single response is correctly signed,

   the following applies:

   When the identifier matches with the name of the CA which has issued

   the target certificate or corresponds to the key used to issue the

   target certificate, then a single response is correctly signed

   only if the digital signature of the OCSP response is valid using the

   key used to sign the target certificate.

   When the identifier does not match with the name of the CA which has

   issued the target certificate or does not correspond to the key used

   to issue the target certificate, then an single response is correctly

   signed only if :

         (a) there exists in the response an OCSP certificate issued by

             the CA which has issued the target certificate which is

             signed by the same key as the one used to issue the

             target certificate, and

         (b) the digital signature of the OCSP response is valid using

             the subjectPublicKey contained in this OCSP certificate.

 

Stefan answered “Not broken” and claimed that “All of this is already covered by the document”.

Unfortunately, this is not the case.

 

Comment 10

The text states on page 8:

2.4  Semantics of thisUpdate, nextUpdate and producedAt

This section is misplaced. At this time of reading, the reader does not know that thisUpdate,
nextUpdate and producedAt are values used by the ASN.1 structures. It is appropriate to describe
what theses parameters mean when the ASN.1 syntax is described.
The current ASN.1 syntax is very badly described. One would expect that after every ASN.1 structure
description every parameter is described.

Unfortunately this is not the case.

The text from this section is not aligned with the text that is present in section 4.2.2.1.

In particular, in section 2.4:

   If nextUpdate is not set, the responder is indicating that newer

   revocation information is available all the time.

While in section 4.2.2.1:

   Responses where the nextUpdate value is not set are equivalent
   to a CRL with no time for nextUpdate (see Section 2.4).

It is not appropriate to have two different descriptions in two different places.

Delete section 2.4. See comment number 19 for the description of these parameters.

Stefan answered : Not broken and added ”The current text segments fits well into a protocol overview section”.

However, he did not realize that the two sentences do not say the same thing.

 

Comment 14

The text states on page 11:

3.2  Signed Response Acceptance Requirements

   Prior to accepting a signed response as valid, OCSP clients SHALL

   confirm that:

   1. The certificate identified in a received response corresponds to

      that which was identified in the corresponding request;

   2. The signature on the response is valid;

   3. The identity of the signer matches the intended recipient of the

      request.

   4. The signer is currently authorized to sign the response.

   5. The time at which the status being indicated is known to be

      correct (thisUpdate) is sufficiently recent.

   6. When available, the time at or before which newer information will

      be available about the status of the certificate (nextUpdate) is

      greater than the current time.

This section is misplaced since it uses terms from the ASN.1 syntax and the protocol description has not yet been made,
since it is the next section 4. Its text is not correct either.

This description does not take into account the fact that a BasicOCSPResponse may contain one or several SingleResponses.
In particular, the sentence “The signer is currently authorized to sign the response” is misleading because a signer
may be authorized to include some SingleResponses but not necessarily all of them.

The appropriate explanations should be done after the description of the response, when describing the processing of the response.

Delete that section.

Stefan answered “Not broken”.

 

However, the important matter is to make the difference between single responses and the basic response.
The basic response cannot be validated, only single responses can be INDIVIDUALLY validated. This text is wrong
(or is only valid when the request contains a single certificate request).

 

Comment 15

On page 12, after the ASN.1 description, the only parameters which are described are:

hashAlgorithm, issuerNameHash, issuerKeyHash and serialNumber.

This is insufficient.  In order to cover the full list of parameters, the following text is proposed:

   requestorName is optional and MAY be used by the server for access

   control and audit purposes.

 

   requestList contains one or more single requests.

 

   requestExtensions is OPTIONAL.  Any specific extension is OPTIONAL.

   The critical flag SHOULD NOT be set for any of them. Section 4.4

   suggests several useful extensions.  Additional extensions MAY be

   defined in additional RFCs.

 

   reqCert contains the identifier of a target certificate.

 

   issuerNameHash is the hash of the Issuer's distinguished name.  The

   hash shall be calculated over the DER encoding of the issuer's name

   field in the certificate being checked.

 

   issuerKeyHash is the hash of the Issuer's public key.  The hash

   shall be calculated over the value (excluding tag and length) of the

   subject public key field in the issuer's certificate.  The hash

   algorithm used for both these hashes, is identified in

   hashAlgorithm.

 

      The primary reason to use the hash of the CA's public key in

      addition to the hash of the CA's name, to identify the issuer,

      is that it is possible that two CAs may choose to use the same

      name (uniqueness in the Name is a recommendation that cannot be

      enforced). Two CAs will never, however, have the same public key

      unless the CAs either explicitly decided to share their private

      key, or the key of one of the CAs was compromised.

 

   serialNumber is the serial number of the certificate for which

   status is being requested.

 

   singleRequestExtensions is OPTIONAL.  Any specific extension is

   OPTIONAL.  The critical flag SHOULD NOT be set for any of them.

   The requestor MAY choose to sign the OCSP request.  In that case, the

   signature is computed over the tbsRequest structure.  If the request

   is signed, the requestor SHALL specify its name in the requestorName

   field.  Also, for signed requests, the requestor MAY include

   certificates that help the OCSP responder verify the requestor's

   signature in the certs field of Signature.

 

Stefan answered: “Not broken. The current text is short, but it is actually sufficient from the context of the ASN.1 definitions
of the section. This is a detailed protocol section and the reader need to understand ASN.1 in any case to understand
and implement the section.

The information about criticality is already covered in the extension section”.

 

I disagree the current text is so short that it omits to define the semantics and the use of most parameters.

 

Comment 16

Section 4.1.2 is called: “Notes on the Request Syntax”

The first paragraph has been moved after the description of issuerKeyHash and thus is no more needed.

The second paragraph has been moved after the description of requestExtensions.
However, the sentence
“ Unrecognized extensions MUST be ignored (unless they have the critical flag set and are not understood)”
has been deleted since it applies to the OCSP responder and not to the OCSP client. Thus it is no more needed.

The third paragraph applies to signed requests. However, it should belong to a section dedicated on how clients should build OCPS requests,
which is currently missing. See the next comment.

This section should be deleted.

Stefan answered ”Not broken”.

I disagree. The rules are to describe the ASN.1 syntax and to explain every parameters used in the syntax. The initial draft has been very badly written and it is time to write it correctly now.

 

Comment 17

There should be a new section called: “Requirements for OCSP clients”.

It is important first to re-advertise that the request may be about several certificates.
Thus it is important to describe the process for building a request, which is currently missing.

   An OCSP request allows getting in the same response the revocation

   status of one or more certificates.  In order to request the

   status of one or more certificates in a single request, OCSP

   clients SHALL follow the following rules :

 

   For each candidate certificate, OCSP clients SHALL verify

   whether there exists a locally defined rule for the certificate in

   question which indicates the URI where the OCSP responder is

   located.  If this rule exists, it SHALL be followed.

   Otherwise, OCSP clients SHALL determine whether the candidate

   certificate contains an AIA extension with an accessMethod which

   contains the id-ad-ocsp OID.  If it is the case, the accessLocation

   contains a uniformResourceIdentifier (URI) which indicates the

   location of the OCSP server for that certificate.

   Certificates that contain the same URI MAY be grouped in a single

   request.

 

Note:  For each candidate certificate, when performing the path

       validation algorithm, the OCSP client SHOULD verify that the

       current time is within the validity period of the target

       certificate.  Certificates which are outside their validity

       period SHOULD NOT be included in the request.

 

   The requestor MAY choose to sign the OCSP request. In that case, the

   signature is computed over the tbsRequest structure. If the request

   is signed, the requestor SHALL specify its name in the requestorName

   field. Also, for signed requests, the requestor MAY include

   certificates that help the OCSP responder verify the requestor's

   signature in the certs field of Signature.

 

Stefan answered “ Not broken.

Your text may provide guidance that could be useful to some implementers, but is completely beyond this document and further, not generally applicable or true.

As an example, an organisation may setup an in house locally configured OCSP responder that responds to all certificates "out there" that is relevant to that organisation.

Such clients would just blindly send OCSP requests to their local responder, disregarding any information in the cert.

It's totally beyond this spec to have an opinion about this”.

 

The argumentation above is incorrect. The proposed text states:

 

   OCSP clients SHALL verify

   whether there exists a locally defined rule for the certificate in

   question which indicates the URI where the OCSP

 

This means that OCSP clients would just blindly send OCSP requests to their local responder.

 

Comment 27

On page 24, text should be added to the Security consideration section:

Denial of service attack using a flood of queries

 

   A denial of service vulnerability is evident with respect to a flood

   of queries.  The production of a cryptographic signature

   significantly affects response generation cycle time, thereby

   exacerbating the situation.

 

   The flood of queries may either come from a flood attack or from the

   fact that there are too many certificates supported by the same OCSP

   responder.  In the later case, the number of queries can be

   reduced by using a technique similar to the splitting of CRLs:

 

      When a block of certificates have been issued with the same

      accessLocation in the AIA extension field of these certificates,

      then the accessLocation should be changed.  In this way, a given

      OCSP server will only be responsible for a block of certificates.

 

Stefan answered “If the security considerations section is talking about splitting OCSP responders
in this way, then the document itself need to introduce the subject.

I would suggest that it is beyond this update to do so.

 

It is a good guidance to limit denial of service conditions.
I believe that the IESG enjoys information in the security considerations section.

:-)

 

Denis