Subject: [pkix] 2560bis WGLC

From: Stefan Santesson <[email-masked]>
Date: Fri, 04 Jan 2013 10:57:47 +0100

Forwarding Steve's WGLC on RFC 2560bis.
(It was misaddressed)

On 1/2/13 4:43 PM, "Stephen Kent" <[email-masked]> wrote:

>Folks,
>
>Stefan has just published the long-awaited 2560bis update, and has
>requested WGLC.
>
>Let's begin a slightly longer WGLC, to accommodate those who may be on a
>post-New year vacation.
>
>the WGLC will end on 1/20/13.
>
>Steve

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 21 Jan 2013 17:11:57 +0000

>> the WGLC will end on 1/20/13.
Hi,
I reviewed the document for the first time and I think it is reasonably 
clear.
I do have however a list of almost trivial issues, which I think need to 
be looked at, as they would help IANA and first time readers:

1) In 2.1, list item: I think there is a missing dot before "If". It 
also looks like that sentence should be in its own paragraph and not in 
item 3.

2) In 3.1: URI RFC (RFC 3986) should be referenced normatively here.

3) The IANA Considerations section is empty, but Appendix C registers 2 
Media Types. I think this is wrong, the IANA Considerations section 
needs to point to Appendix C, or just move Appendix C content into the 
IANA Considerations section.

4) RFC 2616 is normative, as the document defines a normative HTTP mapping.

5) In A.1.2: cache control header fields must be obeyed by proxies. I 
hope this section is not saying otherwise ("MAY ignore").

6) In Appendix C: Published Specification - this RFC? The document 
should say so, so that RFC Editor doesn't forget to insert the RFC 
number here.

7) Change Controller for a WG document is a person? Make it "IETF".

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 27 Jan 2013 11:08:43 +0100

Alexey,

Thanks for your review.

I have tried to address all your issues in draft 10, which I just posted
in response to these comments.
Does this resolve your issue list?

I'm a bit uncertain regarding your point 5.
I did no action on this as the "MAY ignore" relates to the receiving
requester getting a response back and not proxies.
I think that is clear form the text.

/Stefan

On 1/21/13 6:11 PM, "Alexey Melnikov" <[email-masked]> wrote:

>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 27 Jan 2013 11:52:31 +0100

In Chapter

4.2.2.2  Authorized Responders

The order of the text seems rather unfortunate to me. It seems pretty reversed.
The first of the three use cases mentioned at the end is not mentioned at the beginning.

1: Matches a local configuration of OCSP signing authority for the
    certificate in question;

The current does not requireid-kp-OCSPSigning for this use case (only for case 3)
I wonder whether all current clients accept this.

In Chapter

2. Protocol

the use case 1 of a locally configured responder does not provide more timely
information. since this is the FIRST use case, it should be mentioned that
the protocol can be used to delegate revocation checking.

Peter