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
The following comments from Russ Housley on the IETF list need to be resolved:

Russ did compile the ASN.1 modules.

(Jari Arkko) No Objection

Comment (2015-11-19 for -11)
No email
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
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
- 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.


(Brian Haberman) (was Discuss) No Objection

Comment (2015-11-18 for -11)
No email
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
Eric Vynke performed the opsdir review.

Barry Leiba No Objection

Comment (2015-11-18 for -11)
No email
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. "". 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?

(Terry Manderson) No Objection

Alvaro Retana No Objection