Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

["Black, David" <[e-mail]>]

> Anyway, I'm pasting David's interpretation of the text that he sent in one
> of the messages in this thread. I would appreciate it if you can share you
> thoughts on this interpretation.
> If this is how most people see it, they would conclude that both clients and
> server would need to be updated together if servers start returning revoked
> for non-issued. I know that this is not what you trying to convey.
I don't think that's a good inference ... but this is getting confusing, so
let's go back to the beginning.

An important consideration is that "revoked" is defined in RFC 2560, so all
existing clients have to be able to cope with that response, independent of
whether they comply with 2560 or 2560bis.  They apparently do cope just fine,
as Piyush wrote:

> Legacy clients will continue to work whether you make it required or optional.
What's new is that there's an additional case, non-issued certificate
serial number, where a 2560bis server could return "revoked" but
a 2560 server will never return "revoked".  OTOH, use of "revoked"
can't be required in this case for the reasons described in Stefan's
new text in 2560bis.

That would appear to lead to the following:

- Server (responder) use of "revoked" for non-issued certificate
    serial numbers is optional for the reasons that Stefan described,
    but suggested when possible because it reduces the likelihood
    of relying parties falling back to CRLs by comparison to use of
    "unknown".  I'm carefully avoiding use of "SHOULD" here.
- Clients (requesters) MUST NOT depend on receiving "revoked" for
    non-issued certificate numbers because servers that comply
    with RFC 2560 won't do that.  According to Piyush, all existing
    deployed clients already meet this "MUST NOT" requirement, so
    nothing else is needed.

Stefan's text in -16 covers the first point.  The second point could
be added for additional explanation, but it would need to go outside
the "NOTE:" due to its use of "MUST NOT."

Thanks,
--David

________________________________
From: Piyush Jain [[e-mail]]
Sent: Saturday, March 30, 2013 8:53 PM
To: 'Stefan Santesson'; Black, David; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

> This is what backward compatibility of a standard is.
> A standard is backwards compatible if any valid implementation of the old
> standard is also a valid implementation of the revised standard.

And I always thought that compatibility applies to implementations.

Anyway, I'm pasting David's interpretation of the text that he sent in one
of the messages in this thread. I would appreciate it if you can share you
thoughts on this interpretation.
If this is how most people see it, they would conclude that both clients and
server would need to be updated together if servers start returning revoked
for non-issued. I know that this is not what you trying to convey.


Pasted from David's message
~~~~~~~~~~~~~~~~~~~~~~
"The usual backwards compatibility concern is mixed new/legacy deployments.
In this case, the specifics appear to be:
New clients with legacy servers cannot expect to see "revoked" in this case.
This matters because a hypothetical client coded to depend on a "revoked"
response in this case won't work correctly with legacy servers (even though
it'd be rather questionable to code that dependency into a new client -
never underestimate the creativity and cleverness of implementers).
New servers with legacy clients risk breaking clients that can't cope with
"revoked" in this case, as you noted:"
End
~~~