harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ian Payton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-6248) Wildcard subjectAltName dNSName entries throw IOException
Date Fri, 26 Jun 2009 13:03:07 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724506#action_12724506

Ian Payton commented on HARMONY-6248:


Thanks very much for the quick response.  I think restricting wildcards to allowing "*." prefix
is reasonable - the only use-cases I've seen have are of this format (although I need to double-check).
 And I can confirm that the patch works for this.

However, testing this patch highlighted a related issue - but this is more clear cut in terms
of conformance to RFC1034.  The subjectAltName dNSName entry in one of the certificates I
was testing with is actually for a subdomain of "3gppnetwork.org".  As you can see, this unambiguously
doesn't conform to the "preferred name syntax" specified in RFC1034 because it doesn't start
with a letter (which is something I didn't spot while I was concerned about the wildcard issue
- sorry).  So Harmony still throws an IOException from checkDNS() for this certificate, only
for a slightly different reason.  But this is a real domain that we need to work with :-(

Digging through the RFCs, RFC1123 states (in section 2.1): "The syntax of a legal Internet
host name was specified in RFC-952.  One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a letter or a digit.  Host software
MUST support this more liberal syntax."

As this is a more recent RFC than RFC1034 (and RFC1034 also references RFC-952), I think it
could be seen that the "preferred name syntax" of RFC1034 is out-of-date with respect to this
change in RFC1123 to allow leading digits.

Can I therefore also ask that checkDNS() is updated to allow a leading digit in a subdomain?

(Do you want me to raise this as a separate Issue in Jira?)


> Wildcard subjectAltName dNSName entries throw IOException
> ---------------------------------------------------------
>                 Key: HARMONY-6248
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6248
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>            Reporter: Ian Payton
>         Attachments: harmony-6248.patch
> Using the DRLCertFactory JCE provider, calling getSubjectAlternativeNames() on an X509Certificate
throws IOException if the subjectAltName extension in the certificate contains a dNSName entry
with a wildcard (such as "*.example.com").
> This is ultimately because GeneralName::checkDNS() does not allow wildcard entries. 
RFC3280 and RFC1034 both discuss wildcards, although a strict reading of RFC3280 would *appear*
not to allow for them in a subjectAltName dNSName.  However, RFC3280 explicitly allows for
application-specific semantics of use of wildcards in subjectAltName.  As the Harmony code
currently stands, it is not possible for an application to even retrieve the subjectAltName
values if they contain a dNSName that does not strictly conform to the "preferred name syntax"
in RFC1034.  So it is not possible for an application to make the decision on what semantics
to apply to a wildcard value.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message