Assurance

["Michael R. Gettes" <>]

okay, i'm an idiot.  ignore me - for now.  :-)

/mrg

On Aug 3, 2012, at 13:15, Michael R. Gettes wrote:

> Ann,
> 
> I am reading SP800-63V1_0_2 which has the first paragraph you cite in 
> section 7 "Registration and Identity Proofing" on document page 19 and PDF 
> page 29.  I am unable to locate the 2nd paragraph in part or whole in this 
> version of SP800-63.  The first paragraph sheds lots of light on issues 
> related to the CommIT project but I don't want to comment until we are all 
> literally on the same page.
> 
> 1.0.2 is the latest rev of 800-63 and can be found at 
> http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf linked 
> from the main NIST SP site at http://csrc.nist.gov/publications/PubsSPs.html
> 
> Thanks.
> 
> /mrg
> 
> On Aug 3, 2012, at 12:43, Ann West wrote:
> 
>> All,
>> 
>> On the Implementers call on Wednesday, we talked about whether our current 
>> id proofing models should be categorized as remote proofing or in person 
>> proofing done remotely by another organization. 
>> 
>> One of the questions that arose is whether FICAM would allow organizations 
>> independent from the IdPO (not the same legal entity) to perform Id 
>> Proofing. 
>> 
>> In rereading 800-63-1 today, I suggest we all review their Registration 
>> and Issuance Processes. I've included the primary sections below. How 
>> would you answer our question from Wednesday?
>> 
>> Ann
>> 
>> 
>> 
>> 800-63-1
>> 
>> Page 27 Registration and Issuance Processes
>> 
>> The RA can be a part of the CSP, or the RA can be a separate and 
>> independent entity; however, a trusted relationship always exists between 
>> the RA and CSP. The RA or CSP maintain records of the registration. The RA 
>> and CSP can provide services on behalf of an organization or may provide 
>> services to the public. The processes and mechanisms available to the RA 
>> for identity proofing may differ as a result. Where the RA operates on 
>> behalf of an organization, the identity proofing process may be able to 
>> leverage a preexisting relationship (e.g., the Applicant is an employee or 
>> student). Where the RA provides services to the public, the identity 
>> proofing process is generally limited to confirming publicly available 
>> information and previously issued credentials.
>> 
>> And later in that section...
>> 
>> In models where the registration and identity proofing take place 
>> separately from credential issuance, the CSP is responsible for verifying 
>> that the credential is being issued to the same person who was identity 
>> proofed by the RA. In this model, issuance must be strongly bound to 
>> registration and identity proofing so that an Attacker cannot pose as a 
>> newly registered Subscriber and attempt to collect a token/credential 
>> meant for the actual Subscriber. This attack, and similar attacks, can be 
>> thwarted by the methods described in Section 5.3.1 (below Table 3), which 
>> describes which techniques are considered appropriate for establishing the 
>> necessary binding at the various assurance levels.
>