Re: [TLS] Fwd: New Version Notification for draft-pettersen-tls-ext-multiple-ocsp-03.txt

[Sean Turner <[e-mail]>]

<no hat>

Yngve,

Here are some comments on the draft (hopefully this will encourage 
others to also read it):

1. The Abstract contains the following:

  This document introduces a replacement of the TLS Certificate Status
  Extension to allow clients to specify and support multiple
  certificate status methods.

I know somebody will get to the word "replacement" and start asking 
whether this draft should update 6066.  I don't think that's the intent 
you're just defining a new extension so it should just say that:

  This document defines the TLS Certificate Status Version 2
  Extension to allow clients to specify and support multiple
  certificate status methods.

2. Abstract: Expand OCSP and TLS.

3. Abstract: r/Also being introduced/Also defined

4. The RFC editor will move the "requirements language" paragraph to the 
main body so you might as well do it now.  Move it to s1.1.

5. The copy right notice section contains the pre-5378 paragraph, but 
the draft first appeared after 5378 was published.  Is there some bits 
in here that are copied from 5246 or somewhere else?  If not, then you 
can delete that para.

6. s1: r/Transport Layer Security/Transport Layer Security (TLS)

7. s1: I don't think you need to try to slip in the comparison to other 
methods.  I think it's implied.

OLD:

  The benefits of this extension include a reduced number
  of roundtrips and network delays for the client to verify the status
  of the server's certificate using other retrieval methods and a
  reduced load on the certificate issuer's status response servers,
  thus solving a problem that can become significant when the issued
  certificate is presented by a frequently visited server.

NEW:

  The benefits of this extension include a reduced number
  of roundtrips and network delays for the client to verify the status
  of the server's certificate and a
  reduced load on the certificate issuer's status response servers,
  thus solving a problem that can become significant when the issued
  certificate is presented by a frequently visited server.

8. s1: wordy ;)

OLD:

  There are two problems with the existing Certificate Status extension
  as it is currently defined.

NEW:

  There are two problems with the existing Certificate Status extension.

9. s1: Just some tweaking (two whichs read a little odd):

OLD:

  First, it does not provide functionality
  to request the status information about intermediate CA certificates,
  which means the client has to request this through other retrieval
  methods, such as CRLs, which can cause significant delays when the
  revocation list has to be refreshed.

NEW:

  First, it does not provide functionality
  to request the status information about intermediate Certification
  Authority (CA) certificates,
  which means the client has to request status information through other
  methods, such as CRLs, thus adding additional delay.

10. s1: r/Certificate Authorities/Certification Authorities X2

11. s1: r/Point[RFC5280]/Point [RFC5280]

12. s1: In the following I think the point is just for client-cached 
CRLS because most that responders I know about are fed by a CRL.

OLD:

  Given
  that CRLs, particularly those cached by the client, are frequently
  less up to date than is possible for an OCSP responder, using OCSP to
  access up-to-date status information about intermediate CA
  certificates will be of great benefit to clients.

NEW:

  Given
  that client-cached CRLs are frequently out of date, using OCSP to
  access up-to-date status information about intermediate CA
  certificates will be of great benefit to clients.

13. s1: I guess I'd tweak the following a bit:

OLD:

  The author is aware that the cost of providing this bandwidth
  just for site certificates has been a concern to some CAs,
  particularly the smaller ones, and it follows naturally that doubling
  or tripling this cost could be problematic for the CAs.  The author
  is also aware of at least one case when OCSP requests for a single
  high-traffic site caused significant network problems for the issuing
  CA.

NEW:

  CAs should be aware that there is a cost associated with providing
  bandwidth to support OCSP.  There are cases where OCSP requests for a
  single
  high-traffic site caused significant network problems for the issuing
  CA.

14. s1: r/multiple, OCSP mode/multiple-OCSP method

15. s2.1: r/The extension added by this/The extension defined by this

16.: s2.1: Just trying to avoid the questions about whether this draft 
updates 6066: r/which is updated with this value/which uses the 
following value

17. s2.2: So OCSP is definitely used a lot more than SCVP, but it is the 
other status protocol.  Should we just add it now?

18. s2.2: Need a normative reference for DER.  Use the x680/x690 
references from 5246.

19. s2.2: The nonce extension encoding is being fixed.  I sure hope 
it'll get done sooner rather than later.  Note that the bis draft does 
define the encoding as an OCTET STRING so it's aligned.

20. Hmmm should this draft reference draft-ietf-pkix-rfc2560bis instead 
of RFC 2560?

21. s2.2: r/[RFC2560]) ./[RFC2560]).

22. s2.2: r/that is,/That is,

23. s.2.2: Why the MUST NOT here:

  The list MAY
  contain fewer OCSP responses than there were certificates in the
  Certificate handshake message, but there MUST NOT be more responses
  than there were certificates in the list

spt

</no hat>

On 3/6/12 8:01 AM, Yngve N. Pettersen (Developer Opera Software ASA) wrote:
>
> FYI
>
> <http://www.ietf.org/id/draft-pettersen-tls-ext-multiple-ocsp-03.txt>
>
> ------- Forwarded message -------
> From: [e-mail]
> To: [e-mail]
> Cc:
> Subject: New Version Notification for
> draft-pettersen-tls-ext-multiple-ocsp-03.txt
> Date: Tue, 06 Mar 2012 13:49:50 +0100
>
> A new version of I-D, draft-pettersen-tls-ext-multiple-ocsp-03.txt has
> been successfully submitted by Yngve N. Pettersen and posted to the IETF
> repository.
>
> Filename: draft-pettersen-tls-ext-multiple-ocsp
> Revision: 03
> Title: Adding Multiple TLS Certificate Status Extension requests
> Creation date: 2012-03-06
> WG ID: Individual Submission
> Number of pages: 9
>
> Abstract:
> This document introduces a replacement of the TLS Certificate Status
> Extension to allow clients to specify and support multiple
> certificate status methods. Also being introduced is a new OCSP-
> based method that servers can use to provide status information not
> just about the server&#39;s own certificate, but also the status of
> intermediate certificates in the chain.
>
>
>
>
>
> The IETF Secretariat
>
>