Last Call Review of draft-santesson-auth-context-extension-09
review-santesson-auth-context-extension-09-opsdir-lc-vyncke-2015-11-10-00

Request Review of draft-santesson-auth-context-extension
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-11-17
Requested 2015-10-09
Authors Stefan Santesson
Draft last updated 2015-11-10
Completed reviews Genart Last Call review of -09 by Jouni Korhonen (diff)
Genart Last Call review of -11 by Jouni Korhonen (diff)
Secdir Last Call review of -09 by Matthew Miller (diff)
Opsdir Last Call review of -09 by Éric Vyncke (diff)
Opsdir Telechat review of -11 by Éric Vyncke (diff)
Assignment Reviewer Éric Vyncke 
State Completed
Review review-santesson-auth-context-extension-09-opsdir-lc-vyncke-2015-11-10
Reviewed rev. 09 (document currently at 12)
Review result Has Issues
Review completed: 2015-11-10

Review
review-santesson-auth-context-extension-09-opsdir-lc-vyncke-2015-11-10






Hi, OPS-DIR, Stefan,










I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects
 of the IETF drafts.













Section 1.2 (deployment) is helpful to exhibit a real world deployment, nice to keep.










Section 2, mixing XML (as proposed by this I-D) and ASN.1 (per X.509 certificates) force all implementations to support both XML and ASN.1 syntaxes. This complicates deployments. Moreover this could also inflate the size
 of certificates and potentially add one round-trip when doing a TLS exchange. Section 3.1.2 even goes further in complication by explaining that OID must be expressed as strings in the XML.










Section 2, marking the extension as critical should state that this is wrt to RFC 5280. And, the extension is either critical or not: saying 'MAY be marked as critical' is ambiguous.










Section 3.1.1 makes a reference to section 3.3 which is not in the document.










Section 3.1.1 talks about time but without mentioning whether it is UTC.










It is also unclear from my reading of the I-D whether the content of the certificate can be traced back to a specific SAML operation (for debugging/auditing for example).










I was also unable to find information about the other certificate attributes when used with this extension (for example which value for validity period or for the CRL). This comment applies more to the use case than on the
 specific proposed extension; in the same vein, the enrollment process should probably be described.










I would welcome a few words about the scalability (notably in terms of GUI or local secure storage) when this system is used to get X.509 certificates from several identity providers for which the subject can have multiple
 identities.










Nits: a lot of missing '.' at end of sentences or some 's' at the end of some verbs :-)










Hope this helps










-éric