You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Ian Payton (JIRA)" <ji...@apache.org> on 2009/06/26 15:03:07 UTC

[jira] Commented: (HARMONY-6248) Wildcard subjectAltName dNSName entries throw IOException

    [ 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:
-------------------------------------

Tim,

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?)

Thanks
Ian

> 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.