On Aug 28, 2023, at 2:18 PM, Heikki Vatiainen wrote:
> My colleague just pointed out that a lazy implementation can simply always
> ignore EMSK and still be compliant. Would being lazy be a good reason?
With the updated text, the document says "use EMSK if it's available". So if
an implement
On Aug 28, 2023, at 2:20 PM, Eliot Lear wrote:
>> First, section 3.11.1 states that authentication is needed before
>> provisioning, but C.11. does not show any authentication. Should the diagram
>> show phase 1 client certificate authentication or phase 2 tunnelled
>> authentication? Are both
On Aug 26, 2023, at 3:47 PM, Alexander Clouter wrote:
> I have read through the document and think it is "good to go", post nit
> combing...
Fixed, thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
On Aug 27, 2023, at 10:42 AM, Heikki Vatiainen
wrote:
> Related to this, a closer look at the draft shows that at least the following
> terms are used in interchangeable manner:
Fixed thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https:/
On 28.08.23 20:10, Heikki Vatiainen wrote:
Here are some notes that I thought could be useful to sharpen how PKCS
exchange is documented.
Example exchange C.11. PKCS Exchange shows how certificate
provisioning is done with TEAP:
https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-13.ht
On Mon, 28 Aug 2023 at 21:09, Alexander Clouter
wrote:
> On Mon, 28 Aug 2023, at 15:43, Heikki Vatiainen wrote:
> >
> >> If an inner method supports export of an Extended Master Session Key
> >> (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in
> >> [RFC5295].
> >
> > Why the SH
Here are some notes that I thought could be useful to sharpen how PKCS
exchange is documented.
Example exchange C.11. PKCS Exchange shows how certificate provisioning is
done with TEAP:
https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-13.html#name-c11-pkcs-exchange
Section 3.11.1 "Certif
On Mon, 28 Aug 2023, at 15:43, Heikki Vatiainen wrote:
>
>> If an inner method supports export of an Extended Master Session Key
>> (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in
>> [RFC5295].
>
> Why the SHOULD? If something else is done, how could it work with other
> impleme
On Mon, 28 Aug 2023 at 13:25, Alexander Clouter
wrote:
> On Sun, 27 Aug 2023, at 18:16, Heikki Vatiainen wrote:
>
> > https://github.com/emu-wg/rfc7170bis/pull/27
> >
> > Alex, please comment. I've discussed this with a colleague and we think
> the
> > current draft would break compatibility wi
On Aug 27, 2023, at 1:50 PM, Eliot Lear wrote:
> This change looks good. I want to code it with the PKCS ops to make sure
> it's okay. That'll take a little bit.
I've merged the PR.
I'll think separately about Alex's comments. I understand the intent, but
getting this text clear and cor
On Sun, 27 Aug 2023, at 18:16, Heikki Vatiainen wrote:
> RFC 7170 and the current draft have diverged in how IMSK is calculated.
>
> In short:
> 1. RFC 7170 pass EMSK to TLS-PRF whereas the draft passes both EMSK and MSK
> to TLS-PRF.
> 2. While RFC 7170 adjusts only MSK to 32 octet length, the dra
Hi Heikki
Ok, so *I* let it soak for a few days ;-) and I'm comfortable with the
wording.
Eliot
On 27.08.23 16:42, Heikki Vatiainen wrote:
On Fri, 25 Aug 2023 at 22:30, Eliot Lear wrote:
I agree with the sentiment, but I think it would be good for the
words
to soak a bit, since
12 matches
Mail list logo
