On 3/27/13 5:35 PM, Denis wrote:
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.
Hopefully, you'll still find time in your retirement to keep on PKIXing!
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.
I agree it's time to get this one done.
However, it is the last chance to correct what is still incorrect in the
draft.
There are some changes warranted by these comments. Some are already
addressed in v16. Some I don't see consensus around making.
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
Here we're talking about the protocol overview section, which is where
authors usually say things like my protocol is great and here's why. The
text says:
OCSP may
be used to satisfy some of the operational requirements of providing
more timely revocation information ...
I'm not hearing a bunch of implementers saying the overview is confusing
and they're being unfairly swayed/tricked in to implementing OCSP over
CRLs; All thanks to that goes to the US DoD and their monolithic CRLs.
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*
Addressed by in v16.
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
There's four things listed there. status is discussed at length in s2.2
and s4.2.2.3. The remaining 3 fields are discussed in s4.2.2.3,
s4.2.2.1, and s4.2.2.3, respectively. The bits of text about
determining who signed what is addressed in s4.2.2.2.
I think this one is addressed. If others disagree, I have no doubt
they'll let me know.
*
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
I think implementers can figure out that the bullets in s2.2:
- time when the response was generated
- response validity interval
correspond to producedAt and thisUpdate/nextUpdate in s2.4. So I don't
see the harm in leaving the section where it is.
I consider this one adddressed/adopted except for two little bits that
need to be addressed/added:
Put a number in and I'll count 'em; there's four times in OCSPResponse.
Another time is in revokedInfo and we in fact need to say something
about it in s2.2, s.2.4, and s4.2.2.1.
For s2.2:
OLD:
o the revocation status of the certificate (good, revoked, or
unknown);
NEW:
o the revocation status of the certificate (good, revoked, or
unknown); if revoked it indicates the time at which the
certificate was revoked and optionally the reason why it
was revoked.
For s2.4:
Responses can contain four times - thisUpdate, nextUpdate, producedAt,
and revokedAt. 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.
- revokedAt: The time at which the certificate was revoked.
It will also stop people saying producedAt is the revocationTime. It
might be but it might not be.
For s4.2.2.1:
OLD:
Responses can contain three times in them - thisUpdate, nextUpdate,
and producedAt. ...
NEW:
Responses can contain four times - thisUpdate, nextUpdate,
producedAt, and revokedAt. ....
Somewhere the draft needs to say what format is required of
GeneralizedTime. I assume it's Zulu time. If so add the following to
the end of the 1st paragraph in s4.2.2.1:
The format for GeneralizedTime is as specified in Section 4.1.2.5.2
of [RFC5280].
After all this gets incorporated I'll consider this one addressed/adopted.
The text states on page 8:
*2.4Semantics 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
v16 addresses this without removing the text.
The text states on page 11:
*
3.2Signed 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*
When reading this comment I considered would implementers be confused by
the lack of text about these fields. I believe the answer is no, but I
also know I'd hammer/discuss protocols for not describing them so some
text will be included to describe the fields.
I'll leave it to the editor as to whether he'd prefer to leave it in
s4.1.1 or move the whole thing to s4.1.2. Here's my suggestion:
putting the following before the OCSPRequest ASN.1:
The ASN.1 structure corresponding to the OCSPRequest is:
In s4.1.2 before the existing text (and keep the existing text as is)
I'd add:
The fields in OCSPRequest have the the following meanings:
o tbsRequest is the optionally signed OCSP request.
o optionalSignature contains the algorithm identifier and any associated
algoirthm parameters in signatureAlgorithm, the signature value in
signature, and optionally certificates the server needs to verify the
signed response (normally up to but not including the client's root
certificate).
The contents of tbdRequest include the following fields:
o version indicates the version of the protocol, which for this document
is v1(0).
o requestorName is OPTIONAL and indicates the name of the OCSP requestor.
o requestList contains one or more single certificate status requests.
(note for you Stefan Denis says one or more but the ASN.1 doesn't say
that - I think it's safe to say that's what was meant though.
o requestExtension is OPTIONAL and includes extension applicable to the
all requests found in reqCert. See Section 4.4.
o reqCert contains the identifier of a target certificate and includes:
* 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.
* singleRequestExtensions is OPTIONAL and includes extensions applicable
to this single certificate status request. See Section 4.4.
-----
Now don't go and say well now we need to do the same thing in s4.2.1;
it's different all but one of those fields are discussed later :) Might
not be as explicit as s4.2.1, but the description in s4.2.2.3 is mighty
clear. The one missing description is for algorithmIdentifier and a one
sentence addition in s4.2.1 fixes this (a new second sentence):
OLD:
The value for signature SHALL be computed on the hash of the DER
encoding ResponseData. The responder MAY include certificates in the
certs field of BasicOCSPResponse that help the OCSP client verify the
responder's signature. If no certificates are included then certs
SHOULD be absent.
NEW:
The value for signature SHALL be computed on the hash of the DER
encoding ResponseData. The algorithm and any parameters used to
generate the signature are included in the signatureAlgorithm field.
The responder MAY include certificates in the certs field of
BasicOCSPResponse that help the OCSP client verify the
responder's signature. If no certificates are included then certs
SHOULD be absent.
I consider this one addressed/adopted based on as-yet-not published v17.
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*
I can see moving all of the fields' descriptions to s4.1.2 or putting
the new text in s4.1.1 and point back to s4.1.2. I think this is
editorial and I'll leave it to the editor. In other words adopting
comment 15 means this is adopted too in one form or another.
I consider this one addressed/adopted based on as-yet-not published v17.
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's two nuggets in here and the rest is text that need not be
repeated (and in v16 Stefan addresses the multiples issue).
Nugget 1: The sentence about grouping status information about
certificates from the same URI in on OCSPRequest. The MAY adds nothing
so I just can't see the need for it. Clients might do it or they might
not and that just doesn't seem like useful advice to implementers.
Nugget 2: For status checks on certificates beyond their validity
there's an archive cutoff extension so indicating SHOULD NOT seems
incorrect as you're basically deprecating that feature. I've not seen
any kind of consensus around that in the WG or here.
I'd consider this one closed unless a ground swell begins soon.
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*
After re-reading this text and RFC 4753, it's true for this protocol
like others that it's difficult to tell the difference from a flash
crowd vs DoS attack. In the proposed text, even splitting the load
amongst different OCSP servers still can't protect you against flash
crowds. And, the number of queries received isn't necessarily tied to
how many servers you have. I think the first paragraph is addressed
adequately already in RFC 4732, which is included by reference. There's
volumes of text in RFC 4732 about DoS based on floods, but on
cryptography there' also:
In fact, poorly
designed authentication mechanisms using cryptographic methods can
exacerbate the problem.
If we look at the 2nd paragraph, the first sentence doesn't address the
flash crowd issue. If you split a server that would normally of had 10
certificates on it two to 5 and 5 and one person is doing all the
signing splitting didn't help one bit. I think this one gets down to
provisioning and is covered by RFC 4732:
Thus, the first line
of defense against DoS attacks must be to provision your service so
that it can handle a foreseeable legitimate peak load.
The second sentence and following paragraph don't necessarily follow.
Splitting won't necessarily have an impact on the number of queries
received.
It seems that we're covered by reference on this one so I consider this
one addressed. If anybody else disagrees, I'm sure I'll hear about it.
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
Thanks for continuing to slug away at it.
spt