The DMZ

9:09 AM

Hi everybody!

From (ISC)² Candidate Background Qualifications: "Have you ever been known by any other name, alias, or pseudonym? (Omit user identities or screen names with which you were publicly identified. Also omit name changes due to marriage or adoption.)"

What does this mean exactly? Does the use of a forum username break (ISC)² rules and could void a CISSP certification?

I find it quite a bit weird...

bilbo_pingouin

9:32 AM

I find that formulation really unclear...

Plus, if you've been known by a nickname at some point, why should that deny you the right to get a cerification, which is implied later...

WhiteWinterWolf

11:13 AM

@bilbo_pingouin It is not the fact to use a nickname which is "forbidden", it is fact to not publicly link this nickname to your real name.

You may use a nickname, but you have to publicly link it to your full real name.

I don't understand the interest of this. I may use a nickname on forums, on sites where I give feedback on products I bought or places I saw, for some artistic activity, etc. What makes this evil?

Journeyman Geek

I think it may be for people who changed their names

or possibly transgendered people

That reads as "We don't want to know your handle, we want to know your other 'legal' names or names you would have used professionally"

bilbo_pingouin

@WhiteWinterWolf on SE, for example, I think it isn't too uncommon to use a nickname NOT linked to you on The Worplace. You might not want your employer know that you consider kleaving your job, or exposing yourself to legal problems.

WhiteWinterWolf

@JourneymanGeek This is a set of "yes/no" "background qualification" questions, and they tell "If you answer 'Yes' to any of the questions above, it is possible you may not be eligible to earn an (ISC)² certification.". They do not seem to ask something for some information, they seem to ask for a formal commitment.

@bilbo_pingouin Yes, this is called privacy.

Journeyman Geek

@WhiteWinterWolf What if you changed your name, legally, to get away from some legal issues in the past?

I don't think they're asking about @WhiteWinterWolf. They're asking about someone changing their name from Jaime Moreno to John (or Jane) Brown...

bilbo_pingouin

@WhiteWinterWolf yep, I am not sure I see why that would deny you a certification. But IANAL, as they say...

WhiteWinterWolf

11:26 AM

@JourneymanGeek "any other name, alias, or pseudonym"

Journeyman Geek

@WhiteWinterWolf here legally you can have something like "Tan Foo Bar Alias Tan Ah Kow"

I think you're completely ignoring the "Omit user identities or screen names with which you were publicly identified."

So, if you were mark twain, you would need to identify yourself as samuel longhorn clements...

WhiteWinterWolf

If I were Samuel Langhorne Clemens, I should check yes here and explain that I used to write books under the name "Mark Twain".

Journeyman Geek

yup

and literally this is the situation they are probably asking for

WhiteWinterWolf

What distinguishes this from me using some pseudonyms for various activities?

Journeyman Geek

The internet is clearly not serious bzns

Also consider people who changed their names legally

WhiteWinterWolf

11:47 AM

Well, maybe you're right (and I hope so :) !), but in this case I really think this question is poorly worded.

In our current era of "transparency and security" which make the business of major economical actors, I see too much discourses telling things like "honest people have nothing to hide" and assimilating privacy to suspicious activity.

Stack Exchange

12:15 PM

I WONDERED why he kept asking whether we thought the impact speed was too low.

Nzall

I've got a question, but I'm not exactly sure what I want to ask about it. It concerns what will be used for certificate verification once SHA-256 has similar security concerns as SHA-1, if that's even possible

Has something been established about that yet?

or is that unlikely to happen soon enough for us to think about it now?

WhiteWinterWolf

@Nzall Yes, this is not only possible but expected as there is no expectation for any cryptographic algorithm to be eternally safe no matter advances in science and technology.

Nzall

@WhiteWinterWolf And has it been established yet what we will be transitioning to at that point?

WhiteWinterWolf

In order to promote open research and information sharing, there are regular open competitions made to establish upcoming cryptographic standards. There are different competitions dedicated to different cryptography domains, and regarding cryptographic hashing you may find useful information here:

NIST hash function competition

The NIST hash function competition was an open competition held by the US National Institute of Standards and Technology (NIST) to develop a new hash function called SHA-3 to complement the older SHA-1 and SHA-2. The competition was formally announced in the Federal Register on November 2, 2007. "NIST is initiating an effort to develop one or more additional hash algorithms through a public competition, similar to the development process for the Advanced Encryption Standard (AES)." The competition ended on October 2, 2012 when the NIST announced that Keccak would be the new SHA-3 hash algorithm...

Nzall

@WhiteWinterWolf But has it been established yet that we will be transitioning towards SHA-3 yet? Or is that still up for debate?

I mean, we're currently transitioning from SHA-1 to SHA-256 for TLS certs. What will we be using next for TLS certs once SHA-256 is deemed insecure?

has that algorithm been established yet?

WhiteWinterWolf

12:29 PM

(... I was searching about an official statement regarding the transition, such as Currently there is no need to transition applications from SHA-2 to SHA-3.").

And yes, NIST hash function competition is over (ended in 2012) and has elected the Keccak algorithm to become SHA-3, official successor of SHA-2. The story is detailed in the linked Wikipedia page.

Nzall

@WhiteWinterWolf Are there any other algorithms that may come into consideration for certificate verification besides SHA-3?

I mean, I don't know if there are any others that may be applicable for the task

WhiteWinterWolf

@Nzall It depends what your main goal is. For certificates, usually you seek for the maximum compatibility and therefore stick to main accepted standards. In this case the safest choice will be to stick to the SHA series.

Otherwise, finalists in such competitions remain well regarded algorithms which can also be safely used for your own purpose, but you cannot expected wide adoption in browsers and other end-user software.

Nzall

12:57 PM

@WhiteWinterWolf So what you're saying is that technically, you can choose any algorithm you want, but in practical terms, the SHA-family is the only real option due to compatibility?

Like, i could hash my certificate using a different algorithm, but the client wouldn't be guaranteed to have support for it?

WhiteWinterWolf

1:15 PM

@Nzall Good question. Actually, in the case of certificates, unless you want to fly on your own completely out of the standards, you are restricted by the allowed values in the certificate's X.509 "signatureAlgorithm" field as defined in RFC 5280, which links in turn to other RFC listing allowed algorithms, lists updated as standards evolve.

Oddly enough, latest updates seem to cover up to elliptic curve and SHA-512, but I do not see SHA-3 mentioned yet. Probably some ongoing work, for instance the BouncyCastle library implemented SHA-3 support very recently (things move slowly and cautiously in cryptography).

Nzall

@WhiteWinterWolf Also, which of those 3 linked RFCs mentions SHA-256?

WhiteWinterWolf

@Nzall SHA-256 with RSA is mentioned in RFC 4055, and with DSA and ECDSA is mentioned in RFC 5758.

RFC authors should be treasure hunt fans ;) !

Nzall

@WhiteWinterWolf ah, so the hashing functions are not the entire signature algorithm, but only part of it?

apologies if these questions are a bit newbish, domain security is not my strong point

WhiteWinterWolf

1:46 PM

No problem, I'm here to learn too :) ! To sign, the sender (the certification authority here) generates a hash and will encrypt it using its private key (hence the need of an asymmetric algorithm). The receiver also calculates the hash and use the certificate authority public key to decrypt the signature and check if the result matches with the hash, if yes then the signature is correct.

I suppose RFC authors are not in a hurry to update due to their statements in RFC 5280 that "other signature algorithms MAY also be supported".

The linked RFC tell the OID to use in the certificate:

id-sha256  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
                     country(16) us(840) organization(1) gov(101)
                     csor(3) nistalgorithm(4) hashalgs(2) 1 }

This is to read OID 2.16.840.1.101.3.4.2.1. SHA-3 being not mentioned in IETF's RFCs, but the NIST registered new ones directly.

Transcript for