On Feb 2, 2009, at 4:01 PM, Siegel, Ellen wrote:
3. Section 2.8 Signing Domain Identifier (SDID)
Original Text: (None. Additional text.)
Corrected Text: A single, opaque value that is the mandatory
payload output of DKIM and which refers to the identity claiming
responsibility for the introduction of a message into the mail
stream.
'---
Although the i= (UAID) value can be opaque in respect to the actual
identity being referenced, the signing domain d= (SDID) is not
opaque. A domain that returns valid keys should not be considered
opaque.
[> ]
I think what is intended by "opaque" in this context is that it
should be opaque to the Identity Assessor, i.e. it should be treated
as an opaque identifier and no knowledge about DNS domain structure
should be applied.
Ellen,
An identity need not be in the form of an email-address. When i=
0123456789(_at_)random(_dot_)ietf(_dot_)org
and d=ietf.org, there is a stark difference between the opacity of
i= and d= values.
A domain within the d= parameter is always transparent. It tells a
great deal about who owns it, even for domains without whois
information.
For example, when one does a whois on ietf.org you'll get:
Domain ID:D36473-LROR
Domain Name:IETF.ORG
Created On:11-Mar-1995 05:00:00 UTC
Last Updated On:14-May-2008 22:29:36 UTC
Expiration Date:12-Mar-2011 05:00:00 UTC
Sponsoring Registrar:Network Solutions LLC (R63-LROR)
Status:CLIENT TRANSFER PROHIBITED
Registrant ID:40362704-NSI
Registrant Name:IETF Trust
Registrant Organization:IETF Trust
Registrant Street1:1775 Wiehle Ave
Registrant City:Reston
Registrant State/Province:VA
Registrant Postal Code:20190
Registrant Country:US
Registrant Phone:+1.7037289264
Registrant Email:no(_dot_)valid(_dot_)email(_at_)worldnic(_dot_)com
Admin ID:40362705-NSI
Admin Name:Ray Pelletier
Admin Organization:IETF Trust
Admin Street1:1775 Wiehle Ave
Admin Street2:
Admin Street3:
Admin City:Reston
Admin State/Province:VA
Admin Postal Code:20190
Admin Country:US
Admin Phone:+1.7037289264
Admin FAX:+1.7037797463
Admin Email:rpelletier(_at_)isoc(_dot_)org
Tech ID:40362705-NSI
Tech Name:Ray Pelletier
Tech Organization:IETF Trust
Tech Street1:1775 Wiehle Ave
Tech City:Reston
Tech State/Province:VA
Tech Postal Code:20190
Tech Country:US
Tech Phone:+1.7037289264
Tech FAX:+1.7037797463
Tech Email:rpelletier(_at_)isoc(_dot_)org
Name Server:NS1.AMS1.AFILIAS-NST.INFO
Name Server:NS1.MIA1.AFILIAS-NST.INFO
Name Server:NS1.SEA1.AFILIAS-NST.INFO
Name Server:NS1.YYZ1.AFILIAS-NST.INFO
Name Server:NS1.HKG1.AFILIAS-NST.INFO
Name Server:NS0.IETF.ORG
One might inquire about this domain's name servers, and the IP
addresses used by the name servers to further determine more about
this fairly transparent identity that indicates who provides name and
routing services.
However, whois for random.ietf.org returns NOT FOUND, returns no name
server, and provides no associated IP addresses, although
0123456789(_at_)random(_dot_)ietf(_dot_)org
represents a legal value for the i= parameter. NOT FOUND, no name
server, and no associated IP addresses is not be a valid result for
the d= value.
For example, if the SDID was subdomain.example.com, the Identity
Assessor should not make any use of the fact that example.com is the
parent domain of the SDID, it should just treat the whole domain
name as an (opaque) identifier string.
Being able to access public keys based upon a domain confirms
ownership hierarchy and indicates both the existence and the
involvement of a supporting name server. A name server for a domain
transparently indicates ownership hierarchy. On the other hand,
0123456789(_at_)random(_dot_)ietf(_dot_)org
may not relate to any specific identity or name server whatsoever,
and yet this is completely valid for RFC 4871. As such, the i= value
might be considered opaque, but the d= value should not.
Obviously it's not opaque to the verifier in that it's necessary to
look up the keys... but the opaque label is attached to the output
of the verifier, not its input.
Why would one wish to attach a label of opaque to ietf.org in the
example given? How does the use of opaque in the case of the d=
value add clarity to RFC 4871? For an identity to be transparent, it
does not need to be in the form of an email-address. An identify is
made transparent when supported by a name server verified as being
associated with the message. How could the identity be any more
transparent?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html