Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

Unfortunately what you suggest would not be backwards compatible, and can't be done within the present effort. Responders using 5019 need to work in foreseeable time with legacy clients that knows nothing about the update you suggest. This group and the IETF made a decision when publishing 5019, t

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

Stefan Santesson wrote: > Unfortunately what you suggest would not be backwards compatible, > and can't be done within the present effort. I'm sorry, I can not follow your arguments. Adding 3 more OCSPResponseStatus error codes { no_authoritative_data(7), single_requests_only(8), unsupported_exte

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

On 3/26/13 12:13 PM, "Martin Rex" wrote: >Adding 3 more OCSPResponseStatus error codes { no_authoritative_data(7), >single_requests_only(8), unsupported_extension(8) } with well-defined and >conflict-free semantics to the existing enum would be perfectly backwards >compatible. Of course it is ba

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

Following up to myself: The real discussion seemed to have started in 2006... Some folks had a pretty reasonable opinion at some point of the discussion, e.g. Russ Houseley: http://www.ietf.org/mail-archive/web/pkix/current/msg03570.html and then there is lots of real dirty horse-trading in the

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

Stefan Santesson wrote: > On 3/26/13 12:13 PM, "Martin Rex" wrote: > > >Adding 3 more OCSPResponseStatus error codes { no_authoritative_data(7), > >single_requests_only(8), unsupported_extension(8) } with well-defined and > >conflict-free semantics to the existing enum would be perfectly backward

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

What OCSP client are you using that behaves like this? On 3/26/13 1:09 PM, "Martin Rex" wrote: >I would no longer get a popup from my OCSP client that tells my >that I'm unauthorized to submit OCSPRequests to that server, and that >the server has been moved to a blacklist

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

Stefan Santesson wrote: > What OCSP client are you using that behaves like this? > > On 3/26/13 1:09 PM, "Martin Rex" wrote: > > >I would no longer get a popup from my OCSP client that tells my > >that I'm unauthorized to submit OCSPRequests to that server, and that > >the server has been moved

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

I take it that the answer to my question is none. Which is what I suspected. The semantics of "unauthorized" does not give you the basis for such functionality. And 5019 is very widely deployed. I'm going to sep down from this discussion and see how it goes. It is not me you have to convince. It'

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

Stefan Santesson wrote: > I take it that the answer to my question is none. Why would an rfc5019 client have a problem with a (7) instead of (6) OCSPResponseStatus? And what about an error code for "only a single request" that rfc5019 fails to specify. > > Which is what I suspected. The semanti

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

> "Martin" == Martin Rex writes: Martin> Oh, here is a message from the Security AD back then (Sam Martin> Hartman), commenting on requirements for rfc2560bis (the I-D Martin> under last call right now!): Martin> http://www.ietf.org/mail-archive/web/pkix/current/msg03515.

Re: [pkix] Last Call: (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

Sam Hartman wrote: > Martin Rex writes: > Martin> http://www.ietf.org/mail-archive/web/pkix/current/msg03515.html > > To be clear, I didn't comment on which error codes were overloaded to do > what. My point was simply that there needs to be a minimal set of > client behavior that is guarantee

Gen-ART review of draft-ietf-pkix-rfc2560bis-15

Authors, I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pkix-rfc2560bis-15

Gen-ART review of draft-ietf-savi-threat-scope-06

I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document:

RE: Gen-ART review of draft-ietf-savi-threat-scope-06

> Review Date: March 27, 2013 Copy/paste glitch - that should be March 25 for obvious reasons ... Thanks, --David > -Original Message- > From: Black, David > Sent: Monday, March 25, 2013 9:04 PM > To: McPherson, Danny; Fred Baker; joel.halp...@ericsson.com; gen-...@ietf.org > Cc: Jean-M

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

Hi David, Thanks for the review. My reply in line. On 3/26/13 1:25 AM, "Black, David" wrote: >Authors, > >I am the assigned Gen-ART reviewer for this draft. For background on >Gen-ART, please >see the FAQ at . > >Please resolve these comm

Gen-ART Last Call Review of draft-ietf-ospf-ipv4-embedded-ipv6-routing-07

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ospf-ipv4-embedded-ipv6-rout

Re: [core] Last Call: (Constrained Application Protocol (CoAP)) to Proposed Standard

Hi Shoichi, On Mar 19, 2013, at 01:55, Shoichi Sakane wrote: > And, the length of URI is likely to be bigger than the MTU. > > Do you assume a use case in which the total length of options is going > to be greater than the MTU ? CoAP has been designed for constrained devices, and networks buil

Re: [core] Last Call: (Constrained Application Protocol (CoAP)) to Proposed Standard

Hi Carsten, On 3/27/13 8:34 AM, Carsten Bormann wrote: Hi Shoichi, On Mar 19, 2013, at 01:55, Shoichi Sakane wrote: And, the length of URI is likely to be bigger than the MTU. Do you assume a use case in which the total length of options is going to be greater than the MTU ? CoAP has been