Hi let me fix a little.
>>These algorithm need a lot of metadata (including EC point, KDF algorithm, hash algorithms, metadata of hash or KDF, etc…), >>and we are not sure, but believe, when specified they will not use id-ecPublicKey. >>However, they may use SubjectPublicKeyInfo for their metadata. we are not sure, but believe when specified they will not use id-ecPublicKey as a algorithm, but they may use id-ecPublicKey in the metadata field, along with ECIES algorithm identifier in the algorithm field. Regards Tadahiko Ito 2020年2月20日(木) 15:49 Sean Turner <[email protected]>: > Dale, > > Hi! And, thanks for your review comments in-line. > > spt > > > On Feb 18, 2020, at 22:07, Dale Worley via Datatracker <[email protected]> > wrote: > > > > Reviewer: Dale Worley > > Review result: Ready with Issues > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed by > > the IESG for the IETF Chair. Please treat these comments just like > > any other last call comments. > > > > For more information, please see the FAQ at > > > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > > > Document: draft-ietf-lamps-5480-ku-clarifications-00 > > Reviewer: Dale R. Worley > > Review Date: 2020-02-18 > > IETF LC End Date: 2020-02-07 > > IESG Telechat date: [unknown] > > > > Summary: > > > > This draft is on the right track but has open issues, described > > in the review. > > > > The text is difficult to follow in places. I believe that the WG has > > a clear understanding of what is intended, but a few small editorial > > errors have unfortunately rendered the text incorrect and > > contradictory to RFC 5480. > > Sometimes when you are too familiar with the context you assume too much > so a fresh set of eye can help! > > > Note that I am unfamiliar with the details of PKI certificates; this > > review is based largely on what I have learned from RFC 5480 and this > > I-D. > > > >> From the discussion it appears that id-ecDH and id-ecMQV are "key > > agreement algorithms" and that, as such, they should not be used with > > keyEncipherment or dataEncipherment. [this draft, section 3] > > Conversely, id-ecPublicKey is not a "key agreement algorithm". [RFC > > 5480, section 2.1.2, para. 1, sentence 1] > > Ah ... this might be where some of misunderstanding comes from because > id-ecPublicKey MAY be a key agreement algorithm that is why it is > “unrestricted”. In other words, when key agreement certificates can include > the following OIDs: id-ecDH (for an EC DH algorithm), id-ecMQV (for EC > MQV), or id-ecPublicKey (for any algorithm). Here’s the text from 5480 > about id-ecPublicKey being used as key agreement algrithm: > > If the keyUsage extension is present in an End Entity (EE) > certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo, > then any combination of the following values MAY be present: > > digitalSignature; > nonRepudiation; and > keyAgreement. > > > 1. Introduction > > > > This document corrects this omission, by updating Section 3 of > > [RFC5480] to make it clear that neither keyEncipherment nor the > > dataEncipherment key usage bits are set for key agreement algorithms. > > > > This could be clearer by replacing or augmenting "key agreement > > algorithms" with a description of which of these algorithms are key > > agreement algorithms, viz., id-ecDH and id-ecMQV. Otherwise, one must > > first have read RFC 5480 to understand this introduction correctly. > > See above. > > I also pondered how much to put in the intro to accommodate those readers > that are not as familiar with RFC 5480. I went the minimal route since this > is supposed to be just adding two sentences to RFC 5480. I sure hope people > that are not intimately familiar with RFC 5480 do immediately go read RFC > 5480 because this draft isn’t all that much use without doing so :) > > > 3. Updates to Section 3 > > > > If the keyUsage extension is present in a certificate that indicates > > id-ecPublicKey as algorithm of AlgorithmIdentifier [RFC2986] in > > SubjectPublicKeyInfo, then following values MUST NOT be present: > > > > keyEncipherment; and > > dataEncipherment. > > > > If the keyUsage extension is present in a certificate that indicates > > id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following > > values also MUST NOT be present: > > > > keyEncipherment; and > > dataEncipherment. > > > > The structure of this section is peculiar, since it presents almost > > the same text about "id-ecPublicKey" and about "id-ecDH or id-ecMQV". > > If the intention is to say the same thing about all three, these > > should be folded together. > > There are two reasons I’d like to not merge these two bits of text: > > 1. Agreed it is a bit odd, but it does mirror RFC 5480, which talks about > id-ecPublicKey for CA certificates and then EE certificates and then > id-ecDH/id-ecMQV. I guess we could collapse it, but for me then it’s a > style thing and I’d rather mimic the RFC it’s updating. > > 2. With separate sentences we leave open the door for ECC encryption > algorithms like ECIES > < > https://itectec.com/spec/c-3-elliptic-curve-integrated-encryption-scheme-ecies/ > > > > These algorithm need a lot of metadata (including EC point, KDF algorithm, > hash algorithms, metadata of hash or KDF, etc…), and we are not sure, but > believe, when specified they will not use id-ecPublicKey. > However, they may use SubjectPublicKeyInfo for their metadata. > > If we integrate two sentence together, a possible future ECIES draft will > conflict with our draft. > > > It is also not clear why the first paragraph refers to > > AlgorithmIdentifier but the second paragraph uses SubjectPublicKeyInfo > > to refer to essentially the same thing. > > I am pretty sure we did that to provide some context for where the OIDs > go, but you are right the first paragraph could just of easily been: > > If the keyUsage extension is present in a certificate that indicates > id-ecPublicKey in SubjectPublicKeyInfo, > > I will make that change. > > > But this text appears to contradict the statement in [RFC 5480] that > > the usage of id-ecPublicKey is "unrestricted" and is not a key > > agreement algorithm, in which case the first paragraph should say "the > > following values MAY be present". (In which case, the "also" in the > > 2nd paragraph should be omitted.) > > See above. > > Cheers, > > spt
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
