[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
New Lightweight OCSP I-D
Title: Message
I have some concerns
regarding the new RFC. There are several items in the I-D that are good
engineering advice, but they go far beyond what should be within the scope of
the RFC and should be up to the application and relying party. These are
listed as MUST in the RFC and should be changed to SHOULD or RECOMMENDED.
These items are included in the comments below.
1. Section
1.2.2, sha256WithRSAEncryption should be added to the signature
algorithms.
2. Section
1.2.2, The term "validity window" for the response is not clear or
defined. I suspect it is thisUpdate and nextUpdate for the response.
It should be defined. Furthermore, there is no reason for the Responder
certificate validity period to envelope the response window. For example,
the Responder may have been issued a new certificate since thisUpdate or may get
a new certificate before nextUpdate. Thus, this requirement is
excessive. Also, it is not clear why this requirement is imposed from
security viewpoint.
3. Section
1.2.3, It is not clear if the certificate has expired and the Responder does not
maintain revocation status of expired certificates, what the response should
be. May be "unauthorized" is meant. If so, this should be made
clearer.
4. Section
2.1, The recognition of AIA should be changed from MUST to RECOMMENDED.
Using MUST means that clients and implementations that use OCSP Responder as
trust anchor, will have an added requirement.
5. Section
2.1, The requirement to check OCSP before CRL as a MUST is excessive. This
should be recommended. It should be left up to the implementation to
determine whether to use CRL or OCSP.
6. Section
2.2, The order in which path is validated and when the OCSP response is
requested, should be changed from MUST to RECOMMENDED. This should be an
application decision.
7.Section 3, When
nonce is not included in the request or response, another way to check
freshness are producedAt and thisUpdate. These should be described in
this section.
8.Section 3, The
checks for nextUpdate that are MUST should be changed to RECOMMENDED.
Basically, freshness check should be based on the local policy and this I-D
should RECOMMEND items based on a combination of the three dates asserted in the
response.
9.Section 5.1,
Caching should be RECOMMEND and not MUST.
10. The I-D
should explicitly require the Responders to have access to accurate source of
time in order to assert producedAt and possibly thisUpdate and nextUpdate,
depending on how the Responder asserts these two values.
Santosh Chokhani Orion Security Solutions, Inc.
1489 Chain Bridge Road, Suite
300 McLean, Virginia
22101 (703)
917-0060 Ext. 35
(voice) (703) 917-0260
(Fax) chokhani@xxxxxxxxxxxx Visit our Web site http://www.orionsec.com