Re: [Shib-Dev] how to deliver personal infocard keyinfo to app?
Jim Fox
>> I'd say we can deliver the modulus only, and skip the exponent altogether.
>
> I think we should deliver something that can be processed by tools and turned
> into a public key, so I think it should be DER (encoded).
>
Why? What's the app going to do with this public key? We don't deliver to
apps the credentials used by IdPs when they authnticate. Seems to me that
this credential is nothing but a validation that the other information comes
from the same user as used the site before. I suggest that a 128 bit
hash of the public key ought to be enough information. It's an identifier
and nothing more.
Jim
Scott Cantor
I don't think we know enough to answer that question. For one thing, that
STS is usable with holder of key credentials on non-browser scenarios.
> We don't deliver to
> apps the credentials used by IdPs when they authnticate.
No, but that's because the SP's job is to authenticate the IdP for the
application. Here it can't do that.
> Seems to me that
> this credential is nothing but a validation that the other information
comes
> from the same user as used the site before. I suggest that a 128 bit
> hash of the public key ought to be enough information. It's an identifier
> and nothing more.
I don't think there's any reason to reduce the amount of information
provided when it's easier to provide the actual key. You're starting (I
think) with a KeyInfo that the C++ code already knows how to turn into DER.
Giving it something else is more work, not less.
-- Scott
Jim Fox
>
>> Seems to me that this credential is nothing but a validation that
>> the other information comes >> from the same user as used the site
>> before. I suggest that a 128 bit hash of the public key ought
>> to be enough information. It's an identifier and nothing more.
>
> I don't think there's any reason to reduce the amount of information
> provided when it's easier to provide the actual key. You're starting (I
> think) with a KeyInfo that the C++ code already knows how to turn into DER.
> Giving it something else is more work, not less.
>
If I get KeyInfo that is a cert (as from DigitalMe) then I can
indeed turn that into DER and send it to the environment. If,
however, all I get is a public key (as from CardSpace) then I
can't turn it into a cert, as the cert is a signed thing and I have
nothing to sign it with, and I therefore cannot turn it into DER.
All I have are two numbers. (I could base64 encode them.)
Jim
Scott Cantor
> indeed turn that into DER and send it to the environment. If,
> however, all I get is a public key (as from CardSpace) then I
> can't turn it into a cert, as the cert is a signed thing and I have
> nothing to sign it with, and I therefore cannot turn it into DER.
> All I have are two numbers. (I could base64 encode them.)
By DER, what I meant is the syntax that openssl uses for unencrypted public
keys. The openssl docs say:
-inform DER|NET|PEM
This specifies the input format. The DER option uses an ASN1 DER
encoded form compatible with the PKCS#1 RSAPrivateKey or Subject-
PublicKeyInfo format. The PEM form is the default format: it
con-
sists of the DER format base64 encoded with additional header and
footer lines. On input PKCS#8 format private keys are also
accepted. The NET form is a format is described in the NOTES sec-
tion.
So I guess I'm talking about the SubjectPublicKeyInfo format.
Now, getting that out probably would take some openssl calls, I suspect, by
casting the Apache key object to the OpenSSL subclass after verifying the
underlying implementation is OpenSSL, and then using operations on an RSA*
to get the DER.
I thought that the DER was available directly from the Apache object, but
it's not, you're right. So I guess a unique hash would be better, I guess of
a concatenation of the two numbers? Or maybe just of the whole KeyInfo, but
that would be a problem because tweaking the XML would change the hash.
-- Scott
Tom Scavo
>
> So I guess I'm talking about the SubjectPublicKeyInfo format.
Not quite (we just finished working through this the last few days).
The SubjectPublicKeyInfo contains two fields, the AlgorithmIdentifier
and the bits of the public key. The Subject Key Identifier (SKI)
extension is *usually* obtained by computing the SHA-1 hash of the
public key bits only (not the AlgorithmIdentifier), which is then
base64 encoded. Not all certs have an SKI extension, and not all
those that do compute it as above, but it's the most common way to do
so. (OpenSAML/Java does it this way, in fact.)
So one approach is the following. If you have a cert, ignore the SKI
extension and compute the SKI as above. If you have the key only,
compute the SKI as above. So in all cases you end up with the same
thing.
Tom
Scott Cantor
>
> Not quite (we just finished working through this the last few days).
I'm talking about a specific format from OpenSSL. not SKI.
That might be the better option, but I don't think it has
anything to do with the format I was talking about.
The OpenSSL format is definitely not a hash.
-- Scott
Tom Scavo
>> > So I guess I'm talking about the SubjectPublicKeyInfo format.
>>
>> Not quite (we just finished working through this the last few days).
>
> I'm talking about a specific format from OpenSSL. not SKI.
> That might be the better option, but I don't think it has
> anything to do with the format I was talking about.
The docs you quoted referred to an *input* format, presumably to
construct a certificate. I thought you and Jim were discussing a
format to pass from the SP to the application, in which case I don't
see how constructing a certificate applies (which I think Jim said, in
so many words). So I'm confused, and I'll shut up until I understand
the context better :-)
Tom
Scott Cantor
> construct a certificate.
No, I was just pasting from the manpage of the openssl rsa command. Inform
and outform are the same options and formats. Nothing to do with
certificates at all.
> I thought you and Jim were discussing a
> format to pass from the SP to the application, in which case I don't
> see how constructing a certificate applies (which I think Jim said, in
> so many words). So I'm confused, and I'll shut up until I understand
> the context better :-)
We are discussing that, but my feeling has been that a mechanism that
communicates the actual key is better than a hash if it's possible to do so.
In this case it may be more work than it's worth, so using some kind of SKI
approach might be the best middle ground (a semi-standard sort of hash).
-- Scott
Peter Williams
Try to ensure shib stays with the intended semantics of the SKI. It is not a mere implementation types : the various identifiers were defined to ensure that particular control objectives are (or at least can be) satisfied. Obviously, whether security profiles of the ASN.1 types actually satisfy the associated control objectives depends on the skill of the profiling team.
Tom Scavo
> See 2003: http://lists.oasis-open.org/archives/wss/200306/msg00096.html
The writer of this message claims the SKI is the "SHA1 hash of the DER
of the key." I don't think that's correct. According to RFC5280, at
least, the SKI is the SHA-1 hash of the plain (not DER-encoded) public
key. The tools I've looked at compute it this way, too.
Tom
Peter Williams
4.2.1.2 is clear that SKI aims to id a cert (which is what folks intended it to do, in the original proposed amendment to the X.509 standard). Good so far. Any use of SKI for other purpose (e.g. id keying material, id a party, id some arbitrary datum) is "improper" security engineering.
It's pretty obvious that the means of generating the unique value is essentially irrelevant - as all the core technical control is intended to do is allow one to make matches, between certificate layers, for use in path building or discriminating between leaf path nodes with the same public key component value(s) yet different control parameters. No other purpose is intended, and none should be assigned, I might counsel.
The 2 suggested practices for calculating the value in CA certs are pretty clearly written up: DER encoding of the subjectPublicKey **ASN.1 typed value*, as then encoded into an X.410 BIT STRING, with various leading bits and bytes removed or added to/from the DER-marshaled bit-string primitive type.
The type of the SubjectPublicKey Type is dependent on the algorithm of the keying material(s), of course, and contains various values as a consequence. (One deprecated NSA type defined for the DSS/KEA world used to contain 2 public keys, various privilege bits, and control values for ensuring key wrapping IKs derived from one of the public keys by KEA would be guaranteed to change by month and sensitivity class assigned to the particular TEK). Hopefully, it's now obvious why the suggested calculation is a function of the bit-string, whose value is an encoding of the marshaled subjectPublicKey type - which by the magic of ASN.1 macros is essentially an opaque type
The spec does then call out how CA certs are to be distinguished from EE certs, in the area of including the SKI extension: it's MUST generation and it's SHOULD handling.
"For end entity certificates, subject key identifiers SHOULD be
derived from the public key. Two common methods for generating key
identifiers from the public key are identified above."
However, this quote pretty clearly references the very methods defined earlier, for CA certs.
My conclusion is that the X.509 profile does not require its described methods be used (in fact, it clearly states one can roll one's own.) The methods it describes do support (to my eye) the main purpose of the identifier - identify certs - and thus the asymmetric key management controls that the particular cert represents. This all seems to nicely support the guts of Rick's message (from way back in 2003).
Scott Cantor
I see no relevance.
> Try to ensure shib stays with the intended semantics of the SKI.
And that would be? Let me put it this way. If we have to think about this
non-trivially, it's the wrong approach.
-- Scott
Joana M. F. Trindade
As Tom pointed out, we recently implemented something similar. What we do is
compute the SHA-1 hash of the public key bytes according to RFC5820, and
encode it in Base64. An example is available here (look for KeyInfo in the
SubjectConfirmation element):
https://gsoc2008.ncsa.uiuc.edu/sso-demo/SAMLResponse.xml
As you can see, we populate the KeyInfo with both the certificate and the SHA-1
hash we computed from the cert. This method for computing the SKI from RFC5820
is trivial, and also used by Apache WSS4J and bouncycastle API.
HTH,
Joana
--
Joana M. F. da Trindade
Email: jmftr...@inf.ufrgs.br
Personal Homepage: http://joanatrindade.wikidot.com
LinkedIn: http://www.linkedin.com/in/joanatrindade
Jim Fox
>
> Let me put it this way. If we have to think about this
> non-trivially, it's the wrong approach.
>
Possibly we can stop overdesigning this thing. The whole point was
to give some uniqueness to infocard's broken PPID. Adding a hash
of the card's public key accomplishes that. The only reason the
original PPID might not be unique is that it is a bearer item, and
could be stolen and reused. The only way the PPID can be discovered
is with the compromise of the user's system or the server's system.
Either way any little bit of security has been lost.
We don't even know that the key hash is even beneficial.
If I export a card to another system, the PPID might
stay the same, but will the public key? I don't see where
that's guaranteed. The system might be more useful without
it and no more secure with it.
My inclination is to drop the public key - hash and all.
If the PPID is important to the service, then the service
can protect it.
Jim
Scott Cantor
> to give some uniqueness to infocard's broken PPID. Adding a hash
> of the card's public key accomplishes that. The only reason the
> original PPID might not be unique is that it is a bearer item, and
> could be stolen and reused.
Well, right. It's not intended to be secure absent the ability to prove that
the same "issuer" is providing it, by verifying that the signature over the
assertion is from the same key. That's all we're trying to verify.
> We don't even know that the key hash is even beneficial.
> If I export a card to another system, the PPID might
> stay the same, but will the public key? I don't see where
> that's guaranteed. The system might be more useful without
> it and no more secure with it.
Actually, yes, it will be the same (because of how the self-issuing IdP is
defined). See section 8.4 of the ISIP.
> My inclination is to drop the public key - hash and all.
> If the PPID is important to the service, then the service
> can protect it.
How? The key is the only protection. The service can't protect it in any
other way.
My goal was to provide the key in a simple format and leave it at that. I
still think that's possible, but it will require some openssl functions to
pull off. It's not hard, but I don't object to avoiding linkage to openssl
either.
An alternative is a hash, but if the PKI specs have over-complicated that
like they do everything else, I'd say we should avoid anything that has the
semblance of "officialness" and just generate something.
The only thing to be careful of is that it needs to be something that can
port cleanly, because a service shouldn't have to depend on a hash value
that can't be generated by an alternative implementation of the SP. As an
example, this is C++, not Java, so what Java can do "trivially" is only
interesting to me insofar as it's something we can do (and vice versa).
-- Scott
Jim Fox
>> My inclination is to drop the public key - hash and all.
>> If the PPID is important to the service, then the service
>> can protect it.
>
> How? The key is the only protection. The service can't protect it in any
> other way.
>
> My goal was to provide the key in a simple format and leave it at that. I
> still think that's possible, but it will require some openssl functions to
> pull off. It's not hard, but I don't object to avoiding linkage to openssl
> either.
>
My thinking is that the PPID has the security of a big random number,
which cannot be guessed. It can only be compromised if the application
gives it away. It can be protected by keeping it secret.
How about a base64 of an sha1 of the modulus? That's a mathematical
thing. All languages ought to do it about the same.
Jim
Scott Cantor
> which cannot be guessed. It can only be compromised if the application
> gives it away. It can be protected by keeping it secret.
I suppose, but nothing prevents anything from asserting that PPID if it is
known, so I don't see why I'd trust such a system.
> How about a base64 of an sha1 of the modulus? That's a mathematical
> thing. All languages ought to do it about the same.
I don't know enough about the RSA algorithm, but I was under the impression
only the two numbers were unique, not just the modulus. That's why I was
trying for a known key format, rather than trying to invent some way to hash
multiple numbers and accidentally screw it up.
- Scott
Jim Fox
>> How about a base64 of an sha1 of the modulus? That's a mathematical
>> thing. All languages ought to do it about the same.
>
> I don't know enough about the RSA algorithm, but I was under the impression
> only the two numbers were unique, not just the modulus. That's why I was
> trying for a known key format, rather than trying to invent some way to hash
> multiple numbers and accidentally screw it up.
>
The modulus is a big random number, which is the unique part. The
exponent is small number, very often the same for many keys. If we were
going to do anything with the key we would need both. If we're only
interested in uniqueness the modulus is enough.
For DSA the 'Y' value performs the same uniqueness function. Infocard
seems not to use DSA however, so that's maybe not an issue.
Jim
Scott Cantor
> exponent is small number, very often the same for many keys. If we were
> going to do anything with the key we would need both. If we're only
> interested in uniqueness the modulus is enough.
Ok, that's fine with me.
> For DSA the 'Y' value performs the same uniqueness function. Infocard
> seems not to use DSA however, so that's maybe not an issue.
I don't recall from the profile whether they say anything about RSA being
required or not, but I don't think we have to worry much about it.
-- Scott