[Ace] Charter boundaries?

2017-07-17 Thread Michael StJohns
As I'm sitting in the ACE wig session in Prague I'm struck by the number of
extra-charter documents being reviewed or proposed or in progress.  Some
(most?) of these are the specific profiles for given protocols for ace
auth, but reading all of the documents as a whole I get a sense of creeping
featurism or charter creep.

It may be reasonable to do a quick charter respin now or soon to scope the
remainder of the work and just how many auth profiles will be worked
through this group so the group can actual conclude at some point.   In
conjunction with the respin, we need to add and update milestones for
accepted work.

Mike
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


[Ace] Related work for draft-erdtman-ace-rpcc

2017-07-17 Thread Mike Jones
These RFCs are all pertain to OAuth Client Authentication using signed 
assertions:

  *   RFC 7521 - Assertion Framework for OAuth 2.0 Client Authentication and 
Authorization Grants
  *   RFC 7522 - Security Assertion Markup Language (SAML) 2.0 Profile for 
OAuth 2.0 Client Authentication and Authorization Grants
  *   RFC 7523 - JSON Web Token (JWT) Profile for OAuth 2.0 Client 
Authentication and Authorization Grants

I'd encourage you to think about whether using the JWT Profile, in particular, 
would achieve the goals you're after.

   Best wishes,
   -- Mike

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


Re: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt

2017-07-17 Thread Mike Jones
Samuel – I spoke with Jim after ACE.  He said that it’s the encryption example, 
which you didn’t update, that still has the same problems as he identified 
below.

   -- Mike

From: Jim Schaad [mailto:i...@augustcellars.com]
Sent: Friday, June 23, 2017 12:09 AM
To: 'Samuel Erdtman' 
Cc: draft-ietf-ace-cbor-web-to...@ietf.org; 'ace' 
Subject: RE: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt

See below.

Jim

From: Samuel Erdtman [mailto:sam...@erdtman.se]
Sent: Thursday, June 22, 2017 1:40 AM
To: Jim Schaad mailto:i...@augustcellars.com>>
Cc: 
draft-ietf-ace-cbor-web-to...@ietf.org;
 ace mailto:ace@ietf.org>>
Subject: Re: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt

Thanks Jim!
Se comments inline

On Sun, Jun 18, 2017 at 9:21 PM, Jim Schaad 
mailto:i...@augustcellars.com>> wrote:
Comments on this version of the draft.

Section 7 - Step 6 & 7 - I do not know if it is legal to have a CWT CBOR tag at 
this point

In section 7.1 step 6 describes how one can add the CWT CBOR Tag to the full 
CWT if transport layer cannot indicate that this is a CWT. In this case you 
would want first the COSE tag and then the CWT tag this is described in section 
6. We asked Carsten about this before we added the text so it should be okay.
In section 7.2 step 6 and 7 CWT CBOR tag is not mentioned as far as I can tell.

[JLS]  So if an intermediary adds a layer of wrapping (i.e. encrypts it to the 
end point) but the original entity who signed it put the CWT tag on it, it will 
be and invalid CWT if the tag was not removed?


Appendix A.3 - I was unable to reproduce the example.  I assume that this means 
that a deterministic signature algorithm is not being used.  While a verifier 
cannot tell if one is being used, the COSE document does strongly suggest that 
one be used.  Additionally, it helps in testing if one is used so that a 
signature creator can be more easily tested.

Correct I have not used a deterministic signing algorithm. I have used 
COSE-JAVA to create the examples, is it possible to configure that 
implementation to generate deterministic ECDSA signatures?
When working with my JS implementation I have noticed that support for 
deterministic ECDSA implementations are hard to find.

[JLS] With COSE-JAVA, if you are using anything remotely recent is 
deterministic, so that should not be a problem.  I put this change into the 
sources about 8 months ago.  The problem may be the same issue as for A.5 where 
something is different in the data to be signed.



Appendix A.5 - I was unable to reproduce the example.  Specially the tag value 
does not match with the one that I compute.

That is bad. but apart from the tag it looks good?

[JLS] Yes apart from the tag I matched everything – including the encryption.  
This bothers me if you are using the COSE-JAVA to produce the examples.  I 
routinely run regression tests on both language libraries so they should 
produce the same output given the same inputs.  This triggers in my mind that 
you might have done something odd with the external data and thus we are 
generating different tags.   It would be something that is being done for 
signing and for encryption but not mac.



Minor:

In section 2:  Is there a reason not to define CWT claim value in this section

Sorry I´m not following, could you please explain a bit more`?

[JLS] You thought it was reasonable to define a “CWT encoded claim key” in the 
terms.  I was just thinking that it would be symmetric to have the values have 
defined here at the same time.



-Original Message-
From: Ace [mailto:ace-boun...@ietf.org] On Behalf 
Of internet-dra...@ietf.org
Sent: Monday, June 5, 2017 6:27 PM
To: i-d-annou...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] I-D Action: draft-ietf-ace-cbor-web-token-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for 
Constrained Environments of the IETF.

Title   : CBOR Web Token (CWT)
Authors : Michael B. Jones
  Erik Wahlström
  Samuel Erdtman
  Hannes Tschofenig
Filename: draft-ietf-ace-cbor-web-token-05.txt
Pages   : 23
Date: 2017-06-05

Abstract:
   CBOR Web Token (CWT) is a compact means of representing claims to be
   transferred between two parties.  The claims in a CWT are encoded in
   the Concise Binary Object Representation (CBOR) and CBOR Object
   Signing and Encryption (COSE) is used for added application layer
   security protection.  A claim is a piece of information asserted
   about a subject and is represented as a name/value pair consisting of
   a claim name and a claim valu