From: Russ Housley [mailto:housley@xxxxxxxxxxxx]
Sent: den 16 januari 2007 13:54
To: Stefan Santesson; ietf-pkix@xxxxxxx
Subject: RE: Straw poll for Algorithm Identifiers in Subject Public Key
Info.
Stefan:
If a certificate says that the public key is only to be used with RSAES-OAEP,
then it should fail if it trys to use it with some other algorithm. In
the three steps that you cite, this has no impact on 1). It is not a
signature algorithm, so it should no have any impact on the certification path
validation. Updating the OID table seems very straightforward.
Something like this needs to be done anytime a new algorithm is added to the
system. It will need to be added to the table to handle the appearance in
S/MIME for example. Finally, the pain involved with 3) is the leverage to
get application developers to use the OID table. There may be some
application-specific things that need to be done as well, but that does not
necessarily have anything to do with the certificate.
I disagree with one thing you said. You said:
> In the “old” logic, when a subject public key OID had no
constraining semantics.
> It would be safe to use a trusted key if it works (if all other checks are
good). This
> change of semantics is the danger when it hits old applications not
designed for
> it. If they were designed to honor RFC 4055 OIDs, this would not be an
issue.
> However RFC 4055 has not been implemented in many places.
The subject public key information has always included an algorithm
identifier. The table of contents of RFC 3279 shows the ones that have
been in use for at least four years:
2.3 Subject Public Key Algorithms
2.3.1 RSA Keys
2.3.2 DSA Signature Keys
2.3.3 Diffie-Hellman Key Exchange Keys
2.3.4 KEA Public Keys
2.3.5 ECDSA and ECDH Public Keys
DSA and KEA public keys can also be used in DH operations from a purely
mathematical perspective. However, we choose to assign three different
OIDs. We did not assign one OID for discrete log public keys.
Russ
At 03:12 PM 1/16/2007, Stefan Santesson wrote:
Russ,
I can’t see that we have any disagreements.
My point is that the mapping and as such the responsibility for doing the
mapping correctly rests fully on the applications or protocol stacks.
You can’t just add this feature in the crypto library or the validation
module, and use current protocol stacks and applications. If you do that, they
most likely either fail or get it wrong.
So we have a situation with multiple possible points of failure.
An expansion of the public key OIDs for ECC will in short require the following
changes:
1) Update chain validation to recognize new OIDs and enforce them in chain validation
2) Update the OID table (voluntarily used by protocols and applications)
3) Update the mapping logic in all protocol stacks and cert using applications
The interesting question is what will happen if you do 1) and 2) but not 3). Or
do 1) and 2) and gradually update 3)
Keeping in mind that many applications are designed out of the notion that a
public key obtained through a validated certificate path, associated with a
matching key usage and EKU, either works (then it is a good one) or don’t
work, I wouldn’t be surprised if an application receiving a new Alg ID
that it can’t map to the protocol Alg ID, still will try to use the key
it has to see if it works. Neither the chain validation engine nor the Crypto
library will catch or prevent this abuse.
Of course, a correct application will get it right, but many developers have
learned to make their code as fault tolerant as possible and are used to
process cases of conflicting information in a way that succeeds when it should
be “safe” to do so. Example: a chain should fail if Issuer name and
subject name matching fails. But still, if signature of the leaf cert matches
the public key of the CA cert and subject/issuer name are “Example
Inc”/”example, inc” in different encoding. It would be safe
to allow it to pass. Strictly such chain should fail, but you will find that
“fault tolerant” designs, knowing that users will get things wrong,
may actually pass such chain, because it is safe to do so.
In the “old” logic, when a subject public key OID had no
constraining semantics. It would be safe to use a trusted key if it works (if
all other checks are good). This change of semantics is the danger when it hits
old applications not designed for it. If they were designed to honor RFC 4055
OIDs, this would not be an issue. However RFC 4055 has not been implemented in
many places.
The difference with an extension is that the application will get a critical
extension error, which applications currently are designed to honor. They
either need to recognize and honor that extension or fail. The risk for abuse
during transition is thus considerably lower.
What ever we do, I hope we can do it as simple as possible. But even though
defining a few new alg OIDs seems simple, it may not provide for a safe and
simple transition.
Stefan Santesson
Senior Program Manager
Windows Security, Standards
From: Russ Housley [
mailto:housley@xxxxxxxxxxxx]
Sent: den 16 januari 2007 11:04
To: Stefan Santesson; ietf-pkix@xxxxxxx
Subject: RE: Straw poll for Algorithm Identifiers in Subject Public Key
Info.
Stefan:
Let's expand your "Crypto Library"
box to include the algorithms that are discussed in RFC 4055.
-----------------
| Crypto Library|
-----------------
|
----------------------------------------------------
|
|
|
|
---------------
--------------- -------------- ---------------
| PKCS#1 v1.5 | | PKCS#1 v1.5
| | RSASSA-PSS | | RSAES-OAEP |
| Signature | | Key
Encrypt | | Signature | | Key Encrypt |
---------------
--------------- -------------- ---------------
|
|
|
|
----------------------------------------------------
|
---------------------
| RSA Math Routines |
---------------------
In the RFC 4055 approach, the algorithm
identifier says that the public key may be used for any one of these RSA
operations, or it names exactly one of them. If exactly one is named, it
seems to help the crypto library determine which of the routine to use.
If any is allowed, then the application or the protocol stack needs to tell the
crypto library which operation to perform.
You say:
> Adding this feature in the RFC4055
style is not impossible but it needs to be
> individually implemented in each cert
using protocol and application. This is
> not trivial considering that legacy is
a big complicating factor. In
> principle it worries me to put this
complex mapping burden on applications.
> Another threat with this approach is if
it leads to a requirement to define
> combinations of algorithm modes by
single OIDs where we may end up with a
> very large space of OIDs.
On your last point, RFC 4055 does not do any
such thing. It does not define OIDs for OAEP with a particular hash
algorithm as the mask generation function. No, it uses a parameter for
that.
Certificate using applications need to map
algorithm identifiers from certificates, the protocol, and the crypto
library. Agreed. It seems that the table approach that you describe
will work well with the simplified crypto library architecture that I have
drawn above. The one difference is that crypto libraries need to be able
to handle the fact that one public key might be useful in more than
algorithm. This is already the case. RSA keys are used for PKCS#1
v1.5 signature and key encrypt. If the key usage extension is not
present, then the certificate is not providing the context to select the
appropriate algorithm within the crypto library.
Russ