Id Resolution Observations and Suggestions

[Chad La Joie <la...@itumi.biz>]

So, last night I spent some time digging in to the new code and
discussing with some things with Scott.  Here's where we ended up.

The IdResolver is not designed in a manner that would allow alternative
implementations to be used.  Though, given that it is only used by the
ResourceResolver implementations, those could be replaced by the user of
the library

The new code does use the Document.getElementById method to look up IDs
in the general case.  This may be overridden by explicitly placing
ID-to-Element mappings into the IdResolver, but since doing this is
neither documented nor shown in the examples it is fairly safe to assume
this isn't happening out in the wild.

Given the above, this code does not guard against any issues that may
arise from duplicate IDs.

In the case of signatures, there seems to be nothing that a library can
do in order to ensure that the "right thing" is covered by the signature
since the "right thing" is use-case specific.

In the case of encryption, there is no way for the application to know
whether the dereferenced encrypted encryption key is what the document
author actually intended.  If it's not, however, the worst that would
happen is that encrypted data would not decrypt.

Given this, I believe the following things should be done:
- The use of Document.getElementById and the potential issue caused by
the lack of a strong guarantee on ID uniqueness should be documented.
- The documentation for XMLSignature and all the examples should be
updated to make it clear that the user of the library needs to check
that what they thought was covered by the signature actually was.
- Attempting to update the examples in this way will make it clear that
better APIs need to be provided to expose the content indicated by
<Reference>s.

In addition, given the manner in which the IdResolver currently works, I
believe it could be done away with entirely. The
IdResolver.registerElementById method could simply be replaced by the
appropriate Element.setIdAttribute* method.  Doing so would remove a
potentially large in-memory data structure as well as various
synchronization points that currently prevent concurrent ID resolutions.

-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered

Re: Id Resolution Observations and Suggestions

[Chad La Joie <la...@itumi.biz>]

I also think it's useful if you think that something funny might be
going on.  You could turn on these additional set of checks, take a
bit of a performance hit, and potentially become aware of some
app/partner doing something wrong or questionable.

On Mon, Jan 9, 2012 at 12:55, Cantor, Scott <ca...@osu.edu> wrote:
> What this is for (to me) is getting around the lack of reference caching.
> If that exists, you don't need it, you just compare the cached reference
> node to what you expect. But today, that caching is not widely available
> (e.g. not available in the old API, or in C++).



-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered

Re: Id Resolution Observations and Suggestions

[Chad La Joie <la...@itumi.biz>]

Right, when you check the tree you want to check with *exactly* the
same logic as you're using for resolution.  So, in the case of
getElementById you want to *only* check those attributes where
Attr.isId() == true.  Otherwise the check is mostly meaningless.

On Mon, Jan 9, 2012 at 11:31, Colm O hEigeartaigh <co...@apache.org> wrote:
> Hi Scott,
>
>> No, they just have to register it with the DOM ahead of time. Your id
>> resolution itself will not even find that attribute unless it's registered
>> with the DOM, based on what you posted.
>
> Ok, so if I'm understanding you correctly, the purpose of the tree
> search is to ensure that no two Elements are registered by the same Id
> and so there is no ambiguity about what Document.getElementById()
> returns. But it does not guard against the fact that there could be
> two Elements in the document tree with the exact same Id, where one is
> registered as an Id and the other isn't. Is this correct?
>
> Colm.
>
> On Mon, Jan 9, 2012 at 4:01 PM, Cantor, Scott <ca...@osu.edu> wrote:
>> On 1/9/12 10:47 AM, "Colm O hEigeartaigh" <co...@apache.org> wrote:
>>>
>>>The problem is that it does not take account of IDs in other
>>>namespaces, for example xmlns:wsu. If the user wants to support IDs in
>>>other namespaces then he/she has to do their own tree-search.
>>
>> No, they just have to register it with the DOM ahead of time. Your id
>> resolution itself will not even find that attribute unless it's registered
>> with the DOM, based on what you posted.
>>
>>> IMO we should also be checking the wsu namespace, as well as the SAML
>>>AssertionID/ID attributes, by default, as this gives better default
>>>protection against wrapping attacks.
>>
>> You can special case 2 or 3 or 5 things, but you're still left with the
>> same problem.
>>
>>>Note that we don't actually support retrieving References by this
>>>search, just checking for duplicates. So it's still up to the user to
>>>find the elements that are signed so that they can be retrieved via
>>>Document.getElementById().
>>
>> What matters is what gets resolved. There's no sense checking for
>> duplicates except using the same set of IDs that will be subject to
>> resolution.
>>
>> -- Scott
>>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com



-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered

Re: Id Resolution Observations and Suggestions

["Cantor, Scott" <ca...@osu.edu>]

On 1/9/12 11:31 AM, "Colm O hEigeartaigh" <co...@apache.org> wrote:
>
>Ok, so if I'm understanding you correctly, the purpose of the tree
>search is to ensure that no two Elements are registered by the same Id
>and so there is no ambiguity about what Document.getElementById()
>returns. But it does not guard against the fact that there could be
>two Elements in the document tree with the exact same Id, where one is
>registered as an Id and the other isn't. Is this correct?

Yes, because it allows the application to know that *it* knows what
getElementById will return to both it and the library. If there are
duplicates, then the result being undefined, you can't assume anything
about what was returned to each part independently. If there are no
duplicates, then you do know, provided nothing changes the DOM in between
in this area.

What this is for (to me) is getting around the lack of reference caching.
If that exists, you don't need it, you just compare the cached reference
node to what you expect. But today, that caching is not widely available
(e.g. not available in the old API, or in C++).

-- Scott

Re: Id Resolution Observations and Suggestions

[Colm O hEigeartaigh <co...@apache.org>]

Hi Scott,

> No, they just have to register it with the DOM ahead of time. Your id
> resolution itself will not even find that attribute unless it's registered
> with the DOM, based on what you posted.

Ok, so if I'm understanding you correctly, the purpose of the tree
search is to ensure that no two Elements are registered by the same Id
and so there is no ambiguity about what Document.getElementById()
returns. But it does not guard against the fact that there could be
two Elements in the document tree with the exact same Id, where one is
registered as an Id and the other isn't. Is this correct?

Colm.

On Mon, Jan 9, 2012 at 4:01 PM, Cantor, Scott <ca...@osu.edu> wrote:
> On 1/9/12 10:47 AM, "Colm O hEigeartaigh" <co...@apache.org> wrote:
>>
>>The problem is that it does not take account of IDs in other
>>namespaces, for example xmlns:wsu. If the user wants to support IDs in
>>other namespaces then he/she has to do their own tree-search.
>
> No, they just have to register it with the DOM ahead of time. Your id
> resolution itself will not even find that attribute unless it's registered
> with the DOM, based on what you posted.
>
>> IMO we should also be checking the wsu namespace, as well as the SAML
>>AssertionID/ID attributes, by default, as this gives better default
>>protection against wrapping attacks.
>
> You can special case 2 or 3 or 5 things, but you're still left with the
> same problem.
>
>>Note that we don't actually support retrieving References by this
>>search, just checking for duplicates. So it's still up to the user to
>>find the elements that are signed so that they can be retrieved via
>>Document.getElementById().
>
> What matters is what gets resolved. There's no sense checking for
> duplicates except using the same set of IDs that will be subject to
> resolution.
>
> -- Scott
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Id Resolution Observations and Suggestions

["Cantor, Scott" <ca...@osu.edu>]

On 1/9/12 10:47 AM, "Colm O hEigeartaigh" <co...@apache.org> wrote:
>
>The problem is that it does not take account of IDs in other
>namespaces, for example xmlns:wsu. If the user wants to support IDs in
>other namespaces then he/she has to do their own tree-search.

No, they just have to register it with the DOM ahead of time. Your id
resolution itself will not even find that attribute unless it's registered
with the DOM, based on what you posted.

> IMO we should also be checking the wsu namespace, as well as the SAML
>AssertionID/ID attributes, by default, as this gives better default
>protection against wrapping attacks.

You can special case 2 or 3 or 5 things, but you're still left with the
same problem.

>Note that we don't actually support retrieving References by this
>search, just checking for duplicates. So it's still up to the user to
>find the elements that are signed so that they can be retrieved via
>Document.getElementById().

What matters is what gets resolved. There's no sense checking for
duplicates except using the same set of IDs that will be subject to
resolution.

-- Scott

Re: Id Resolution Observations and Suggestions

[Colm O hEigeartaigh <co...@apache.org>]

Ok great.

> I propose to add a tree search when
> this switch is enabled, which will check that each Reference URI that
> is a fragment or XPointer reference is unique in the document.

I have a prototype of this working and I've run into a few issues I'd
like some feedback on.

The basic idea is a tree search when secure validation is enabled,
that checks that no two Elements in the Document have the same ID
attribute that was registered using the DOM APIs, e.g. "if
(attr.isId() && id.equals(attr.getValue()))".

The problem is that it does not take account of IDs in other
namespaces, for example xmlns:wsu. If the user wants to support IDs in
other namespaces then he/she has to do their own tree-search. IMO we
should also be checking the wsu namespace, as well as the SAML
AssertionID/ID attributes, by default, as this gives better default
protection against wrapping attacks.

Note that we don't actually support retrieving References by this
search, just checking for duplicates. So it's still up to the user to
find the elements that are signed so that they can be retrieved via
Document.getElementById().

Opinions?

Colm.


On Fri, Jan 6, 2012 at 7:22 PM, Cantor, Scott <ca...@osu.edu> wrote:
> On 1/6/12 1:16 PM, "Colm O hEigeartaigh" <co...@apache.org> wrote:
>>
>>Does this sound like a reasonable course of action?
>
> Yes.
>
> -- Scott
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Id Resolution Observations and Suggestions

[Colm O hEigeartaigh <co...@apache.org>]

> Finally, the application must check that the dereferenced Elements
> that were signed are in the location in the document that it expects
> them to be signed. The JSR-105 API facilitates this by caching the
> references (this must be configured by setting a property to true).
> The "old" API does not return the Reference Elements. I will look into
> adding some functionality for this.

I've committed some code that does this:

https://issues.apache.org/jira/browse/SANTUARIO-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183384#comment-13183384

Colm.


On Fri, Jan 6, 2012 at 6:16 PM, Colm O hEigeartaigh <co...@apache.org> wrote:
> I'd like to summarise my current understanding of this issue.
>
> The patch I attached previously simplifies how same-document
> References are retrieved by using the Document.getElementById() call,
> whereas previously a static cache was also searched. The new behaviour
> is fully pluggable, as you can just plug in a different
> ResourceResolver implementation if you want to retrieve same document
> Elements in a different way. The only downside is that it will break
> existing applications that sign an Object that is not already in the
> document tree, but I'm ok with that as this is a new major release.
>
> The next issue is that the element returned by
> Document.getElementById() is not guaranteed to be unique, thus
> potentially facilitating wrapping attacks. I've added a "secure
> validation" switch which sets some security constraints on signature
> validation (defaults to false). I propose to add a tree search when
> this switch is enabled, which will check that each Reference URI that
> is a fragment or XPointer reference is unique in the document.
>
> Finally, the application must check that the dereferenced Elements
> that were signed are in the location in the document that it expects
> them to be signed. The JSR-105 API facilitates this by caching the
> references (this must be configured by setting a property to true).
> The "old" API does not return the Reference Elements. I will look into
> adding some functionality for this.
>
> Does this sound like a reasonable course of action?
>
> Colm.
>
>
>
> On Thu, Jan 5, 2012 at 8:11 PM, Cantor, Scott <ca...@osu.edu> wrote:
>> On 1/5/12 12:18 PM, "Colm O hEigeartaigh" <co...@apache.org> wrote:
>>>
>>>If people are more or less happy with this approach then I don't mind
>>>dumping IdResolver.
>>
>> My position is just that it should be one or the other, and not both (or
>> making the whole ting fully pluggable so the application just decides),
>> and that obviously a change that involved removing the DOM call by default
>> would have to be phased in.
>>
>> I'm supportive of making changes to the C++ in that vein (I think it's
>> pluggable now, but I need to do some checking).
>>
>> You're correct that in addition to the DOM3 requirement, using the DOM
>> means that all content has to be reachable from the document element. But
>> I'd note that the ability to not require that is most likely a nice gaping
>> hole to more security weirdness, esp. on the verifier end.
>>
>> -- Scott
>>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Id Resolution Observations and Suggestions

[Chad La Joie <la...@itumi.biz>]

Yeah, sorry I meant to look at your patch last night but got
sidetracked.  The patch you have looks like what I expected to see.
And yes, what you stated below sounds correct.

On Fri, Jan 6, 2012 at 13:16, Colm O hEigeartaigh <co...@apache.org> wrote:
> I'd like to summarise my current understanding of this issue.
>
> The patch I attached previously simplifies how same-document
> References are retrieved by using the Document.getElementById() call,
> whereas previously a static cache was also searched. The new behaviour
> is fully pluggable, as you can just plug in a different
> ResourceResolver implementation if you want to retrieve same document
> Elements in a different way. The only downside is that it will break
> existing applications that sign an Object that is not already in the
> document tree, but I'm ok with that as this is a new major release.
>
> The next issue is that the element returned by
> Document.getElementById() is not guaranteed to be unique, thus
> potentially facilitating wrapping attacks. I've added a "secure
> validation" switch which sets some security constraints on signature
> validation (defaults to false). I propose to add a tree search when
> this switch is enabled, which will check that each Reference URI that
> is a fragment or XPointer reference is unique in the document.
>
> Finally, the application must check that the dereferenced Elements
> that were signed are in the location in the document that it expects
> them to be signed. The JSR-105 API facilitates this by caching the
> references (this must be configured by setting a property to true).
> The "old" API does not return the Reference Elements. I will look into
> adding some functionality for this.

-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered

Re: Id Resolution Observations and Suggestions

["Cantor, Scott" <ca...@osu.edu>]

On 1/6/12 1:16 PM, "Colm O hEigeartaigh" <co...@apache.org> wrote:
>
>Does this sound like a reasonable course of action?

Yes.

-- Scott

Re: Id Resolution Observations and Suggestions

[Colm O hEigeartaigh <co...@apache.org>]

I'd like to summarise my current understanding of this issue.

The patch I attached previously simplifies how same-document
References are retrieved by using the Document.getElementById() call,
whereas previously a static cache was also searched. The new behaviour
is fully pluggable, as you can just plug in a different
ResourceResolver implementation if you want to retrieve same document
Elements in a different way. The only downside is that it will break
existing applications that sign an Object that is not already in the
document tree, but I'm ok with that as this is a new major release.

The next issue is that the element returned by
Document.getElementById() is not guaranteed to be unique, thus
potentially facilitating wrapping attacks. I've added a "secure
validation" switch which sets some security constraints on signature
validation (defaults to false). I propose to add a tree search when
this switch is enabled, which will check that each Reference URI that
is a fragment or XPointer reference is unique in the document.

Finally, the application must check that the dereferenced Elements
that were signed are in the location in the document that it expects
them to be signed. The JSR-105 API facilitates this by caching the
references (this must be configured by setting a property to true).
The "old" API does not return the Reference Elements. I will look into
adding some functionality for this.

Does this sound like a reasonable course of action?

Colm.



On Thu, Jan 5, 2012 at 8:11 PM, Cantor, Scott <ca...@osu.edu> wrote:
> On 1/5/12 12:18 PM, "Colm O hEigeartaigh" <co...@apache.org> wrote:
>>
>>If people are more or less happy with this approach then I don't mind
>>dumping IdResolver.
>
> My position is just that it should be one or the other, and not both (or
> making the whole ting fully pluggable so the application just decides),
> and that obviously a change that involved removing the DOM call by default
> would have to be phased in.
>
> I'm supportive of making changes to the C++ in that vein (I think it's
> pluggable now, but I need to do some checking).
>
> You're correct that in addition to the DOM3 requirement, using the DOM
> means that all content has to be reachable from the document element. But
> I'd note that the ability to not require that is most likely a nice gaping
> hole to more security weirdness, esp. on the verifier end.
>
> -- Scott
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Id Resolution Observations and Suggestions

["Cantor, Scott" <ca...@osu.edu>]

On 1/5/12 12:18 PM, "Colm O hEigeartaigh" <co...@apache.org> wrote:
>
>If people are more or less happy with this approach then I don't mind
>dumping IdResolver.

My position is just that it should be one or the other, and not both (or
making the whole ting fully pluggable so the application just decides),
and that obviously a change that involved removing the DOM call by default
would have to be phased in.

I'm supportive of making changes to the C++ in that vein (I think it's
pluggable now, but I need to do some checking).

You're correct that in addition to the DOM3 requirement, using the DOM
means that all content has to be reachable from the document element. But
I'd note that the ability to not require that is most likely a nice gaping
hole to more security weirdness, esp. on the verifier end.

-- Scott

Re: Id Resolution Observations and Suggestions

[Colm O hEigeartaigh <co...@apache.org>]

Hi Chad,

> In addition, given the manner in which the IdResolver currently works, I
> believe it could be done away with entirely. The
> IdResolver.registerElementById method could simply be replaced by the
> appropriate Element.setIdAttribute* method.  Doing so would remove a
> potentially large in-memory data structure as well as various
> synchronization points that currently prevent concurrent ID resolutions.

I took a stab at implementing this to check for any problems (patch
attached). All of the tests on trunk pass with this change. One
potential issue is when you are creating a Signature which is signing
an "Object" contained in the Signature. In this case, the Signature
element must be available via the document element, or else it will
not be able to resolve the Object via "getElementById".

If people are more or less happy with this approach then I don't mind
dumping IdResolver.

I want to think about the duplicate Id thing a bit more before getting
back to you on that.

Colm.

On Wed, Dec 21, 2011 at 12:14 PM, Chad La Joie <la...@itumi.biz> wrote:
> So, last night I spent some time digging in to the new code and
> discussing with some things with Scott.  Here's where we ended up.
>
> The IdResolver is not designed in a manner that would allow alternative
> implementations to be used.  Though, given that it is only used by the
> ResourceResolver implementations, those could be replaced by the user of
> the library
>
> The new code does use the Document.getElementById method to look up IDs
> in the general case.  This may be overridden by explicitly placing
> ID-to-Element mappings into the IdResolver, but since doing this is
> neither documented nor shown in the examples it is fairly safe to assume
> this isn't happening out in the wild.
>
> Given the above, this code does not guard against any issues that may
> arise from duplicate IDs.
>
> In the case of signatures, there seems to be nothing that a library can
> do in order to ensure that the "right thing" is covered by the signature
> since the "right thing" is use-case specific.
>
> In the case of encryption, there is no way for the application to know
> whether the dereferenced encrypted encryption key is what the document
> author actually intended.  If it's not, however, the worst that would
> happen is that encrypted data would not decrypt.
>
> Given this, I believe the following things should be done:
> - The use of Document.getElementById and the potential issue caused by
> the lack of a strong guarantee on ID uniqueness should be documented.
> - The documentation for XMLSignature and all the examples should be
> updated to make it clear that the user of the library needs to check
> that what they thought was covered by the signature actually was.
> - Attempting to update the examples in this way will make it clear that
> better APIs need to be provided to expose the content indicated by
> <Reference>s.
>
> In addition, given the manner in which the IdResolver currently works, I
> believe it could be done away with entirely. The
> IdResolver.registerElementById method could simply be replaced by the
> appropriate Element.setIdAttribute* method.  Doing so would remove a
> potentially large in-memory data structure as well as various
> synchronization points that currently prevent concurrent ID resolutions.
>
> --
> Chad La Joie
> www.itumi.biz
> trusted identities, delivered



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: Id Resolution Observations and Suggestions

[Chad La Joie <la...@itumi.biz>]

Detecting duplicate IDs is really orthagonal to the real question: "Is
the stuff I care about covered by the signature?".  So what I
recommended below is really just focused on providing the means to
answer that question.

If was wish to provide duplicate ID checking, in addition to this, I
think that would be a fine tool to make available to people.


On 12/21/11 2:47 PM, Sean Mullan wrote:
> Are you still thinking we should also scan the document for duplicate IDs?
> 
> --Sean
> 
> On 12/21/11 7:14 AM, Chad La Joie wrote:
>> So, last night I spent some time digging in to the new code and
>> discussing with some things with Scott.  Here's where we ended up.
>>
>> The IdResolver is not designed in a manner that would allow alternative
>> implementations to be used.  Though, given that it is only used by the
>> ResourceResolver implementations, those could be replaced by the user of
>> the library
>>
>> The new code does use the Document.getElementById method to look up IDs
>> in the general case.  This may be overridden by explicitly placing
>> ID-to-Element mappings into the IdResolver, but since doing this is
>> neither documented nor shown in the examples it is fairly safe to assume
>> this isn't happening out in the wild.
>>
>> Given the above, this code does not guard against any issues that may
>> arise from duplicate IDs.
>>
>> In the case of signatures, there seems to be nothing that a library can
>> do in order to ensure that the "right thing" is covered by the signature
>> since the "right thing" is use-case specific.
>>
>> In the case of encryption, there is no way for the application to know
>> whether the dereferenced encrypted encryption key is what the document
>> author actually intended.  If it's not, however, the worst that would
>> happen is that encrypted data would not decrypt.
>>
>> Given this, I believe the following things should be done:
>> - The use of Document.getElementById and the potential issue caused by
>> the lack of a strong guarantee on ID uniqueness should be documented.
>> - The documentation for XMLSignature and all the examples should be
>> updated to make it clear that the user of the library needs to check
>> that what they thought was covered by the signature actually was.
>> - Attempting to update the examples in this way will make it clear that
>> better APIs need to be provided to expose the content indicated by
>> <Reference>s.
>>
>> In addition, given the manner in which the IdResolver currently works, I
>> believe it could be done away with entirely. The
>> IdResolver.registerElementById method could simply be replaced by the
>> appropriate Element.setIdAttribute* method.  Doing so would remove a
>> potentially large in-memory data structure as well as various
>> synchronization points that currently prevent concurrent ID resolutions.
>>

-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered

Re: Id Resolution Observations and Suggestions

[Sean Mullan <se...@oracle.com>]

Are you still thinking we should also scan the document for duplicate IDs?

--Sean

On 12/21/11 7:14 AM, Chad La Joie wrote:
> So, last night I spent some time digging in to the new code and
> discussing with some things with Scott.  Here's where we ended up.
> 
> The IdResolver is not designed in a manner that would allow alternative
> implementations to be used.  Though, given that it is only used by the
> ResourceResolver implementations, those could be replaced by the user of
> the library
> 
> The new code does use the Document.getElementById method to look up IDs
> in the general case.  This may be overridden by explicitly placing
> ID-to-Element mappings into the IdResolver, but since doing this is
> neither documented nor shown in the examples it is fairly safe to assume
> this isn't happening out in the wild.
> 
> Given the above, this code does not guard against any issues that may
> arise from duplicate IDs.
> 
> In the case of signatures, there seems to be nothing that a library can
> do in order to ensure that the "right thing" is covered by the signature
> since the "right thing" is use-case specific.
> 
> In the case of encryption, there is no way for the application to know
> whether the dereferenced encrypted encryption key is what the document
> author actually intended.  If it's not, however, the worst that would
> happen is that encrypted data would not decrypt.
> 
> Given this, I believe the following things should be done:
> - The use of Document.getElementById and the potential issue caused by
> the lack of a strong guarantee on ID uniqueness should be documented.
> - The documentation for XMLSignature and all the examples should be
> updated to make it clear that the user of the library needs to check
> that what they thought was covered by the signature actually was.
> - Attempting to update the examples in this way will make it clear that
> better APIs need to be provided to expose the content indicated by
> <Reference>s.
> 
> In addition, given the manner in which the IdResolver currently works, I
> believe it could be done away with entirely. The
> IdResolver.registerElementById method could simply be replaced by the
> appropriate Element.setIdAttribute* method.  Doing so would remove a
> potentially large in-memory data structure as well as various
> synchronization points that currently prevent concurrent ID resolutions.
>