Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98341A6F1E; Tue, 23 Sep 2014 16:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNMS5tDkguoX; Tue, 23 Sep 2014 16:40:57 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0735.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::735]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A279B1A6F12; Tue, 23 Sep 2014 16:40:56 -0700 (PDT) Received: from CO2PR03CA0026.namprd03.prod.outlook.com (10.141.194.153) by BLUPR03MB391.namprd03.prod.outlook.com (10.141.78.21) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Tue, 23 Sep 2014 23:40:33 +0000 Received: from BY2FFO11FD028.protection.gbl (2a01:111:f400:7c0c::170) by CO2PR03CA0026.outlook.office365.com (2a01:111:e400:1414::25) with Microsoft SMTP Server (TLS) id 15.0.1034.13 via Frontend Transport; Tue, 23 Sep 2014 23:40:32 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD028.mail.protection.outlook.com (10.1.15.217) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 23 Sep 2014 23:40:32 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.23]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0195.002; Tue, 23 Sep 2014 23:40:21 +0000 From: Mike Jones To: Stephen Kent , "secdir@ietf.org" , "jose-chairs@tools.ietf.org" , "Moriarty, Kathleen" Thread-Topic: SECDIR review of draft-ietf-jose-json-web-key-31 Thread-Index: Ac/NW1FjzMdOWVrURg2Daf2ptprAcwAd5ucAAmzKvhA= Date: Tue, 23 Sep 2014 23:40:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BA6F3C8@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439AEB89F6@TK5EX14MBXC292.redmond.corp.microsoft.com> <5411BC12.9040808@bbn.com> In-Reply-To: <5411BC12.9040808@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BA6F3C8TK5EX14MBXC286r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(199003)(377454003)(3905003)(51414003)(51914003)(189002)(16236675004)(54356999)(99396002)(512954002)(230783001)(81156004)(76176999)(19300405004)(19617315012)(86362001)(84326002)(81342003)(66066001)(85806002)(46102003)(77096002)(10300001)(120916001)(87936001)(31966008)(15202345003)(104016003)(95666004)(86612001)(81542003)(15975445006)(80022003)(4396001)(71186001)(55846006)(68736004)(106466001)(83072002)(19625215002)(50986999)(76482002)(64706001)(107046002)(19580405001)(79102003)(6806004)(83322001)(19580395003)(2501002)(92566001)(2656002)(21056001)(2201001)(85306004)(74502003)(74662003)(97736003)(90102001)(44976005)(77982003)(33656002)(85852003)(92726001)(84676001)(69596002)(20776003)(7059019)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB391; H:mail.microsoft.com; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB391; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0343AC1D30 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Ob7JR4egnIpk3V9V2OXj2xAtn1A Cc: "jose@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 23:41:04 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BA6F3C8TK5EX14MBXC286r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks again for your review, Stephen. The resolutions discussed below hav= e been incorporated in draft -32. See the thread "JWK member names, was: [jose] SECDIR review of draft-ietf-j= ose-json-web-key-31" for the status of that particular issue. -- Mike From: Stephen Kent [mailto:kent@bbn.com] Sent: Thursday, September 11, 2014 8:13 AM To: Mike Jones; secdir@ietf.org; jose-chairs@tools.ietf.org; Moriarty, Kath= leen Cc: jose@ietf.org Subject: Re: SECDIR review of draft-ietf-jose-json-web-key-31 Mike, Thanks for the reply to my comments. I've retained your replies and responded to them, below. I agree that "employing countermeasures to" is more accurate than "preventi= ng". I also agree that the "avoiding mistakes" language is not actionable = - I propose to just remove it. Great. Actually, it was spoken by then-Security AD Sean Turner. ;-) gee, I thought Sean was wise, but I didn't realize he was a Jedi ;-). How about changing "data associated with a key" to "data cryptographically = secured by a key"? (And of course, deleting the extraneous "than".) OK. The wording above is needlessly awkward. Nonetheless, this says that key s= ets containing symmetric or private keys should be encrypted by embedding t= hem in another JSON crypto format (JWE). It would be nice to add that this = implies a that there is secure way to deliver the needed decryption key for= the JWE, else this recommendation just adds a layer of indirection, and do= es not solve the problem. Fair enough. I propose that we add something along those lines. OK, I look forward to seeing the revised wording here. Section 9.3 discusses a countermeasure against a specific attack on RSA key= use. This seems unduly narrow, since this spec is intended for use with RS= A, DH, DSS, and ECDH keys. Why devote a long paragraph to this one issue, w= hile saying nothing about equally serious concerns that arise for other alg= orithms? This particular attack is described both because the countermeasure require= s specific key representation actions and because a working group member as= ked it to be included. For what it's worth, I expect that additional secur= ity considerations will be added when resolving Russ Housley's gen-art revi= ew of the JWS specification. If comparable alg-specific countermeasures are added based on Russ's commen= ts then this may be OK, but in isolation this RSA-specific attack seem out of place= . These non-goals were agreed to by the working group from the very beginnin= g, while the working group was still being chartered. The group wanted to = build something simple and easily deployable to represent keys in JSON - no= t reinvent all the work that the PKIX working group did on certificates and= certificate chains, etc. Do any working group members want to suggest spe= cific wording to try to capture this sentiment? OK. The example that comprises Section 3 should include an explanation of the = parameters, else it's not a great example. The parameters and values of them are explained in the paragraph preceding = the example text. It says: The following example JWK declares that the key is an Elliptic Curve [DSS] key, it is used with the P-256 Elliptic Curve, and its x and y coordinates are the base64url encoded values shown. A key identifier is also provided for the key. Each statement above corresponds to a parameter in the example, and in the = same order. OK. I missed that. I suppose that one option is to be more verbose above and add parenthetical= remarks after each statement above saying which parameter does this. So f= or instance, the parenthetical phrase "("kty" parameter)" could be added be= fore the first comma. Do others in the working group think that would make= the example easier to read, harder to read, or do any of you have an alter= native suggestion? I defer to the WG on this presentation issue. In addition to the common parameters, each JWK will have members that are algorithm-specific. They're not algorithm-specific - they're key type-specific. Another way of= eliminating the repeated use of the word "parameters" is to replace the se= cond sentence with "These members represent the key value". Would that wor= k for you (and the working group)? Yes, I meant key-type specific. But if one were to use that term instead of= "algorithm specific" I still think my wording is better. This topic has been heavily discussed by the working group, and while the s= pecs used to just say that objects with duplicate member names MUST be reje= cted, working group members, including Tim Bray (the editor of the JSON spe= c), prevailed on us to weaken this so that parsers that implement the ECMAs= cript behavior of returning only the last member name may be legally used. = (The argument was made that there was more security downside in effectivel= y requiring people to write and debug their own strict parsers than in usin= g laxer, but well-supported and debugged parsers.) I find that argument unpersuasive, but I defer to the cognizant Ad on this. However, we also intentionally require that producers use only one instance= of each member name, so that legally produced objects will never exercise = the ambiguities that are present in real JSON parsers. That seemed to be t= he most practical solution to the working group. Based on year of experience in PKIX that is not a great solution. If the co= nsumer of a data structure fails to strictly enforce the requirement imposed on the producer= of the data structure, the result is that non-conforming producers do not receive "appropriate" fe= edback. The term "Collision-Resistant Name" is already present in the Terminology s= ection. However, previous reviewers had requested that definitions not be = repeated in multiple specs, so it's incorporated by reference, rather than = repeating the definition here. The notion is that of an implementation wan= ts to use a collision-resistant name such as "http://names.example.com/the-= name", it can do so without having to create a public specification and reg= ister the name with IANA. I found the definition by reading one of the other specs, but I didn't see = a clear explanation of why this is a reasonable alternative to using an IANA registry. The text ab= ove does still does not provide a rationale. I agree that the "SHOULD" language is awkward. Rather than saying "SHOULD= be used", we could change it to just say "is used". OK. Would the language "The "alg" member can be used to specify the cryptograph= ic operation that the key is intended to be used for" work better for you? = Or would people like to just see the parenthetical remark deleted? How about: The "alg" member is used to specify the algorithm with which the key is to = be used. Section 4.5 defines the key_ops parameter. It's not clear how this paramet= ers and "use" relate. There is also an odd sentence at the end of the first= paragraph: The "key_ops" parameter is intended for use cases in which public, private, or symmetric keys may be present. This seems to encompass all of the types of keys that JWK carries, so the s= entence seems to add no useful qualification for when this parameter is int= ended to be used. This is in contrast to the related statement in the "use" definition: The "use" parameter is intended for use cases in which it is useful to distinguish between public signing keys and public encryption keys. Too subtle for me, and the language above seems a bit wimpy. Why not say: The "use" parameter is employed to indicate whether a public key is for enc= rypting data or verifying the signature on data. If you want to see this parameter name changed, you'll need to file a bug = against the WebCrypto spec and get it changed there. Then I'm sure that JO= SE will gladly follow. My request is directed to the IESG, suggesting that they take this action. This specification will be used both in open environments, in which multipl= e organizations will need to have a common understanding of any extensions = used, and closed environments, which the producing and consuming organizati= on will always be the same and private values could be safely used. IANA r= egistration is definitely the right thing to do for open environments. It'= s probably unnecessary for deployments in closed environments. Then say this. Same answer as for Section 4. ibid. "Can" is being used as a non-2119 synonym for "MAY" here. That being said,= we could just change "can be" to "is", since it's explicitly said that its= use is optional at the end of the paragraph. please revise accordingly. It's the inclusion of other metadata about the key that might improve inte= roperability that's being referred to - not the inclusion of the cert refer= ence. For instance, including "use" or "alg" parameters might be useful to= applications that can't process the certificate. that's not what the text said, hence my confusion. As for the cert vs. cert chain question, in the general case, a chain may b= e required to establish trust. However, a chain of length one (a single ce= rtificate) will also be sufficient in some use cases. We're not inventing = anything new here. The data format is specified in RFC 1421. could you point specifically to where 1421 uses two names to identify equiv= alent data structures for transport of certs/cert chains? I trued a quick search of the text and = didn't locate the text to which you appear to refer. I had thought there were uses of RSA keys where the same key is used both = for signing and encryption (even though this is a deprecated practice). Yes, that practice is frowned upon, and we prefer that certs use an OID tha= t makes it clear how a key is to be used. How about the following text: Similarly, if the "alg" member is present, it MUST be consistent with the algorithm specified in the certificate. But we could change this to "Similarly, if the "alg" member is present, it = SHOULD correspond to the algorithm specified in the certificate." Or is th= at overly strong for some certificates and uses of them? I prefer this text. Also, the name seems misleading since the chain MAY contain additional cer= ts, and hence may not be a chain at all! I'm not sure if I'm following you here. Are you suggesting the possibility= of having multiple certificates not chaining to one another in the represe= ntation? This isn't allowed by the specification, as written. Are you sug= gesting that it needs to be allowed? Thumbprint is the term used in the Windows libraries, such as http://msdn.m= icrosoft.com/en-us/library/system.security.cryptography.x509certificates.x5= 09certificate2.thumbprint(v=3Dvs.110).aspx. Whereas OpenSSL uses fingerprint http://www.= openssl.org/docs/apps/x509.html. I know that there would be an uproar if w= e tried to make a breaking change to the "x5t" name at this point, because = it's in widespread production use. However, we could add language saying t= hat certificate thumbprints are also known as certificate fingerprints, so = people familiar with either term will know what this is. Yes, do add that explanatory text. The term "base64url" is incorporated by reference in the terminology sectio= n (Section 2). Actually, Appendix C in JWS is not normative. It's just example code. The= normative definition of the encoding is in Section 5 of RFC 4648. Then 4648 should be cited. It used to be a "SHOULD" but the working group felt that the "MUST ... unle= ss" wording was a more accurate statement of the requirement. I defer to the cognizant AD here, but the notion of SHOULD is really MUST .= .. unless ... Section 8 (IANA Considerations) establishes a two-week review period for cr= eating new (IANA) registry items. This seems too short; some people take mu= lti-week vacations. I note that the same text appears in the JWS and JWE do= cuments. This text was taken from RFC 6749. I didn't review that RFC. My comment still stands. Aren't appendices normally informative? normally, but not always. We could be more explicit and talk about performing authenticated encrypti= on. please do. Steve --_000_4E1F6AAD24975D4BA5B16804296739439BA6F3C8TK5EX14MBXC286r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks again for your rev= iew, Stephen.  The resolutions discussed below have been incorporated = in draft -32.

 <= /p>

See the thread “JWK= member names, was: [jose] SECDIR review of draft-ietf-jose-json-web-key-31= ” for the status of that particular issue.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         -- Mike

 <= /p>

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Thursday, September 11, 2014 8:13 AM
To: Mike Jones; secdir@ietf.org; jose-chairs@tools.ietf.org; Moriart= y, Kathleen
Cc: jose@ietf.org
Subject: Re: SECDIR review of draft-ietf-jose-json-web-key-31

 

Mike,

Thanks for the reply to my comments.

I've retained your replies and responded to them, below.

 
I agree that “employing countermeasures to= ” is more accurate than “preventing”.  I also agree = that the “avoiding mistakes” language is not actionable –= I propose to just remove it.

Great.

  Actually, it was spoken by then-Security = AD Sean Turner. ;-)

gee, I thought Sean was wise, but I didn't realize h= e was a Jedi ;-).

How about changing “data associat= ed with a key” to “data cryptographically secured by a key̶= 1;?  (And of course, deleting the extraneous “than”.)<= /p>

OK.

 The wording above is needlessly awkward. Nonetheless, this says that key sets containing symmetric or private keys should be encrypte= d by embedding them in another JSON crypto format (JWE). It would be nice t= o add that this implies a that there is secure way to deliver the needed de= cryption key for the JWE, else this recommendation just adds a layer of indirection, and does not solve the pr= oblem.

Fair enough.  I propose that we ad= d something along those lines.

OK, I look forward to seeing the revised wording her= e.

Section 9.3 discusses a counte= rmeasure against a specific attack on RSA key use. This seems unduly narrow= , since this spec is intended for use with RSA, DH, DSS, and ECDH keys. Why devote a long paragraph to this one = issue, while saying nothing about equally serious concerns that arise for o= ther algorithms?

 

This particular attack is described bot= h because the countermeasure requires specific key representation actions and because a working group member asked it to be included.  = For what it’s worth, I expect that additional security considerations= will be added when resolving Russ Housley’s gen-art review of the JW= S specification.

If comparable alg-specific countermeasures are added= based on Russ's comments then
this may be OK, but in isolation this RSA-specific attack seem out of place= .

 These non-goals were agreed to by= the working group from the very beginning, while the working group was still being chartered.  The group wanted to build something simpl= e and easily deployable to represent keys in JSON – not reinvent all = the work that the PKIX working group did on certificates and certificate ch= ains, etc.  Do any working group members want to suggest specific wording to try to capture this sentiment?<= /o:p>

OK.

 The example that comprises Section 3 should include an explanation of the parameters, else it’s not a great example.=

 

The parameters and values of them are e= xplained in the paragraph preceding the example text.  It says:

 

   The =
following example JWK
   decl=
ares that the key is an Elliptic Curve [DSS] key, it is used with
   the =
P-256 Elliptic Curve, and its x and y coordinates are the=

   base=
64url encoded values shown.  A key identifier is also provided<=
o:p>
   for =
the key.

 

Each statement above corresponds to a p= arameter in the example, and in the same order.

OK. I missed that.

I suppose that one option is to be more= verbose above and add parenthetical remarks after each statement above saying which parameter does this.  So for instance, the parenth= etical phrase “(“kty” parameter)” could be added be= fore the first comma.  Do others in the working group think that would= make the example easier to read, harder to read, or do any of you have an alternative suggestion?

I defer to the WG on this presentation issue.

  In addition to t= he common parameters, each JWK will have members that

  are algorithm-specific.

 <= /o:p>

They’re not algo= rithm-specific – they’re key type-specific.  Another way o= f eliminating the repeated use of the word “parameters” is to r= eplace the second sentence with “These members represent the key value”.  W= ould that work for you (and the working group)?

Yes, I meant key-type specific. But if one were to u= se that term instead of "algorithm specific"
I still think my wording is better.

This topic has been he= avily discussed by the working group, and while the specs used to just say = that objects with duplicate member names MUST be rejected, working group members, including Tim Bray (the editor of the JSON spec), p= revailed on us to weaken this so that parsers that implement the ECMAscript= behavior of returning only the last member name may be legally used. = (The argument was made that there was more security downside in effectively requiring people to write and debug = their own strict parsers than in using laxer, but well-supported and debugg= ed parsers.)

I find that argument unpersuasive, but I defer to th= e cognizant Ad on this.

However, we also inten= tionally require that producers use only one instance of each member name, = so that legally produced objects will never exercise the ambiguities that are present in real JSON parsers.  That seemed to be= the most practical solution to the working group.

Based on year of experience in PKIX that is not a gr= eat solution. If the consumer of a data
structure fails to strictly enforce the requirement imposed on the producer= of the data structure,
the result is that non-conforming producers do not receive "appropriat= e" feedback.


The term "Collision-Resistant Name" is already present in the Terminology section.  H= owever, previous reviewers had requested that definitions not be repeated in multiple specs, so it’s incorporated by reference, rather than re= peating the definition here.  The notion is that of an implementation = wants to use a collision-resistant name such as “http://names.example.com/the-name”, it can do so without having to create a public specification and register = the name with IANA.

I found the definition by reading one of the other s= pecs, but I didn't see a clear explanation of
why this is a reasonable alternative to using an IANA registry. The text ab= ove does still does
not provide a rationale.

 I agree that the &#= 8220;SHOULD” language is awkward.  Rather than saying “SHO= ULD be used”, we could change it to just say “is used”.

OK.

Would the language = 220;The “alg” member can be used to specify the cryptographic o= peration that the key is intended to be used for” work better for you= ?  Or would people like to just see the parenthetical remark deleted?

How about:

The "alg" member is used to specify the al= gorithm with which the key is to be used.

 Section 4.5 defines the = key_ops parameter. It’s not clear how this parameters and “use&= #8221; relate. There is also an odd sentence at the end of the first paragraph:

 

   The "key_ops" parameter is= intended for use cases in which public,

   private, or symmetric keys may be pr= esent.

 

This seems to encompass all of= the types of keys that JWK carries, so the sentence seems to add no useful= qualification for when this parameter is intended to be used.

 

This is in cont= rast to the related statement in the “use” definition:

 

   The "use" parameter is intended for use cases = in which

   it is useful to distinguish between public signing keys = and public

   encryption keys.

Too subtle for me, an= d the language above seems a bit wimpy. Why not say:

The "use" parameter is employed to indicat= e whether a public key is for encrypting
data or verifying the signature on data.

 If you wa= nt to see this parameter name changed, you’ll need to file a bug against the WebCrypto spec and get it changed there.  Then I’m = sure that JOSE will gladly follow.

My request is directed to the IESG, suggesting that = they take this action.



T= his specification will be used both in open environments, in which multiple= organizations will need to have a common understanding of any extensions used, and closed environments, which the producing and c= onsuming organization will always be the same and private values could be s= afely used.  IANA registration is definitely the right thing to do for= open environments.  It’s probably unnecessary for deployments in closed environments.

Then say this.

Same answer as = for Section 4.

ibid.

&= #8220;Can” is being used as a non-2119 synonym for “MAY” = here.  That being said, we could just change “can be” to &= #8220;is”, since it’s explicitly said that its use is optional at the end of the paragraph.

please revise accordingly.

&= nbsp;It’s the inclusion of other metadata about the key that might im= prove interoperability that’s being referred to – not the inclu= sion of the cert reference.  For instance, including “use” or = “alg” parameters might be useful to applications that can’= ;t process the certificate.

that's not what the text said, hence my confusion.

As for the cert= vs. cert chain question, in the general case, a chain may be required to establish trust.  However, a chain of length one (a si= ngle certificate) will also be sufficient in some use cases.  We’= ;re not inventing anything new here.  The data format is specified in = RFC 1421.

could you point specifically to where 1421 uses two = names to identify equivalent data structures
for transport of certs/cert chains? I trued a quick search of the text and = didn't locate the
text to which you appear to refer.

 I had tho= ught there were uses of RSA keys where the same key is used both for signing and encryption (even though this is a deprecated practice).

Yes, that practice is frowned upon, and we prefer th= at certs use an OID that makes it clear
how a key is to be used. How about the following text:


   Sim= ilarly, if the "alg" member is present, it MUST be consistent wit= h

   the= algorithm specified in the certificate.



B= ut we could change this to “Similarly, if the “alg” membe= r is present, it SHOULD correspond to the algorithm specified in the certif= icate.”  Or is that overly strong for some certificates and uses of them?

I prefer this text.

&= nbsp;Also, the name seems mislea= ding since the chain MAY contain additional certs, and hence may not be a chain at all!

&= nbsp;

I= ’m not sure if I’m following you here.  Are you suggesting= the possibility of having multiple certificates not chaining to one anothe= r in the representation?  This isn’t allowed by the specification= , as written.  Are you suggesting that it needs to be allowed?<= o:p>



Thumbprint is the term us= ed in the Windows libraries, such as http://msdn.microsoft.com/= en-us/library/system.security.cryptography.x509certificates.x509certificate= 2.thumbprint(v=3Dvs.110).aspx.  Whereas OpenSSL uses fingerprint http://ww= w.openssl.org/docs/apps/x509.html.&nb= sp; I know that there would be an uproar if we tried to make a breaking change= to the “x5t” name at this point, because it’s in widespr= ead production use.  However, we could add language saying that certif= icate thumbprints are also known as certificate fingerprints, so people familiar with either term will know what this is.

Yes, do add that explanatory text.

The term “base64url= ” is incorporated by reference in the terminology section (Section 2)= .

 <= /p>

Actually, Appendix C in J= WS is not normative.  It’s just example code.  The normativ= e definition of the encoding is in Section 5 of RFC 4648.=

Then 4648 should be cited.

 

It used to be a “SH= OULD” but the working group felt that the “MUST … unless&= #8221; wording was a more accurate statement of the requirement.

I defer to the cognizant AD here, but the notion of = SHOULD is really MUST ... unless ...

 <= /p>

Section 8 (IANA = Considerations) establishes a two-week review period for creating new (IANA= ) registry items. This seems too short; some people take multi-week vacatio= ns. I note that the same text appears in the JWS and JWE documents.

 

This text was taken from = RFC 6749.

I didn't review that RFC. My comment still stands.

Aren’t appendices n= ormally informative?

normally, but not always.

 We could be more explicit and talk about performing= authenticated encryption.

please do.

Steve

--_000_4E1F6AAD24975D4BA5B16804296739439BA6F3C8TK5EX14MBXC286r_--