Last Call Review of draft-ietf-tls-multiple-cert-status-extension-04
review-ietf-tls-multiple-cert-status-extension-04-genart-lc-davies-2013-03-22-00

  
  
    I am the assigned Gen-ART reviewer for this draft. For background on
    


    Gen-ART, please see the FAQ at
    







<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

.
    





    Please resolve these comments along with any other Last Call
    comments
    


    you may receive.
    





    Document: draft-ietf-tls-multiple-cert-status-extension-04.txt
    


    Reviewer:
    Elwyn Davies


    Review Date: 22 March 2013
    


    IETF LC End Date:
    29 March 2013


    IESG Telechat date: (if known)
    -





    Summary:
    Almost ready for IESG - one possible minor issue relating to the
    alleged criterion for ordering CertificateStatusRequestItems plus a
    number of nits that are mainly missing cross references and notes
    for clarity about updates of RFC 6066 items. 





    Major issues:
    


    None





    Minor issues:
    


    s2.2:







   The list of CertificateStatusRequestItem entries MUST be in order of
   preference.






    Having thought a bit about this, I cannot identify what the
    preference criterion is - this may be because I don't understand the
    problem, but I think you need to explain what the criterion is if
    there really is one.  If there *is* a criterion, it must be clear
    whether the order is most preferred first or least preferred first. 
    Since I don't know what the criterion is, I can't tell if there are
    any security implications from the ordering: no chance of downgrade
    attacks?





    Nits/editorial comments:
    


    s2:


    The presentation format used should be referenced back to s4 of RFC
    5246.





    s2.1:


    A reference to s1.1 of RFC 6066 where extension_type is defined is
    needed, and it should be made more clear that this an expansion of
    the existing type.  





    s2.2:


    A reference to s7.4.1.4 of RFC 5246 where extension_data is defined
    is needed.





    s2.2, page 4:


    Might be good to be more explicit that the definition of
    CertificateStatusRequest is an extension of the definition in RFC
    6066.  Also the definition of OSCPStatusRequest duplicates the one
    in RFC 6066 and should be noted as such.  It would also be more
    appropriate if it came before CertificateStatusRequest as it is used
    in CertificateStatusRequest. 





    s2.2, para 4 on page 5:







   In the case of the "id-pkix-ocsp-nonce" OCSP extension, [

RFC2560

] is
   unclear about its encoding; for clarification,..... 





    This probably needs to be flagged up in the IANA considerations so
    that an additional reference is added to the registry.


    ALSO I subsequently noted that this same caveat is already in RFC
    6066.  Consider referring to the caveat there rather than
    duplicating it.





    s2.2, para 5 on page 5:


    s/A server that receive a client hello/A server that receives a
    client hello/





    s2.2, page 5/6:


    Might be good to be more explicit that the definition of
    CertificateStatus is an extension of the definition in RFC 6066.


    Also the definition of OSCPResponse duplicates the one in RFC 6066
    and should be noted as such.  It would also be more appropriate if
    it came before CertificateStatus as it is used in CertificateStatus.
    





    s2.2, page 6:


    The definition of OCSPResponseList should come before the
    redefinition of CertificateStatus as it is used in
    CertificateStatus.





    s2.2, para 2 after structure definitions on page 6:


    A reference to s7.4.2 of RFC 5246 for the Certificate list would be
    helpful.