Re: [apps-discuss] The authentication server id, was rfc5451bis

["Murray S. Kucherawy" <[e-mail]>]

On Mon, Mar 25, 2013 at 5:19 AM, Alessandro Vesely <[e-mail]> wrote:

> On Sun 24/Mar/2013 22:06:41 +0100 Murray S. Kucherawy wrote:
> > I'm not in favour of changing to a grammar that matches current use to
> > the exclusion of other uses without a good reason to do so.  Since in
> > the prose we talk about authserv-id being a domain name in the typical
> > case but basically also say it could be anything the operator wants to
> > use, I think "value" is the right thing there.
>
> Besides the parsability point (quotes), the intended use of this piece
> of data is rather overloaded.  Let me recap some requirements:
>
> 1. Identification of the ADMD for assessing trust relationships
>    (and possibly also for POP3 MUAs to send back complaints,
>    per Section 5.3 of RFC 6650),
>

I don't see a reference to this work there.


> 2. uniqueness of the identifier,
>

This is key for identifying your own, but it doesn't speak to a necessary
syntax.


> 3. similar in syntax to a fully-qualified domain name,
>

There's nothing saying an ADMD can't use a simple word or even a single
punctuation here (so long as it fits the grammar).  Ideally it's most
useful when it's in this form, but an ADMD could use "---" as an
authserv-id and still get results useful to it.  A complete sentence would
also be valid.

I can't think of a good reason to restrict this to look like a domain name
if it doesn't actually represent a single DNS domain entity.  One ADMD
could be doing authentication service for lots of domains, but it's still
one ADMD.  If I run a service that does email authentication for tons of
domains, why could I not use "Murray's Authentication Service" for an
authserv-id?  Or even the empty string?  As long as the producer and
consumer are consistent in their uses of it, all of your stated
requirements are met.


> 4. transport tracing data such as the SMTP queue ID or a timestamp
>    (semantic hints would also go here, e.g. "all signatures checked
>    but failures not reported" vs "checking stops on first success"),
>

This also doesn't appear to me to demand a specific format (as above).


> 5. version identification,
>

That's not part of the authserv-id itself.


> 6. examples of valid authentication identifiers are "example.com",
>    "mail.example.org", "ms1.newyork.example.com", and "example-auth".
>

The last string in that list is not what most people think of as a
fully-qualified domain name, but as you point out, it's perfectly
acceptable.


>
> Bullets #3 and #6 are compatible with "domain-name".  By using domain
> names in the traditional ways, even though they are not required to be
> in the DNS, operators can easily implement #1 and #2.  Conversely,
> we'd need production rules to parse a "domain-name" inside the rest of
> the "value" if the grammar were relaxed that way.
>
> Alternatively, we can meet #4 and #5 by relaxing or extending the
> "version".  For example:
>
>      authres-header = "Authentication-Results:" [CFWS] authserv-id
>               [ [CFWS] separator [CFWS] ex-version ]
>               ( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF
>
>      authserv-id = domain-name
>
>      artext  = ALPHA / DIGIT /  ; RFC 5322 atext without "="
>                "-" / "_" /
>                separator
>
>      separator =  "!" / "#" /   ; dot-atom characters that cannot
>                   "$" / "%" /   ; be part of a domain-name
>                   "&" / "'" /
>                   "*" / "+" /
>                       / "/" /
>                         "?" /
>                   "^" /
>                   "`" / "{" /
>                   "|" / "}" /
>                   "~"
>
>      ar-dot-text = 1*artext *("." 1*artext)
>
>      ex-version = [CFWS] ar-dot-text [CFWS]
>

I think we're wandering off into some bikeshedding here.  I'm curious to
know if anyone else supports this more complicated notion.  I certainly
don't agree with making the "separator" be anything other than "/".

The overall grammar is pretty clean right now: break on unescaped
semicolons and you get paragraphs of useful information; the first
paragraph is the authserv-id stuff, and everything else is "method=result"
followed by relevant method parameters; any unescaped "/" followed by a
number is a version.  Is there a reason to complicate that?

Semantically, allowing "anything the operator wants to use" conflicts
> with the requirement that a parser explicitly knows it, in the new
> Section 2.4.  IMHO, unrecognized ex-versions could just be ignored, as
> the format is determined by the field name.
>

How does it conflict?

-MSK