[
https://issues.apache.org/jira/browse/CODEC-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated CODEC-333:
----------------------------------
Summary: Add distinct Base64 decoding for standard and URL-safe (was:
Separate Base64 decoding to "real" base64 and base64Url)
> Add distinct Base64 decoding for standard and URL-safe
> ------------------------------------------------------
>
> Key: CODEC-333
> URL: https://issues.apache.org/jira/browse/CODEC-333
> Project: Commons Codec
> Issue Type: Improvement
> Affects Versions: 1.18.0
> Reporter: Aleksandr Beliakov
> Priority: Minor
>
> The behavior applied in CODEC-75 does not distinguish between Base64 and
> Base64Url implementations within
> [isBase64|https://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/binary/Base64.html#isBase64(java.lang.String)]
> and
> [decodeBase64|https://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/binary/Base64.html#decodeBase64(java.lang.String)]
> methods. Nor, it does change the behavior, even if instantiating a class
> object using a Builder like below, explicitly stating that url-safe
> processing should not be used:
> {code:java}
> Base64 base64 = Base64.builder().setUrlSafe(false).get(); {code}
> with the method
> [isInAlphabet|https://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/binary/Base64.html#isInAlphabet(byte)]
> still using the base64Url-safe decoding table.
>
> This causes some issues in the implementation, for instance inability to
> distinguish between Base64 and PEM encoded certificates, with Apache Codec
> accepting the latest as Base64. See a (chunked and dummy) example below (with
> _Base64.isBase64()_ method returning true):
> {code:java}
> -----BEGIN CERTIFICATE-----
> AQIDBAU=
> -----END CERTIFICATE-----{code}
>
> According to the [RFC 4648|https://datatracker.ietf.org/doc/html/rfc4648],
> handling of Base64 and Base64Url together should not be used:
> {panel:title=5. Base 64 Encoding with URL and Filename Safe Alphabet}
> This encoding may be referred to as "base64url". *This encoding should not
> be regarded as the same as the "base64" encoding* and should not be referred
> to as only "base64". Unless clarified otherwise, "base64" refers to the base
> 64 in the previous section.
> {panel}
> While same handling may be acceptable in some particular cases, we think a
> generic library like Apache Commons Codes shall make a clear separation
> between the two encodings and unless implementors explicitly state the
> support of url-safe characters, it should not be applied by default.
>
> This should also avoid potential errors within the implementations, when a
> system shall treat base64 and base64url encodings as two separate ones (for
> instance like in
> [standards|https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.02.01_60/ts_11918201v010201p.pdf]
> explicitly requiring one or another implementation, based on the usage).
>
> _FYI, Google Guava have two separate implementations
> [BaseEncoding.base64()|https://guava.dev/releases/17.0/api/docs/com/google/common/io/BaseEncoding.html#base64()]
> and
> [BaseEncoding.base64Url()|https://guava.dev/releases/17.0/api/docs/com/google/common/io/BaseEncoding.html#base64Url()]
> allowing implementors to explicitly choose one according to the project
> needs._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
