Authentication Context Certificate Extension
RFC 7773
Yes
No Objection
(Alissa Cooper)
(Alvaro Retana)
(Ben Campbell)
(Benoît Claise)
(Deborah Brungard)
(Terry Manderson)
Note: This ballot was opened for revision 11 and is now closed.
Kathleen Moriarty Former IESG member
Yes
Yes
(2015-11-17 for -11)
Unknown
The following comments from Russ Housley on the IETF list need to be resolved: https://mailarchive.ietf.org/arch/msg/ietf/XZqjGmjPokiMdzG2xI3G60Av56w Russ did compile the ASN.1 modules.
Alissa Cooper Former IESG member
No Objection
No Objection
(for -11)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -11)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2015-11-18 for -11)
Unknown
-- Section 3.1.1 -- The <AuthContextInfo> element may hold any number of child elements of type any (processContents="lax"), providing additional information according to local conventions. Any such elements MAY be ignored if not understood. What else can be done with such elements that are not understood, other than to ignore them? That is, why is it "MAY be", rather than, say, "are"? (The same question applies to Section 3.1.2.) -- Section 3.1.2 -- String representations of object identifiers (OID) in the Ref attribute MUST be represented by a sequence of integers separated by a period. E.g. "2.5.4.32". This string MUST NOT contain any white-space or line breaks. That's a very limited MUST not, and it doesn't say what other characters can appear in the string. Is it actually the case that "This string contains only numerals (ASCII 0x30 to 0x39) and periods (ASCII 0x2E), and MUST NOT contain any other characters." ? If so, wouldn't it be better to say it that way?
Ben Campbell Former IESG member
No Objection
No Objection
(for -11)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -11)
Unknown
Brian Haberman Former IESG member
(was Discuss)
No Objection
No Objection
(2015-11-18 for -11)
Unknown
I was notified that Kathleen has the status issue well in hand, so I am removing my DISCUSS on that point. I tend to agree with Stephen's point about the usefulness of this as a standard (if it is supposed to be ST).
Deborah Brungard Former IESG member
No Objection
No Objection
(for -11)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2015-11-19 for -11)
Unknown
Authors should probably note a couple of minor editorial issues that were raised by Jouni Korhonen in his Gen-ART review.
Joel Jaeggli Former IESG member
No Objection
No Objection
(2015-11-18 for -11)
Unknown
Eric Vynke performed the opsdir review.
Spencer Dawkins Former IESG member
No Objection
No Objection
(2015-11-16 for -11)
Unknown
Just as a nit, this document uses "certificate" with no qualification. Most of the documents in the references say "X.509 certificates". Is "certificate" sufficiently disambiguated with no qualifiers?
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-11-16 for -11)
Unknown
- This is not the kind of thing that is particularly useful, as (IMO) it's over generalised and will not be supported widely. I think you'd have been better off simply saying what you have done in the Swedish eID system. (Mind you, I also think that's over complex too;-) However, I've no objection to this as I guess it's a little useful to your eID project, and not harmful elsewhere. (It'd be better though if you said that you didn't claim that this is highly scalable etc.) - I think this'd be better if you said the extension MUST be critical. That'd eliminate the (real, but not huge) concern that the code for all this (being mostly unused) could be harmful. Not a huge deal though. - "A unique reference to the authentication instant" Huh? What's that mean? - "The extension defined here provides better scalability..." I don't buy that fwiw. One needs the code to intepret all these (overly) abstract data structures. - p8, "This string MUST NOT contain any white-space or line breaks." I have no idea why that MUST NOT is needed given how much other fluff can be in XML string encodings. - p9, "Any such elements MAY be ignored if not understood." Huh? If I don't understand what else can I do but igore? - I think it'd be useful to say that implementations really ought not decode then re-encode all this stuff as there are too many way to get that wrong. (If you tell me that's considered obvious nowadays, I'm fine with that.) - The secdir review [1] makes some points similar to those above. I think that deserves a response, even if I don't consider those points require a DISCUSS ballot. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06124.html
Terry Manderson Former IESG member
No Objection
No Objection
(for -11)
Unknown