Hi, the proposed changes seemed fine at least to me.
P.S. Sorry, got back from holidays this week. On 08/05/2016 03:42 AM, Julien Laganier wrote:
Hi Stephen, FYI I've implemented the proposed change in the last draft revision. Best, --julien On Thu, Jul 21, 2016 at 4:22 AM, Stephen Farrell <[email protected]> wrote:Hiya, That'd be fine for clearing my discuss. I'd encourage you to also get feedback from the WG though as I don't think I've ever seen a list of cert handling errors that was correct first time around:-) Cheers, S. On 20/07/16 16:11, Julien Laganier wrote:Hi Stephen, Thanks for reviewing the document. I think there would be value in making the cause of certificate error explicit. Would the following change be acceptable? OLD: If the certificate in the parameter is not accepted, the registrar MUST reject the corresponding registrations with Failure Type [IANA TBD] (Invalid certificate). NEW: If the certificate in the parameter is not accepted, the registrar MUST reject the corresponding registrations with the appropriate Failure Type: [IANA TBD] (Bad certificate): The certificate is corrupt, contains invalid signatures, etc. [IANA TBD] (Unsupported certificate): The certificate is of an unsupported type. [IANA TBD] (Certificate expired): The certificate is no longer valid. [IANA TBD] (Certificate other): The certificate could not be validated for some unspecified reason. [IANA TBD] (Unknown CA): The issuing CA certificate could not be located or is not trusted. Please let us know. Best, --julien On Tue, Jul 5, 2016 at 7:01 AM, Stephen Farrell <[email protected]> wrote:Stephen Farrell has entered the following ballot position for draft-ietf-hip-rfc5203-bis-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 3.3 - This fails to distinguish between an invalid certificate (e.g. bad signature, unknown signer) and one that is valid, but is not acceptable for this purpose. I don't get why that is ok for HIP, can you explain? If it is ok, I think you need to say so. If it is not ok (as I'd suspect) then you appear to need to change text or one more new error code. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 7 - I'm fine that this doesn't repeat stuff from 5203, but a sentence saying to go look there too would maybe be good. (I'm not sure if that would fix Alexey's discuss or not. If not, then ignore me and just talk to him about his discuss.)_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
