Hi, >Some answers to your questions inline. I'm not sure further changes along the >lines suggested here are needed, but I'm open to arguments that point in that >direction.
I am mostly fine with your answers. Just a couple of comments inline still. --- MIN_2: >>>> Can the mechanism be used also for DTLS? >>> >>> I think the answer is yes. I don't see any reason to disallow the use of >>> Exported Authenticators in DTLS. >> >> Would it be useful to clarify that? > > Going through what the modified text would look like, it seems like a > substantial amount of re-writing (even the title!) for what amounts to an > unclear use case. > Keeping in mind that DTLS 1.3 hasn't been finalized and doesn't directly > define exporters, I'm disinclined to define how EAs would work with DTLS. If > someone > has a strong use case for EA in DTLS, it may be worth considering it. Would it then be useful with a statement saying that it might be possible to use exporters also with DTLS, but that such usage is outside the scope of the document and needs to be specified in a separate document? --- MIN_3: >>>> The documents talk about additional certificates. If I only have one >>>> additional >>>> certificate, can I use that for multiple authenticators throughout the TLS >>>> session? >>> >>> Yes, there is nothing disallowing the creation of multiple exported >>> authenticators with the same certificate. >> >> Would it be useful to clarify that? > > I'm not convinced this is a realistic use case. Since exported authenticators > are based on the exporter, there is no inherent ordering. > If you re-authenticate with the same certificate, there's nothing asserting > freshness of the second certificate. Is there something in > the text that suggests that using a certificate multiple times is disallowed? > If there's no suggestion that this is not possible that > needs to be corrected, I don't see the benefit of calling out this specific > use case. I don't think there is any text suggesting that it is disallowed. But, if you don't think it is a realistic use case I'll take your word for it :) --- ED_2: >>>> Section 3 says: "The authenticator request is a structured message that >>>> can be >>>> created..." Section 4 says: "The authenticator is a structured message >>>> that can >>>> be exported..." >>>> >>>> In the 2nd paragraph of Section 4 it is stated that "authenticator" is sent >>>> based on an "authenticator request". I wonder if that could be stated >>>> already >>>> in the beginning of Section 4, to further clarify the difference between >>>> them. >>>> E.g., >>>> >>>> "The authenticator is a structured message, triggered by an authenticator >>>> request, that can be exported from either party of a TLS connection." >>> >>> The issue is that servers can generate spontaneous exported authenticators >>> without >>> an authenticator request. >> >> Where is this written? Did I miss it? > > Section 4: > An authenticator message can be constructed by either the client or > the server given an established TLS connection, a certificate, and a > corresponding private key. Clients MUST NOT send an authenticator > without a preceding authenticator request; for servers an > authenticator request is optional. For authenticators that do not > correspond to authenticator requests, the certificate_request_context > is chosen by the server. Ok. Looks good. Regards, Christer _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
