RE: Straw poll for Algorithm Identifiers in Subject Public Key Info.

[Russ Housley <housley@xxxxxxxxxxxx>]

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