Yes using "alg":"spi" is cleaner and allowed by the current spec.  I am not 
keen on omitting alg as a flag.

On 2013-04-19, at 3:10 PM, Mike Jones <[email protected]> wrote:

> BTW, in terms of a “dedicated flag”, I’d previously suggested to Richard in 
> private communication that one way for the SPI spec to do his cleanly would 
> be to use “alg”: “spi”, rather than omitting the “alg” field entirely.  The 
> “spi” value would then be registered by the SPI spec in the algorithms 
> registry – pointing back to the SPI spec.
>  
> I personally think that this is cleaner than just omitting “alg”, since it 
> maintains the invariant that all JWS and JWE representations have an “alg” 
> value that is used to determine the processing rules.
>  
>                                                                 Cheers,
>                                                                 -- Mike
>  
> From: Russ Housley [mailto:[email protected]] 
> Sent: Friday, April 19, 2013 10:51 AM
> To: Richard Barnes; Mike Jones
> Cc: Karen O'Donoghue; [email protected]
> Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add 
> a "spi" header field?
>  
> +1
>  
>  
> On Apr 19, 2013, at 1:42 PM, Richard Barnes wrote:
> 
> 
> In principle, you could use the omission of the "alg" field as a signal that 
> pre-negotiation is going on.  However, that seems like not the most useful 
> way to do it, and it conflicts with current practice -- namely the examples 
> currently in the JWE and JWS specs.  Those examples use pre-negotiation, but 
> they also have an "alg" field.  It's not very useful because it doesn't 
> provide the recipient any clue about how to populate the missing fields.  
> There's a semantic mis-match here as well, since a JWE with pre-negotiation 
> is still a JWE, just an incomplete one.  
>  
> A dedicated flag field like SPI provides a clearer indication, and it also 
> provides a hook that out-of-band protocols can use to connect in the 
> pre-negotiated parameters.
>  
> --Richard
>  
>  
> 
> On Fri, Apr 19, 2013 at 12:06 PM, Mike Jones <[email protected]> 
> wrote:
> Russ, I'm curious why you say that the "spi" field needs to be in the base 
> spec.  From a spec factoring point of view, even if SPI remains a completely 
> separate spec and nothing is said in the base spec, there would be no 
> confusion or conflicts, including for implementations.  Here's why:
>   - A header without an "alg" field is not recognized as a JWS or JWE, so 
> there's no conflict there
>   - A JWS or JWE can legally contain a "spi" header field and a registry is 
> already provided to define the meanings of additional header fields, so 
> there's no conflict there either
> 
> Therefore, it seems like the separate spec could use the registry to define 
> the meaning of "spi" in a JWS and JWE and could furthermore define the 
> semantics of objects using headers without an "alg" field but including a 
> "spi" field.  No conflicts.  And clear separation of concerns.
> 
> Those wanting the SPI functionality could use it.  Those not needing it would 
> need to do nothing - which I think is as it should be.
> 
>                                 Best wishes,
>                                 -- Mike
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Russ 
> Housley
> Sent: Friday, April 19, 2013 8:37 AM
> To: [email protected]; [email protected]
> Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add 
> a "spi" header field?
> 
> Combination of 1 and 2.  The field needs to be in the base specifications, 
> but the only rule that needs to be included in the base specification is an 
> exact match of the identifier.
> 
> Russ
> 
> = = = = = = = = = =
> 
> 1.  Have draft-barnes-jose-spi remain a separate specification that could 
> optionally also be supported by JWS and JWE implementations.
> 2.  Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as 
> a mandatory feature.
> 3.  Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as 
> an optional feature.
> 4.  Another resolution (please specify in detail).
> 
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
>  
>  
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to