RE: composition of Issuer identifier (also: "dns-date" URN NID)

[Phillip Hallam-Baker <pbaker@verisign.com>]

As far as identifiers go:

1) Allowing the optional use of a URI for anything that is potentially
downloadable means that if an application wants to provide that feature they
may.

Thus allowing URLs as one form of assertion ID makes a lot of sense.

2) Where issuer IDs are concerned the 'issuer' is clearly not 'downloadable'
but there might well be a need at some point to support some form of service
that was resolved in some fashion from the Issuer ID.

Here DNS names make a lot of sense since it is possible to map from a DNS
name to a service of any type using an SRV record. DNS names also have a
unique owner and there is a working consensus on a single name root so
ambiguity between DNS names does not arise the same way that it can with
X.400 names.

I think that at this point we can pretty much assume DNS infrastructure as a
given and ignore the claims of those who believe that X.500 is poised to
replace it imminently.

3) The DNS-DATE URN scheme has come up many times in many forms. The
earliest one in actual use being the Presidential Document Identifiers used
by the Whiethouse Publications service in 1992. The observation is that
ownership of a DNS name can be transfered. Therefore to 'fix' the semantics
of the name it is necessary to extend the name with the date. Where the name
relates to a message rather than an issuer it is necessary to have another
field to distinguish between messages issued on the same day, so we end up
with:

[URN-Prefix] : [DNS-NAME] : [Date] : [Serial]

A sinilar scheme may be found in implementations of the USENET system which
is represented in the URI scheme as news:<message-id>, we also specified a
msgid:<message-id> scheme at one time for mailing list messages (I can't
remember if it got through to the final RFC). For both schemes the spec only
requires that the message id contain the DNS name and the @ sign and that
the message ID not be reused within 2 years.

The intention of using a URN in the examples was simply to reinforce the
fact that as with USENET the identifier was not a 'locator' it was a
retrieval index.

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Jeff Hodges [mailto:jhodges@oblix.com]
> Sent: Tuesday, June 12, 2001 7:57 PM
> To: oasis sstc
> Subject: composition of Issuer identifier (also: "dns-date" URN NID)
> 
> 
> In..
> 
>   composition of AssertionID (Issue: DS-4-04: URIs for Assertion IDs) 
>   
> http://lists.oasis-open.org/archives/security-services/200106/
> msg00025.html
> 
> ..the composition of Issuer is punted.. 
> 
> > D2. some-issuer-identifier -- should this simply be a DNS 
> > fully-qualified-domain-name? Should it be a URN [6]? Should 
> it be something 
> > else?
> 
> Given some further thinking about it in..
> 
>   URIs as general-purpose identifiers, and identifiers in general 
>   
> http://lists.oasis-open.org/archives/security-services/200106/
> msg00074.html
> 
> ..it seems to me that simply using an otherwise unadorned, 
> "absolute" DNS
> domain name (see RFC1034; aka a "Fully-Qualified [DNS] Domain 
> Name", aka a
> "FQDN") will satisfy SAML's needs for identifying an Issuer. e.g...
> 
>   <Issuer>example.com</Issuer>
> 
> ..or even..
> 
>   <Issuer>securitydomain.in-house.example.com</Issuer>
> 
> ..or even..
> 
>   <Issuer>I.Issue.SAML.assertions.example.com</Issuer>
> 
> 
> 
> I note that in draft-sst-core-phill-07 and list discussions 
> thereof, Phill
> showing URNs used to identify Issuers, e.g...
> 
>   URN:dns-date:www.bizexchange.test:2001-01-03:19283
> 
> Note that this URN is pre-supposing a URN Namespace 
> Identifier (NID) of
> "dns-date", and is thus assuming that there is at least some 
> notion of the
> syntax and semantics of identifiers minted within that URN 
> namespace, and that
> it is written down somewhere. However, I haven't found any 
> such information in
> enqueued NID proposal docs, approved NID docs, or any of the 
> mailing lists I'm
> monitoring. 
> 
> If we were to use a URN-based identifier as-illustrated in
> draft-sst-core-phill-07 et al, we should either use an established URN
> namespace with documented syntax and semantics, or we would 
> have to create one
> and design & document & register it. For instance, in fully 
> examining the
> example URN above, one needs to know what the semantics of 
> the "date" portion
> are, and what those of the trailing "19283" numeric string are. 
> 
> By using simply an unadorned absolute DNS domain name we 
> avoid most of those
> issues, and entirely avoid the need to register anything 
> having to do with
> these identifiers. Now, deployers WILL be able to "play 
> games" with even DNS
> domain names as hinted at in the "<Issuer>" examples above. 
> And we will have to
> define nominally what it means when the DNS domain name isn't 
> dereferenceable
> (via the DNS of course), and when it (or some subportion thereof) is
> dereferenceable. 
> 
> It is worthwhile to note that others have been thinking about 
> the operational
> considerations of using DNS domain names (and URIs) as identifiers..
> 
> [18] Considerations for URI and FQDN Protocol Parameters
> http://www.ietf.org/internet-drafts/draft-eastlake-uri-fqdn-pa
ram-00.txt

..that doc has some guidance relevant to some of the above. 


JeffH

Phillip Hallam-Baker (E-mail).vcf