Re: SPKI export needs additional parameter

On Tue, Feb 25, 2014 at 10:43 AM, Vijay Bharadwaj <
Vijay.Bharadwaj@microsoft.com> wrote:

>  Why not follow the credo of “Be conservative in what you send, be
> liberal in what you accept”?
>
>
>
> In other words, what if WebCrypto accepts either OID but only produces a
> specific one on export (we could pick the more specific one except when
> doing so significantly impacts compatibility)?
>
>
>
> *From:* Jim Schaad [mailto:ietf@augustcellars.com]
> *Sent:* Tuesday, February 25, 2014 10:13 AM
> *To:* public-webcrypto@w3.org
> *Subject:* SPKI export needs additional parameter
>
>
>
> There are going to be some interesting issues when dealing with SKPI that
> have not yet been raised.
>
>
>
> Some algorithms allow for multiple SPKI OID values to be specified and
> therefore the OID of the key is not necessarily determinate for the single
> algorithm that is to be used, it may in fact be a set of algorithms that
> can be used for a single key OID value.  The opposite mapping is also not
> going to be one-to-one.  That is a single algorithm may allow for multiple
> key OID values to be used for it.
>
>
>
> We have already seen this for DH, where there are two different key OIDs
> that can be used for the DH key agreement algorithm, specifically the
> PKCS#3 one and the X9.42 one.
>
>
>
> For RSA-PSS, one can use both the rsaEncryption OID for a key as well as
> the id-RSASSA-PSS OID.
>
> For RSA-OAEP, one can use both the rsaEncryption OID for a key as well as
> the id-RSAES-OAEP OID.
>
>
>
> On the import side, this is not an issue as multiple OID values can be
> checked in the logic and permitted.  However for export this is an issue as
> one needs to have the ability to specify which of the OID values should be
> used during the export processing.  This is a missing functionality that we
> needs to discuss adding.
>
>
>
> Jim
>
>
>

The issue about export is already known. The export API will produce a
single canonical, consistent version. That's what I'm in the process of
writing now.

That is, it will _always_ produce id-RSASSA-PSS, so that it can have full
fidelity.

This is no different than JWKs, which MAY or MAY NOT have an "alg". Export
also has to choose whether or not to include an "alg" param in the JWK, and
so for full-fidelity roundtrip, export will always include the "alg"

Applications that wish/need to mutate it can do so. Odds are they already
have ASN.1 parsing handy if they're at that point.