Skip to Content.
Sympa Menu

assurance - RE: [Assurance] Meaning of "industry standard" crypto

Subject: Assurance

List archive

RE: [Assurance] Meaning of "industry standard" crypto


Chronological Thread 
  • From: "Roy, Nicholas S" <>
  • To: "" <>
  • Subject: RE: [Assurance] Meaning of "industry standard" crypto
  • Date: Mon, 12 Nov 2012 20:59:07 +0000
  • Accept-language: en-US

This is excellent news, thanks Ann,

 

Nick

 

From: [mailto:] On Behalf Of Michael R. Gettes
Sent: Monday, November 12, 2012 2:45 PM
To: <>
Subject: Re: [Assurance] Meaning of "industry standard" crypto

 

Aha!  Thanks - that really helps clarify your earlier remarks.

 

/mrg

 

On Nov 12, 2012, at 15:26, Ann West <>

 wrote:



Michael

 

It means that in 1.2, FICAM is asking us to replace the term industry standard with approved as defined in 800-63. 

 

We are responding, sure we can use  approved, but we'd like to provide our own definition that accommodates HE deployments.

 

Once we are finished with the negotiations, I can tell you what the spec will say. ;)

 

Ann


Hi Ann,

 

does this mean "industry standard" will be removed from the 1.2 IAP post FICAM negotiations?  I ask because you use the language of "approved" and "comparable means" and Mr. Brogan was inquiring about "Industry Standard".  They could be loosely interpreted as different or the same, depending on who is doing the interpreting.

 

/mrg

 

On Nov 12, 2012, at 11:57, Ann West <> wrote:

 

Hi Michael,

 

A very good question and one, it turns out, that will be answered  very soon.

 

As you know, we're in discussions with FICAM about the approval of our 1.2 Profile and Framework documents. One of their requests is to change this term to "approved"  and define it the same as in 800-63-1:

 

Federal Information Processing Standard (FIPS) approved or NIST recommended. An algorithm or technique that is either 1) specified in a 

FIPS or NIST Recommendation, or 2) adopted in a FIPS or NIST Recommendation.

 

This poses some issues for HE, most notably the lack of support of technologies used with MS Active Directory. As you know, per FICAM our program needs to be comparable to 800-63, but it doesn't have to follow it exactly. This is one place where HE would be at substantial disadvantage if we were to accept the wording as-is. As a result, we are recommending the following as the definition for "approved:" 

 

Any implementation of an algorithm or techniques specified in a FIPS standard or NIST recommendation, or any algorithm or technique that conforms to a practice identified by InCommon as approved for specified IAPs.

 

As you may remember, Nick Roy et al developed the AD Silver cookbook to help schools using AD comply with Silver. We're proposing to formalize this process  with the resulting documents deemed as approved alternatives (or comparable means).

 

Best regards,

Ann

 


There are several places in IAP v1.1 where “industry standard” crypto is specified. Having a reasonable understanding of the term seems important when making statements about compliance to the IAP.

 

In local discussions I’ve encountered a range of interpretations.

 

One interpretation states that any crypto used in a widely deployed product is “industry standard” because the broad installation base of the product makes it a de facto industry standard.

 

Another interpretation is that “industry standard” means the crypto meets some standard for resistance against current threats that is certified by a government agency (e.g. NIST) or is generally deemed of equivalent strength. Algorithms that have been deprecated for years would be excluded from the “industry standard” list. IAP v1.0 specified NIST-approved crypto but this was changed to “industry standard” in v1.1.  I’ve assumed the goal behind this change was to maintain cryptographic strength but to provide implementers more flexibility in choice of algorithms. Was that the case?

 

Anyone want to offer interpretations of “industry standard” crypto from their own campus assurance work?

 

Michael W. Brogan

University of Washington

 




Archive powered by MHonArc 2.6.16.

Top of Page