Rob,
Happy New Year.
- stating that the literal string "(PRIVATE)" always covers
precisely
_one_ label.
Since DNS names are case insensitive, I suggest we not represent a
reserved
label in uppercase. It may cause some readers to believe that the
label is
special because of its case.
The private label _is_ "special" though. :-)
It's intended to be a placeholder for a real label.
I'm not sure what you mean by these two sentences. I hope you don't mean
that
you expect an RP to treat the uppercase representation as different from
lowercase. That would not be consistent with DNS canonicalization rules
(as per 1034) and thus not consistent with 5280. If you mean that you
plan to
replace "PRIVATE" with some other word, which will treated in a
case-insensitive
fashion, then NEVERMIND.
So for example, if you wanted to redact 3 components, you'd put
"SAN:dNSName=(PRIVATE).(PRIVATE).(PRIVATE).mydomain.com" in the
Precertificate.
To reduce bloat, I think we should also change "(PRIVATE)" to "?".
e.g. "SAN:dNSName=?.?.?.mydomain.com"
Is "?" a legal DNS label character? It doesn't seem so as per RFC 1034,
and RFC 5280 cites 1034 as the normative spec for dNSName syntax in
the subjectAltName extension.
I agree that "?" is not a valid DNS label character according to RFC
1034, but that's actually a useful characteristic here. If it was a
valid DNS label character, then it could be mistakenly interpreted as
a real label rather than as just a placeholder!
true.
"*" isn't a valid DNS label character either, and yet it is commonly
used in SAN->dNSName fields as a placeholder.
yes, I'm sad to say. PKIX gave into this misuse of DNS syntax because so
many
CAs adopted the convention. So we added an explicit exception in 5280. I
don't think
it's a good idea to request another exception. Why not use "*" instead,
since that
seems semantically appropriate?
You're referring to this part of RFC5280 Section 4.2.1.6:
"When the subjectAltName extension contains a domain name system
label, the domain name MUST be stored in the dNSName (an IA5String).
The name MUST be in the "preferred name syntax", as specified by
Section 3.5 of [RFC1034] and as modified by Section 2.1 of
[RFC1123]."
If one or more labels is a placeholder rather than a real label, then
IMHO the string is _not_ a "domain name system label". And therefore,
the two MUST requirements quoted above don't apply.
I find this reasoning rather circular; it sounds like you're saying
"since we violated
the syntax already, we can do a anything we want." I'd argue that if you
use the dNSNAme
SAN type, the string that appears there MUST adhere to DNS name syntax.
If you want to
use some other syntax, then create a new SAN type.
Also, AFAICT RFC5280 doesn't prohibit putting strings that are _not_
"domain name system labels" into SAN->dNSName fields.
Towards the end of Section 4.2.1.6 it says:
"Finally, the semantics of subject alternative names that include
wildcard characters (e.g., as a placeholder for a set of names) are
not addressed by this specification. Applications with specific
requirements MAY use such names, but they must define the semantics."
So, as long as we "define the semantics" for our use of "?", I don't
think we're doing anything wrong.
Do you agree?
No,I do not. As I noted above, PKIX made an explicit exception for "*"
because it
was a widely adopted convention. If you want to use "*" then the
above-cited
paragraph covers this use. If not, then you need to request an update to
5280.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
