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= [email protected] 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:[email protected] 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:[email protected] 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:[email protected] 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 [email protected] 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, [email protected] 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
