On Thu, Jan 04, 2018 at 08:03:55 -0600, Logan Widick wrote: > What do you think of the following:
> Content type application/jose+json: MUST be supported. If used, the JWS > will need to be in the Flattened or General serialization. Flattened MUST > be supported; General MAY be supported. > Content type application/jose: MAY be supported. If used, the JWS MUST use > the Compact serialization. Or should this content type not be allowed? Agreed. I wouldn't disallow "compact". And it could be clarified: The server SHOULD use the "Content-Type" HTTP header as an indication for the request format. > JWS Unprotected Header: Not currently used in ACME. Should this be banned > in ACME? I don't see much sense in those. But some client implementations might automatically add an unprotected header like e.g. "cty". Maybe with a "SHOULD NOT"? > Multiple signatures: MAY be supported. > Should messages signed by both MAC keys and private keys be allowed? This is already forbidden. > What about Key IDs not issued by the CA? > Or are multiple signatures more trouble than they're worth to the point of > banning them entirely? > > Multiple signatures on messages that need to be signed by account key: At > least one signature MUST be from the account key > > Multiple signatures on revokeCert: Should this be allowed? > > Multiple signatures on externalAccountBinding field of newAccount: Should > it be possible to bind to multiple pre-existing accounts? Or should this > not be allowed? > > Multiple signatures on newAccount: Not allowed? > > Multiple signatures on keyChange: Not allowed for outer or inner JWS? I see no use case. All the authentication is based on accounts and those have exactly one keypair. Having multiple signatures would equal using multiple accounts at the same time. That makes no sense to me. Client libs would probably not generate multiple signatures automatically. Multiple signatures should be banned in my opinion. > JWS Unencoded Payload Option (RFC 7797): Not allowed? Yep, they would make things very complicated. > Conversion guide between the different JWS serialization formats: Is it > completely safe to assume that any and all programmers given the JWS RFC, > pre-existing JWS implementations with sufficient documentation, and > pre-existing JSON libraries with sufficient documentation could figure out > how to convert the serialization formats as needed? Why, yes! Of course every programmer can do that! ;-) > Or is the conversion > guide necessary? If the guide is necessary, then include a reference to a > separate new or pre-existing conversion guide. If the guide is necessary, > and there is no pre-existing conversion guide, how should the new > conversion guide be published? Should the new conversion guide be > ACME-specific, or more general (possibly with coverage of JWE as well as > JWS features not utilized in ACME)? It's not necessary, *most* programmers can figure it out. But it would doubtlessly be helpful. E.g. I didn't consider the possibility to do this conversion in an ACME implementation before/after using a preexisting JOSE lib. If such a guide were to be published, it should not be ACME-specific. Cheers Jörn
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
