On 05/01/15 15:42, Stephen Kent wrote:
Rob,
Happy New Year.
Happy New Year, Steve.
- 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.
My intention was that the literal, case-sensitive string "(PRIVATE)."
would appear zero or more times at the start of each SAN:dNSName in each
Precertificate.
In each real X.509 certificate, each instance of "(PRIVATE)" would be
replaced by a real, case-insensitive label.
I don't object to saying that "(PRIVATE)" can be case-insensitive. That
said, my preference is still to ditch "(PRIVATE)" and use "?" instead.
Note that we've decided to change the Precertificate format in 6962-bis.
The format will no longer be the X.509 certificate format. Therefore,
RFC5280 does not apply, which means that a 6962-bis Precertificate and
the associated X.509 certificate can have the same Issuer and Serial Number.
If RFC5280 does not apply to the serial number field of a (non-X.509)
Precertificate, then why would RFC5280 apply to the SAN:dNSName field(s)
of a (non-X.509) Precertificate?
<snip>
"*" 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.
The explicit exception is also present in RFC5280's predecessors:
RFC3280 (published April 2002) and RFC2459 (published January 1999).
Were there really "many CAs" in existence in January 1999?
The exception in 5280/3280/2459 does _not_ say that "wildcard" has to
mean the "*" character.
RFC2818 (HTTP Over TLS) is an example of "Applications with specific
requirements MAY use such names, but they must define the semantics".
It says that "Names may contain the wildcard character * which is
considered to match any single domain name component or component fragment".
I don't think it's a good idea to request another exception. Why not use
"*" instead, since that seems semantically appropriate?
RFC6125 says that if "*" is used in a cert's CN or SAN:dNSName, it must
appear only once per name and it must be the left-most label. It would
be useful to be able to audit compliance to this rule using CT logs.
Such auditing would be impossible if we were to use "*" for name
redaction too.
The semantics are different. "*" means "matches any label", whereas "?"
(or "(PRIVATE)", or "(private)", or even "(pRivATe)") means "matches one
particular label, the value of which has been redacted".
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."
Kinda.
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 "*"
All of the 43 "*" characters in rfc5280.txt are bullet point. RFC5280
never mentions "*" as a/the wildcard character. The word "asterisk"
doesn't appear in RFC5280 at all.
AFAICT, "*" is neither more nor less legal than "?", as far as RFC5280
is concerned.
Where is this 'explicit exception for "*"' that you're talking about?
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.
I can only go by what 5280 actually says. And AFAICT, even if 5280
applies to (non-X.509) Precertificates (which I don't think it does),
5280 would not need to be updated to permit the use of "?" as a
different sort of wildcard/placeholder label for (non-X.509)
Precertificate CN and SAN:dNSName strings.
Steve
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
