Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1662573002:
Adding ASN.1 Name Parsing (Closed)
DescriptionAdding ASN.1 Name Parsing
Primarily to simplify the code for parsing X.509 certificates and
moving off of the system-dependent parsers.
BUG=
Committed: https://crrev.com/d118af36c75a1be3073cb28ff28e9830716abf9d
Cr-Commit-Position: refs/heads/master@{#376240}
Patch Set 1 #Patch Set 2 : Updates to name parsing. #Patch Set 3 : Adding WARN_RESULT. #
Total comments: 18
Patch Set 4 : Fixing comments. #Patch Set 5 : Marking AsString as const. #
Total comments: 20
Patch Set 6 : Fixing comments in the correct CL. #Patch Set 7 : Fix merge on correct CL. #Patch Set 8 : Rebase. #Patch Set 9 : Fix equals. #
Total comments: 4
Patch Set 10 : Fixing comments. #Patch Set 11 : Marking public. #Patch Set 12 : Try again? #Patch Set 13 : Another try. #
Messages
Total messages: 26 (7 generated)
[email protected] changed reviewers: + [email protected], [email protected]
Refactoring out the Name parsing from VerifyNameMatch so that it can be used elsewhere (x509_certificate_model).
https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... File net/cert/internal/parse_name.cc (right): https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... net/cert/internal/parse_name.cc:18: bool ConvertBmpStringValue(const der::Input& in, std::string* out) { Add documentation for this function and the following function. https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... net/cert/internal/parse_name.cc:59: der::Input TypeCommonNameOid() { A comment with where these OIDs are defined would be nice. https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... net/cert/internal/parse_name.cc:129: bool ConvertValueToString(const der::Tag tag, It looks like this function doesn't validate the input - e.g. an IA5String containing non-ASCII bytes will still be converted. That should be documented (I'm assuming the lack of validation is intentional). https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... File net/cert/internal/parse_name.h (right): https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... net/cert/internal/parse_name.h:42: NET_EXPORT bool ConvertValueToString(const der::Tag tag, Documentation? https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... File net/cert/internal/parse_name_unittest.cc (right): https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... net/cert/internal/parse_name_unittest.cc:31: Can you add some negative tests for ConvertBmpStringValue and ConvertUniversalStringValue? https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... net/cert/internal/parse_name_unittest.cc:33: const uint8_t der[] = {0x30, 0x00, 0x00, 0x00}; What are the 2 trailing nul bytes? I see a sequence (0x30) of length 0 (0x00), followed by 2 bytes that aren't valid der (0x00 would be a tag for universal 0, which is reserved for use by the encoding rules).
[email protected] changed reviewers: + [email protected]
+mattm as the author of the code being moved would be a better reviewer, but happy to look too
https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... File net/cert/internal/parse_name.h (right): https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... net/cert/internal/parse_name.h:32: struct AttributeTypeAndValue { This is a fairly generic name to be exposed to the net:: namespace (before it was local to a single .cc file so didn't seem like a problem). Is there a more specific name you can suggest? https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... net/cert/internal/parse_name.h:42: NET_EXPORT bool ConvertValueToString(const der::Tag tag, This naming also feels too generic.
https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... File net/cert/internal/parse_name.h (right): https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... net/cert/internal/parse_name.h:42: NET_EXPORT bool ConvertValueToString(const der::Tag tag, I'm wondering if this function should be in net/der and split on types so it's more like the ParseBool/ParseBitString/ParseUTCTime functions. That raises the question of whether it should also be validating the input (for types like IA5String or PrintableString). If this is going to be used outside of parsing Names, it would make sense to validate the input here, but that results in having to make two passes over the input when normalizing directory strings (one for enforcing character sets, and one for normalization).
https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... File net/cert/internal/parse_name.cc (right): https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... net/cert/internal/parse_name.cc:18: bool ConvertBmpStringValue(const der::Input& in, std::string* out) { On 2016/02/03 19:43:24, nharper wrote: > Add documentation for this function and the following function. Done. https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... net/cert/internal/parse_name.cc:59: der::Input TypeCommonNameOid() { On 2016/02/03 19:43:24, nharper wrote: > A comment with where these OIDs are defined would be nice. Done. https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... net/cert/internal/parse_name.cc:129: bool ConvertValueToString(const der::Tag tag, On 2016/02/03 19:43:24, nharper wrote: > It looks like this function doesn't validate the input - e.g. an IA5String > containing non-ASCII bytes will still be converted. That should be documented > (I'm assuming the lack of validation is intentional). Done. https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... File net/cert/internal/parse_name.h (right): https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... net/cert/internal/parse_name.h:32: struct AttributeTypeAndValue { On 2016/02/03 20:58:55, eroman wrote: > This is a fairly generic name to be exposed to the net:: namespace (before it > was local to a single .cc file so didn't seem like a problem). > > Is there a more specific name you can suggest? X509NameAttribute? https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... net/cert/internal/parse_name.h:42: NET_EXPORT bool ConvertValueToString(const der::Tag tag, On 2016/02/03 19:43:25, nharper wrote: > Documentation? Acknowledged. Moved into X509NameAttribute. https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... net/cert/internal/parse_name.h:42: NET_EXPORT bool ConvertValueToString(const der::Tag tag, On 2016/02/03 21:28:41, nharper wrote: > I'm wondering if this function should be in net/der and split on types so it's > more like the ParseBool/ParseBitString/ParseUTCTime functions. > > That raises the question of whether it should also be validating the input (for > types like IA5String or PrintableString). If this is going to be used outside of > parsing Names, it would make sense to validate the input here, but that results > in having to make two passes over the input when normalizing directory strings > (one for enforcing character sets, and one for normalization). If we move it to net/der, we'll need to have an option for selective enforcing of the validation of different string types. https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... File net/cert/internal/parse_name_unittest.cc (right): https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... net/cert/internal/parse_name_unittest.cc:31: On 2016/02/03 19:43:25, nharper wrote: > Can you add some negative tests for ConvertBmpStringValue and > ConvertUniversalStringValue? Done. https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... net/cert/internal/parse_name_unittest.cc:33: const uint8_t der[] = {0x30, 0x00, 0x00, 0x00}; On 2016/02/03 19:43:25, nharper wrote: > What are the 2 trailing nul bytes? I see a sequence (0x30) of length 0 (0x00), > followed by 2 bytes that aren't valid der (0x00 would be a tag for universal 0, > which is reserved for use by the encoding rules). Done.
https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... File net/cert/internal/parse_name.h (right): https://codereview.chromium.org/1662573002/diff/40001/net/cert/internal/parse... net/cert/internal/parse_name.h:32: struct AttributeTypeAndValue { On 2016/02/03 21:43:33, svaldez wrote: > On 2016/02/03 20:58:55, eroman wrote: > > This is a fairly generic name to be exposed to the net:: namespace (before it > > was local to a single .cc file so didn't seem like a problem). > > > > Is there a more specific name you can suggest? > > X509NameAttribute? Yep better!
https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... File net/cert/internal/parse_name.cc (right): https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... net/cert/internal/parse_name.cc:202: return false; Should also verify that there is at least one AttributeTypeAndValue in the set. (In verify_name_match.cc that was in the VerifyRdnMatch function. Perhaps the check should be moved into ReadRdn.) https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... File net/cert/internal/parse_name.h (right): https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... net/cert/internal/parse_name.h:31: struct X509NameAttribute { add a comment like "Represents an AttributeTypeAndValue structure as defined in RFC 5280". https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... net/cert/internal/parse_name.h:43: bool ValueAsString(std::string* out) const WARN_UNUSED_RESULT; I would say this needs to be specified better, and maybe call it ValueAsStringUnsafe (eg, in the case of teletex, what would you do with the result? Should the user need to check what the value type is before using the result? Or should it just fail in the case of teletex?) https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... File net/cert/internal/parse_name_unittest.cc (right): https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... net/cert/internal/parse_name_unittest.cc:23: const uint8_t der[] = {0x66, 0x6f, 0x6f, 0x62, 0x61, 0x72, 0x72}; comment explaining what about these are invalid https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... net/cert/internal/parse_name_unittest.cc:39: const uint8_t der[] = {0x66, 0x6f, 0x6f, 0x62, 0x61, 0x72}; same https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... net/cert/internal/parse_name_unittest.cc:53: TEST(ParseNameTest, ValidName) { There are a bunch of test files in net/data/verify_name_match_unittest/names that could be useful to test against ParseName too, especially the invalid-* ones. https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/verif... File net/cert/internal/verify_name_match.cc (right): https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/verif... net/cert/internal/verify_name_match.cc:177: // X509NameAttribute in |a_parser| has a matching X509NameAttribute in These comments should probably still say AttributeTypeAndValue, since they are referring to the type from the RFC. https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/verif... net/cert/internal/verify_name_match.cc:186: // RelativeDistinguishedName ::= SET SIZE (1..MAX) OF X509NameAttribute This should definitely still say AttributeTypeAndValue. https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/verif... net/cert/internal/verify_name_match.cc:241: // SET SIZE (1..MAX) OF X509NameAttribute same
https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... File net/cert/internal/parse_name.cc (right): https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... net/cert/internal/parse_name.cc:202: return false; On 2016/02/04 20:41:18, mattm wrote: > Should also verify that there is at least one AttributeTypeAndValue in the set. > (In verify_name_match.cc that was in the VerifyRdnMatch function. Perhaps the > check should be moved into ReadRdn.) Done. https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... File net/cert/internal/parse_name.h (right): https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... net/cert/internal/parse_name.h:31: struct X509NameAttribute { On 2016/02/04 20:41:18, mattm wrote: > add a comment like "Represents an AttributeTypeAndValue structure as defined in > RFC 5280". Done. https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... net/cert/internal/parse_name.h:43: bool ValueAsString(std::string* out) const WARN_UNUSED_RESULT; On 2016/02/04 20:41:18, mattm wrote: > I would say this needs to be specified better, and maybe call it > ValueAsStringUnsafe (eg, in the case of teletex, what would you do with the > result? Should the user need to check what the value type is before using the > result? Or should it just fail in the case of teletex?) Is Teletex conversion into a string incorrect in that case? Isn't it a susbet of Utf8String, or is actually a different encoding? https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... File net/cert/internal/parse_name_unittest.cc (right): https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... net/cert/internal/parse_name_unittest.cc:23: const uint8_t der[] = {0x66, 0x6f, 0x6f, 0x62, 0x61, 0x72, 0x72}; On 2016/02/04 20:41:18, mattm wrote: > comment explaining what about these are invalid Done. https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... net/cert/internal/parse_name_unittest.cc:39: const uint8_t der[] = {0x66, 0x6f, 0x6f, 0x62, 0x61, 0x72}; On 2016/02/04 20:41:18, mattm wrote: > same Done. https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... net/cert/internal/parse_name_unittest.cc:53: TEST(ParseNameTest, ValidName) { On 2016/02/04 20:41:18, mattm wrote: > There are a bunch of test files in net/data/verify_name_match_unittest/names > that could be useful to test against ParseName too, especially the invalid-* > ones. Done. https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/verif... File net/cert/internal/verify_name_match.cc (right): https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/verif... net/cert/internal/verify_name_match.cc:177: // X509NameAttribute in |a_parser| has a matching X509NameAttribute in On 2016/02/04 20:41:19, mattm wrote: > These comments should probably still say AttributeTypeAndValue, since they are > referring to the type from the RFC. Done. https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/verif... net/cert/internal/verify_name_match.cc:186: // RelativeDistinguishedName ::= SET SIZE (1..MAX) OF X509NameAttribute On 2016/02/04 20:41:19, mattm wrote: > This should definitely still say AttributeTypeAndValue. Done. https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/verif... net/cert/internal/verify_name_match.cc:241: // SET SIZE (1..MAX) OF X509NameAttribute On 2016/02/04 20:41:19, mattm wrote: > same Done.
I don't see a new patchset... https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... File net/cert/internal/parse_name.h (right): https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... net/cert/internal/parse_name.h:43: bool ValueAsString(std::string* out) const WARN_UNUSED_RESULT; On 2016/02/09 21:27:29, svaldez wrote: > On 2016/02/04 20:41:18, mattm wrote: > > I would say this needs to be specified better, and maybe call it > > ValueAsStringUnsafe (eg, in the case of teletex, what would you do with the > > result? Should the user need to check what the value type is before using the > > result? Or should it just fail in the case of teletex?) > > Is Teletex conversion into a string incorrect in that case? Isn't it a susbet of > Utf8String, or is actually a different encoding? The Teletex encoding is not a subset of utf-8 encoding. It's some pre-unicode thing that supports different character sets with escape codes or something. I suppose theoretically you could transcode it to utf-8, but it's not well documented and many implementations do it wrong so trying to decipher it is probably a lost cause anyway. (see also rsleevi comment at: https://codereview.chromium.org/1125333005/#msg15) For example, VerifyNameMatch only does raw byte comparison of TeletexString objects, and does not attempt to compare them to other string types.
Fixed. Used the wrong CL originally. https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... File net/cert/internal/parse_name.h (right): https://codereview.chromium.org/1662573002/diff/80001/net/cert/internal/parse... net/cert/internal/parse_name.h:43: bool ValueAsString(std::string* out) const WARN_UNUSED_RESULT; On 2016/02/10 03:24:56, mattm wrote: > On 2016/02/09 21:27:29, svaldez wrote: > > On 2016/02/04 20:41:18, mattm wrote: > > > I would say this needs to be specified better, and maybe call it > > > ValueAsStringUnsafe (eg, in the case of teletex, what would you do with the > > > result? Should the user need to check what the value type is before using > the > > > result? Or should it just fail in the case of teletex?) > > > > Is Teletex conversion into a string incorrect in that case? Isn't it a susbet > of > > Utf8String, or is actually a different encoding? > > The Teletex encoding is not a subset of utf-8 encoding. It's some pre-unicode > thing that supports different character sets with escape codes or something. I > suppose theoretically you could transcode it to utf-8, but it's not well > documented and many implementations do it wrong so trying to decipher it is > probably a lost cause anyway. (see also rsleevi comment at: > https://codereview.chromium.org/1125333005/#msg15) > > For example, VerifyNameMatch only does raw byte comparison of TeletexString > objects, and does not attempt to compare them to other string types. Done.
https://codereview.chromium.org/1662573002/diff/160001/net/cert/internal/pars... File net/cert/internal/parse_name_unittest.cc (right): https://codereview.chromium.org/1662573002/diff/160001/net/cert/internal/pars... net/cert/internal/parse_name_unittest.cc:52: // BmpString must encode characters in pairs of 4 bytes. s/BmpString/UniversalString/ And should this be on the ConvertInvalidUniversalString test? https://codereview.chromium.org/1662573002/diff/160001/net/cert/internal/veri... File net/cert/internal/verify_name_match.cc (right): https://codereview.chromium.org/1662573002/diff/160001/net/cert/internal/veri... net/cert/internal/verify_name_match.cc:188: return false; This check could be removed now. And the comment could moved above the "out->size() != 0" test in ReadRdn.
https://codereview.chromium.org/1662573002/diff/160001/net/cert/internal/pars... File net/cert/internal/parse_name_unittest.cc (right): https://codereview.chromium.org/1662573002/diff/160001/net/cert/internal/pars... net/cert/internal/parse_name_unittest.cc:52: // BmpString must encode characters in pairs of 4 bytes. On 2016/02/10 23:30:43, mattm wrote: > s/BmpString/UniversalString/ > And should this be on the ConvertInvalidUniversalString test? Done. https://codereview.chromium.org/1662573002/diff/160001/net/cert/internal/veri... File net/cert/internal/verify_name_match.cc (right): https://codereview.chromium.org/1662573002/diff/160001/net/cert/internal/veri... net/cert/internal/verify_name_match.cc:188: return false; On 2016/02/10 23:30:43, mattm wrote: > This check could be removed now. And the comment could moved above the > "out->size() != 0" test in ReadRdn. Done.
lgtm
The CQ bit was checked by [email protected] to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1662573002/180001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1662573002/180001
The CQ bit was unchecked by [email protected]
Dry run: Try jobs failed on following builders: linux_chromium_chromeos_compile_dbg_ng on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_compile_dbg_32_ng on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
The CQ bit was checked by [email protected]
The patchset sent to the CQ was uploaded after l-g-t-m from [email protected] Link to the patchset: https://codereview.chromium.org/1662573002/#ps240001 (title: "Another try.")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1662573002/240001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1662573002/240001
Message was sent while issue was closed.
Committed patchset #13 (id:240001)
Message was sent while issue was closed.
Description was changed from ========== Adding ASN.1 Name Parsing Primarily to simplify the code for parsing X.509 certificates and moving off of the system-dependent parsers. BUG= ========== to ========== Adding ASN.1 Name Parsing Primarily to simplify the code for parsing X.509 certificates and moving off of the system-dependent parsers. BUG= Committed: https://crrev.com/d118af36c75a1be3073cb28ff28e9830716abf9d Cr-Commit-Position: refs/heads/master@{#376240} ==========
Message was sent while issue was closed.
Patchset 13 (id:??) landed as https://crrev.com/d118af36c75a1be3073cb28ff28e9830716abf9d Cr-Commit-Position: refs/heads/master@{#376240} |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
