On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H < [email protected]> wrote:
> Breno,**** > > ** ** > > >> How about stapling an OCSP response to a JOSE message?**** > > > That's a more compelling use case -- it's security-specific but only > adds to the security validation context.**** > > ** ** > > ** ** > > How about the signing time?**** > > ** ** > > How about some DNS records with DANE and DNSSEC info giving evidence that > the public key is associated with a domain?**** > > ** ** > > How about a blob of data related to Sovereign Keys, or Perspectives, or > Convergence, or some other proposal to bolster PKI?**** > > ** ** > > How about a domain_parameter_seed so you can verify that the common domain > parameters (eg p & q in DSA) were not chosen to have special properties?** > ** > > ** ** > > How about data to allow you to validate a public key (eg co-factor for EC? > Something complicated for RSA?)?**** > > ** ** > > How about a timestamp from a timestamp service?**** > > ** ** > > ** ** > > I’m not sure which, where, or when an item like the ones mentioned above > will be needed. I am confident that someone will need some items like > these. When that happens they should have a choice about whether including > the item needs to break interop with all existing receivers. A mode field > that MUST be understood (eg “t”:”sig”) coupled with MUST ignored any > unrecognized parameters keeps our future choices open. > That's not good enough for a security spec. If fields are added and not all MUST be understood, then we need explicit syntax about what fields are to be ignored when not understood. E.g., in X509 certificates, extensions (while optional) have the ability to declare themselves critical, so that implementations that don't understand that extension MUST reject the certificate as invalid. > **** > > ** ** > > ** ** > > > However declaring that any header you don't understand could be optional > is a far worse balance on the extensibility versus simplicity spectrum > (where simplicity here is a stand-in for security, interoperability, etc.) > **** > > ** ** > > I’m not sure I understand this “simplicity” argument. Ignoring > unrecognized fields is the simplest implementation choice. Is your idea > that if you tightly constrain extensibility (by making them MUST > understand) then messages will not accumulate as many “enhancements” of > dubious value. That is, over time a MUST ignore rule allows messages to get > more complex (and hence less secure/interoperable). Do you want “MUST > understand” to strongly discourage people misusing the header to carry > content metadata, for instance? > Inevitably, a field will be added that shouldn't be ignored because it modifies the meaning of some other widely understood header entry, followed by usual antics and general perplexity. > **** > > ** ** > > ** ** > > --**** > > James Manger**** > > ** ** > > *From:* Breno de Medeiros [mailto:[email protected]] > *Sent:* Thursday, 26 July 2012 1:12 PM > *To:* Manger, James H > *Cc:* [email protected] > > *Subject:* Re: [jose] MUST understand ALL header fields**** > > ** ** > > That's a more compelling use case -- it's security-specific but only adds > to the security validation context.**** > > ** ** > > There may be a case to define optional entries in the JWT header. However > declaring that any header you don't understand could be optional is a far > worse balance on the extensibility versus simplicity spectrum (where > simplicity here is a stand-in for security, interoperability, etc.) So I am > not convinced that losing the ability to declare OCSP bindings in JWTs > justifies dropping the MUST language. If there is rough consensus that > defining optional security fields in the header is prudent from the > viewpoint of future spec extensibility then we should devise some simple > way to declare a JWT header field optional and exempt _only_those_ from the > MUST fail when not understanding clause. Changing the default behavior even > to SHOULD appears to me to sacrifice too much on the altar of > extensibility. **** > > ** ** > > On Wed, Jul 25, 2012 at 7:38 PM, Manger, James H < > [email protected]> wrote:**** > > How about stapling an OCSP response to a JOSE message? > > Why should that be "MUST understand"? > > -- > James Manger**** > > > > **** > > ** ** > > -- > --Breno**** > -- --Breno
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
