Open
Bug 232775
Opened 22 years ago
Updated 3 years ago
Encode DNs using only UTF-8 for new CSRs
Categories
(NSS :: Libraries, enhancement, P2)
Tracking
(Not tracked)
NEW
People
(Reporter: nelson, Unassigned)
References
(Depends on 1 open bug)
Details
This is a spinoff of bug 204788, address the comments beginning with this one:
http://bugzilla.mozilla.org/show_bug.cgi?id=204788#c8
John Myers added http://bugzilla.mozilla.org/attachment.cgi?id=139529&action=view
to that bug, which causes it to encode all attribute type/value pairs with UTF8
when encoding DNs. But this is only appropriate when encoding DNs for new CSRs
after Jan 1, 2004.
This issue is related to bug 210709 and its blockers.
Perhaps we need separate APIs for encoding old and new DNs, or perhaps we
need an API that takes a date argument (a PRTime) and encodes based on that.
John, any other suggestions?
| Reporter | ||
Comment 1•22 years ago
|
||
I think we need to fix this for NSS 3.10.
We need to start generating new RFC-3280-conformant CSRs RSN.
Priority: -- → P2
Target Milestone: --- → 3.10
Comment 2•22 years ago
|
||
Per RFC 3280, it is appropriate (i.e. optional) to encode DNs using UTF8 before
Jan 1, 2004. Jan 1, 2004 is just when UTF8 becomes mandatory, with exceptions
for legacy issuers, renewals of legacy certs, and the like.
Bug 210709 has to do with a broken search algorithm. The search algorithm needs
to be encoding insensitive, otherwise you won't be able to find certs which are
created by other cert libraries which choose different encoding schemes. Trying
to keep CERT_ParseRFC1465AVA's encoding choice static in order to avoid bug
210709 is just papering over a more fundamental design error.
Trying to make the encoding choice sensitive to the Jan 1, 2004 date won't work,
as one still would have incompatibilities between certs issued after that date
using NSS 3.9 and lookups using NSS 3.10.
So I suggest making this bug depend on bug 210709, at least the
encoding-insensitive comparison portion of that bug. So marking.
The other issue is how CAs which use NSS are to issue certs using the exceptions
for legacy issuers and subjects. Presumably they would have to copy the AVA
directly from the legacy cert, not decode and reencode it with
CERT_AsciiToName(). This would be an issue for the CA, but NSS should probably
mention it in the release notes.
Depends on: 210709
| Reporter | ||
Updated•20 years ago
|
QA Contact: bishakhabanerjee → jason.m.reid
Updated•20 years ago
|
Target Milestone: 3.10 → 3.12
| Reporter | ||
Updated•20 years ago
|
QA Contact: jason.m.reid → libraries
| Reporter | ||
Comment 3•17 years ago
|
||
Unsetting target milestone in unresolved bugs whose targets have passed.
Target Milestone: 3.12 → ---
Updated•3 years ago
|
Severity: normal → S3
Comment 4•3 years ago
|
||
The bug assignee is inactive on Bugzilla, and this bug has priority 'P2'.
:beurdouche, could you have a look please?
For more information, please visit auto_nag documentation.
Assignee: wtc → nobody
Flags: needinfo?(bbeurdouche)
Comment 5•3 years ago
|
||
We have modified the bot to only consider P1 as high priority, so I'm cancelling the needinfo here.
Flags: needinfo?(bbeurdouche)
You need to log in
before you can comment on or make changes to this bug.
Description
•