Authentication Context Certificate Extension
RFC 7773
Note: This ballot was opened for revision 11 and is now closed.
(Kathleen Moriarty) Yes
Comment (2015-11-17 for -11)
No email
send info
send info
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.
(Jari Arkko) No Objection
Comment (2015-11-19 for -11)
No email
send info
send info
Authors should probably note a couple of minor editorial issues that were raised by Jouni Korhonen in his Gen-ART review.
Deborah Brungard No Objection
(Ben Campbell) No Objection
(Benoît Claise) No Objection
Alissa Cooper No Objection
(Spencer Dawkins) No Objection
Comment (2015-11-16 for -11)
No email
send info
send info
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) No Objection
Comment (2015-11-16 for -11)
No email
send info
send info
- 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
(Brian Haberman) (was Discuss) No Objection
Comment (2015-11-18 for -11)
No email
send info
send info
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).
(Joel Jaeggli) No Objection
Comment (2015-11-18 for -11)
No email
send info
send info
Eric Vynke performed the opsdir review.
Barry Leiba No Objection
Comment (2015-11-18 for -11)
No email
send info
send info
-- 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?