Authentication Context Certificate Extension
draft-santesson-auth-context-extension-12

[Ballot comment]
-- Section 3.1.1 --

  The  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?

[Ballot comment]
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).

[Ballot discuss]
Is this document intended to be Standards Track or Informational?  The ballot says ST, but the document header says "Intended Status: Informational". The IETF Last Call message indicates Standards Track, so I think the header is wrong.

[Ballot comment]

- 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

[Ballot comment]
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?

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) This is an individual submission as a proposed standards as it
has seen reasonably wide implementation and deployment although
currently limited to a single market.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document defines an extension to certificates according to
  [RFC5280]. The extension defined in this document holds data about
  how the certificate subject was authenticated by the Certification
  Authority who issued the certificate where this extension appears.

  This document also defines one data structure for inclusion in this
  extension that designed to hold information when the subject is
  authenticated using a SAML assertion [SAML].

Working Group Summary

  The PKIX working group is closed.

Document Quality

  The document has been reviewed by the implementors of the Swedish
  eID (goverment to citizen identity services) signing service. There
  are currently at least 3 fully interoperable implementations
  suggesting the specification has been well reviewed.

  An ASN.1 Syntax verification is requested by the document shepherd.

Personnel

  Shepherd: Leif Johansson
  Responsible Area Director: Kathleen Moriarty
 

(3) The shepherd reviewed the draft, providing recommendations that have
been address in the version used for IETF last call.  References and IDnits
fixes were recommended.  Content and security considerations were reviewed.
An ASN.1 syntax check was not preformed, but was requested by the shepherd.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?  No.

(5) Do portions of the document need review?

A ASN.1 syntax review is requested.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

no

(7) The shepherd has confirmed with the author that there are no IPR
issues and the draft boilerplate claims full conformance with BCP 78
and BCP 79.

(8) The shepherd has confirmed with the author that there are no IPR
issues.

(9) The document has been reviewed by the implementors of the Swedish
eID (goverment to citizen identity services) signing service. There
are currently at least 3 fully interoperable implementations
suggesting the specification has been well reviewed.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  No.

(11) IDnits have been addressed from the shepherd review against
version -07.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

ASN.1 syntax review is requested.

(13) Have all references within this document been identified as
either normative or informative? Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.  None.

(16) Will publication of this document change the status of any existing
RFCs? No.

(17) Describe the Document Shepherd's review of the IANA considerations
section.  There are no IANA considerations.

(18) There are no IANA considerations.

(19) IDnits were verified and references have been updated from the -07 draft.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-santesson-auth-context-extension-09, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Authentication Context Certificate Extension) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Authentication Context Certificate Extension'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-10-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines an extension to certificates according to
  [RFC5280]. The extension defined in this document holds data about
  how the certificate subject was authenticated by the Certification
  Authority that issued the certificate in which this extension appears

  This document also defines one data structure for inclusion in this
  Extension. The data structure is designed to hold information when
  the subject is authenticated using a SAML assertion [SAML].




The file can be obtained via
https://datatracker.ietf.org/doc/draft-santesson-auth-context-extension/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-santesson-auth-context-extension/ballot/


No IPR declarations have been submitted directly on this I-D.

Note: The editorial comments in the shepherd report have been addressed.  These will be removed/updated in a future version of the shepherd report, but I didn't want to hold up processing of this draft any further.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) This is an individual submission as a proposed standards as it
has seen reasonably wide implementation and deployment although
currently limited to a single market.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document defines an extension to certificates according to
  [RFC5280]. The extension defined in this document holds data about
  how the certificate subject was authenticated by the Certification
  Authority who issued the certificate where this extension appears.

  This document also defines one data structure for inclusion in this
  extension that designed to hold information when the subject is
  authenticated using a SAML assertion [SAML].

Working Group Summary

  The PKIX working group is closed.

Document Quality

  The document has been reviewed by the implementors of the Swedish
  eID (goverment to citizen identity services) signing service. There
  are currently at least 3 fully interoperable implementations
  suggesting the specification has been well reviewed.

  An ASN.1 Syntax verification is requested by the document shepherd.

Personnel

  Shepherd: Leif Johansson
  Responsible Area Director: Kathleen Moriarty
 

(3) The shepherd reviewed the draft, providing recommendations that have
been address in the version used for IETF last call.  References and IDnits
fixes were recommended.  Content and security considerations were reviewed.
An ASN.1 syntax check was not preformed, but was requested by the shepherd.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?  No.

(5) Do portions of the document need review?

An ASN.1 syntax review is requested.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

  The document is short and relatively straightforward. The author tends
  to overuse the words "this" and "that" which makes it a little hard to
  follow some of the text but not critically so.

  The author suggests removal of section 1.2 but I think that if made
  a bit shorter and cleaned up it serves as a good motivation for the
  choices in the spec.

(7) The shepherd has confirmed with the author that there are no IPR
issues and the draft boilerplate claims full conformance with BCP 78
and BCP 79.

(8) The shepherd has confirmed with the author that there are no IPR
issues.

(9) The document has been reviewed by the implementors of the Swedish
eID (goverment to citizen identity services) signing service. There
are currently at least 3 fully interoperable implementations
suggesting the specification has been well reviewed.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  No.

(11) IDnits have been addressed from the shepherd review against
version -07.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

ASN.1 syntax review is requested.

(13) Have all references within this document been identified as
either normative or informative? Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.  None.

(16) Will publication of this document change the status of any existing
RFCs? No.

(17) Describe the Document Shepherd's review of the IANA considerations
section.  There are no IANA considerations.

(18) There are no IANA considerations.

(19) IDnits were verified and references have been updated from the -07 draft.


--- Additional readability/grammar review

Introduction:

- s/understand information/obtain information/
- s/This addresses some needs that may arise/The motivation for this work is .../ (rewrite to match)
- s/in exchange of a certificate/in exchange for a certificate/ (but consider rewriting to split up the long sentenc)
- s/traced back to that subjects SAML assertion, both with regard to
  identity attributes and with regard to level of assurance with which
  the subject was authenticated by its Identity Provider./uniquely linked to information provided in the original SAML assertion - eg attriutes and/or level of assurance indicators/

- s/A reason to issue such certificate.../Such certificates are sometimes issued in order to provide the user with a means to create an electronic signature that ties the user to the SAML subject, its attributes and level of assurance indicators/

s/If that signature certificate needs to /If such a certificate needs to.../
- s/This is only possible today/Today this is only possible/
- s/This is however hard to scale and maintain using a/However, this approach does not scale to a/

2. Authentication Context Extension Syntax

Suggest drop first paragraph as redundant

s/is used mainly to allow/is mainly used to allow/

Look for "name form" and suggest replacing it with nameform since it is a SAML term of art - but I suggest getting outside review (ask Scott) about this.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) This is an individual submission as a proposed standards as it
has seen reasonably wide implementation and deployment although
currently limited to a single market.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document defines an extension to certificates according to
  [RFC5280]. The extension defined in this document holds data about
  how the certificate subject was authenticated by the Certification
  Authority who issued the certificate where this extension appears.

  This document also defines one data structure for inclusion in this
  extension that designed to hold information when the subject is
  authenticated using a SAML assertion [SAML].

Working Group Summary

  The PKIX working group is closed.

Document Quality

  The document has been reviewed by the implementors of the Swedish
  eID (goverment to citizen identity services) signing service. There
  are currently at least 3 fully interoperable implementations
  suggesting the specification has been well reviewed.

  An ASN.1 Syntax verification is requested by the document shepherd.

Personnel

  Shepherd: Leif Johansson
  Responsible Area Director: Kathleen Moriarty
 

(3) The shepherd reviewed the draft, providing recommendations that have
been address in the version used for IETF last call.  References and IDnits
fixes were recommended.  Content and security considerations were reviewed.
An ASN.1 syntax check was not preformed, but was requested by the shepherd.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?  No.

(5) Do portions of the document need review?

An ASN.1 syntax review is requested.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

  The document is short and relatively straightforward. The author tends
  to overuse the words "this" and "that" which makes it a little hard to
  follow some of the text but not critically so.

  The author suggests removal of section 1.2 but I think that if made
  a bit shorter and cleaned up it serves as a good motivation for the
  choices in the spec.

(7) The shepherd has confirmed with the author that there are no IPR
issues and the draft boilerplate claims full conformance with BCP 78
and BCP 79.

(8) The shepherd has confirmed with the author that there are no IPR
issues.

(9) The document has been reviewed by the implementors of the Swedish
eID (goverment to citizen identity services) signing service. There
are currently at least 3 fully interoperable implementations
suggesting the specification has been well reviewed.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  No.

(11) IDnits have been addressed from the shepherd review against
version -07.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

ASN.1 syntax review is requested.

(13) Have all references within this document been identified as
either normative or informative? Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.  None.

(16) Will publication of this document change the status of any existing
RFCs? No.

(17) Describe the Document Shepherd's review of the IANA considerations
section.  There are no IANA considerations.

(18) There are no IANA considerations.

(19) IDnits were verified and references have been updated from the -07 draft.