Piyush Jain wrote:
>
> The sole reason cited for overloading the meaning of revoked status with
> non-issued was that it allows new servers to interoperate with legacy
> clients.
There is *NO* overloading of a revoked status. The change is making use
of an existing temporary revocation status (certificateHold) **EXACTLY**
with the original semantics for a temporary revocation,
originating from X.509 08/2005 8.5.2.2 (a):
A certificate may be placed on hold with a reason code of
certificateHold. The certificate hold notice may include an
optional hold instruction code to convey additional information
to certificate users (see 8.5.2.3).
Once a hold has been issued, it may be handled in one of three ways:
a) it may remain on hold with no further action, causing users to reject
transactions issued during the hold period; or,
>
> The WG agreed that there are many better alternatives but they all
> break compatibility with older clients.
If you want to describe "an OCSP responder no longer responding 'good'
for certificate serial numbers for which no records of issuance exist"
as "breaking compatibility with older clients", then yes, this is what
we want to do.
But in reality, this is change is about fixing a security problem that
was documented as such in rfc2560 for the "good" status.
>
> In fact, a more secure and complete
> proposal by Denis was not adopted because of the same reason.
I don't understand this statement, but there can not possibly be a more
secure solution that reporting revoked for not-issued certs.
>
> I believe that Stefan is trying to convey that requiring servers to return
> revoked in this context will make them non-compliant with 2560 and 5019 as
> opposed to breaking interoperability with legacy clients.
The proposed change primarily intends to _standardize_ how to report
revoked/certificateHold for "not-issued" certificate serial numbers,
something that has been found useful (and already been used) in dealing
with certain kinds of security breaches of CAs/RAs.
Returning revoked/certificateHold for not-issued certs is perfectly
compliant with rfc2560 and rfc5019. Returning "unknown" is also
perfectly compliant with rfc2560 and rfc5019. Returning an error code
response status would be just dumb for an authoritative OCSP responder.
Should rfc5019 be interpreted to suggest for authoritative OCSP responders
to returning an error code for "not-issued" certs does not make such
behaviour any less dumb.
-Martin
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
