Brian E Carpenter wrote: > > I have no interest in or knowledge of the technical details, > but there is a pretty complicated DISCUSS against this draft, > which doesn't look like rubber-stamping to me: > https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis/ballot/ > > I assume you've already let the IESG know about the defects you're > concerned about. The concern I originally raised durint LC is primarily a defect of rfc5019 that rfc2560bis does not properly deal with, and is in theory fairly trivial to fix. A much more concerning defect has just recently been uncovered: http://www.ietf.org/mail-archive/web/pkix/current/msg32635.html the complete absence of requirements to allow OCSP response caching (and OCSP response cache updating), which is going to become important for the two work items that are currently active in TLS: - a TLS extension for multiple OCSP response stapling - a TLS caching extension and I strongly believe that PKIX needs to fix that defect/omission and clarify the OCSP response caching semantics in rfc2560bis (and document requirements for "thisUpdate"), or this will result in unexpected and undesirable behaviour (aka interop problems). I have no implementation experience with OCSP, so a number of problems will not be directly apparent to me. But I'm really wondering why noone who has implemented OCSP response caching so far (and I believe there are implementations) has ever brought up this issue against rfc2560 so far. This is close to impossible to miss _for_an_implementor_. -Martin