Skip to main content

Last Call Review of draft-santesson-auth-context-extension-09

Request Review of draft-santesson-auth-context-extension
Requested revision 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
I-D 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 A. 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
Request Last Call review on draft-santesson-auth-context-extension by Ops Directorate Assigned
Reviewed revision 09 (document currently at 12)
Result Has issues
Completed 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

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

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

Hope this helps